← back to v155 · jpeg-xl-decoding-support-image-jxl-in-blink
conformance · v155
v155 · jpeg-xl-decoding-support-image-jxl-in-blink — conformance probe
7 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
7
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
createimagebitmap-available |
createImageBitmap is the decode entry point every probe here uses. spec ↗ | typeof | … | |
jxl-fixture-served-as-image-jxl |
The fixture is served with Content-Type image/jxl. A mislabelled response would make the <picture> negotiation in these demos meaningless, so this checks the harness before it checks the browser. spec ↗ | script | … | |
jxl-decodes-to-a-bitmap |
A real JPEG XL file decodes to an ImageBitmap of its true dimensions (960x600). This is the feature: no registry to query, only a decode that works. spec ↗ | script | … | |
jxl-decodes-to-real-pixels |
Decoding must produce varying pixels, not an opaque or empty bitmap of the right size. Drawing to a canvas and reading it back is the only way to tell those apart. spec ↗ | script | … | |
jxl-loads-in-an-img-element |
The <img> path must work too, not only createImageBitmap: that is how a page actually uses an image. spec ↗ | script | … | |
picture-negotiation-skips-undecodable-types |
A <picture> whose first source declares an unsupported type must fall through to the next candidate. This is what makes shipping a new format safe, and it must keep working regardless of whether JPEG XL itself decodes. spec ↗ | script | … | |
jxl-is-decode-only |
Chrome ships a JPEG XL decoder, not an encoder: canvas.toBlob with image/jxl must fall back to PNG rather than producing a JXL. Asserting the boundary keeps the feature honestly scoped. spec ↗ | script | … |