Consider web font/image/media formats #1089
Comments
Closed
|
For WebP, see dedicated issue #1109 |
|
web-platform-dx/web-features#580 is blocked on this, and is additionally made complicated by the fact that the JEPG XL spec doesn't have a public URL. |
I think we can take the same approach as Specref, which links to the spec page on the ISO web site for ISO/IEC standards. For JPEG XL support in browsers, we probably want to document the file format: iso18181-2, not the core coding system (or list both, but the file format seems the right entry point). I created #1191 to discuss adding specs that don't have published versions to browser-specs. (Can I Use rather links to the JPEG Documentation page, which seems suboptimal: the page does not linnk to the ISO web site) |
tidoust
added a commit
that referenced
this issue
Feb 5, 2024
To add ISO/IEC standards related to JPEG XL (see #1089), there needs to be a way to add an entry in browser-specs that has a canonical URL but no actual nightly URL, because ISO standards are not public (see also #1191). This update amends the code to allow and create entries without a `nightly` property when needed (only for ISO standards for now). The code also retrieves the name of the group that develops an ISO standard. This is a BREAKING CHANGE because the `nightly` property used to be mandatory. Projects that expect to find a `nightly.url` property need to be updated to only look at the root `url` property or to skip the entry altogether. First ISO spec added to the list is JPEG XL, which will appear as: ```json { "url": "https://www.iso.org/standard/85253.html", "seriesComposition": "full", "shortname": "iso18181-2", "series": { "shortname": "iso18181-2", "currentSpecification": "iso18181-2", "title": "Information technology — JPEG XL image coding system — Part 2: File format", "shortTitle": "JPEG XL: File Format" }, "shortTitle": "JPEG XL: File Format", "organization": "ISO/IEC", "groups": [ { "name": "ISO/IEC JTC 1/SC 29", "url": "https://www.iso.org/committee/45316.html" } ], "title": "Information technology — JPEG XL image coding system — Part 2: File format", "source": "specref", "categories": [ "browser" ], "standing": "good" } ``` Worth noting: the absence of a `nightly` property means that there is no place to store the status of the spec, which could in theory be "Under development" or "Published" for ISO specs (there are additional stages in the ISO process but they are probably not worth capturing in any case). An alternative would be to have a `nightly.status` property, but that seems clumsy.
tidoust
added a commit
that referenced
this issue
Feb 6, 2024
…1192) To add ISO/IEC standards related to JPEG XL (see #1089), there needs to be a way to add an entry in browser-specs that has a canonical URL but no actual nightly URL, because ISO standards are not public (see also #1191). This update amends the code to allow and create entries without a `nightly` property when needed (only for ISO standards for now). The code also retrieves the name of the group that develops an ISO standard. This is a BREAKING CHANGE because the `nightly` property used to be mandatory. Projects that expect to find a `nightly.url` property need to be updated to only look at the root `url` property or to skip the entry altogether. First ISO spec added to the list is JPEG XL, which will appear as: ```json { "url": "https://www.iso.org/standard/85253.html", "seriesComposition": "full", "shortname": "iso18181-2", "series": { "shortname": "iso18181-2", "currentSpecification": "iso18181-2", "title": "Information technology — JPEG XL image coding system — Part 2: File format", "shortTitle": "JPEG XL: File Format" }, "shortTitle": "JPEG XL: File Format", "organization": "ISO/IEC", "groups": [ { "name": "ISO/IEC JTC 1/SC 29", "url": "https://www.iso.org/committee/45316.html" } ], "title": "Information technology — JPEG XL image coding system — Part 2: File format", "source": "specref", "categories": [ "browser" ], "standing": "good" } ``` Worth noting: the absence of a `nightly` property means that there is no place to store the status of the spec, which could in theory be "Under development" or "Published" for ISO specs (there are additional stages in the ISO process but they are probably not worth capturing in any case). An alternative would be to have a `nightly.status` property, but that seems clumsy.
tidoust
added a commit
that referenced
this issue
Feb 28, 2024
This adds the GIF and JPEG specifications to the list, as requested in #1089. For GIF, the most canonical URL is the specification published under `w3.org`, consistent with Specref and Wikipedia. The notion of group does not mean much for the GIF spec. Also, the link to the CompuServe website seems a bit wrong, but a URL is needed... For JPEG, the usual reference is to the interchange format (JFIF). A PDF version of the 1992 spec exists under `w3.org` at: https://www.w3.org/Graphics/JPEG/jfif3.pdf That is the spec that Specref returns for JPEG. That said, JPEG is published and maintained by ISO/IEC under the name `iso10918-5`: https://www.iso.org/standard/54989.html That spec (and name) is used in the list instead of the PDF version because it provides a more official entry point. If we want to record the public version from 1992 somewhere, a new "JPEG" or "JPEG-1992" entry could perhaps be created.
tidoust
added a commit
that referenced
this issue
Feb 28, 2024
This adds the GIF and JPEG specifications to the list, as requested in #1089. For GIF, the most canonical URL is the specification published under `w3.org`, consistent with Specref and Wikipedia. The notion of group does not mean much for the GIF spec. Also, the link to the CompuServe website seems a bit wrong, but a URL is needed... For JPEG, the usual reference is to the interchange format (JFIF). A PDF version of the 1992 spec exists under `w3.org` at: https://www.w3.org/Graphics/JPEG/jfif3.pdf That is the spec that Specref returns for JPEG. That said, JPEG is published and maintained by ISO/IEC under the name `iso10918-5`: https://www.iso.org/standard/54989.html That spec (and name) is used in the list instead of the PDF version because it provides a more official entry point. If we want to record the public version from 1992 somewhere, a new "JPEG" or "JPEG-1992" entry could perhaps be created. Schema and logic adjusted to allow ".txt" filenames (should not break anything) for the GIF entry.
tidoust
added a commit
that referenced
this issue
Feb 29, 2024
This adds 2 additional specifications developed by the Khronos Group, as requested in #1089, and adjusts the code that was a bit too specific to WebGL specs and extensions accordingly. The notion of "Working Group" within the Khronos Group appears somewhat informal, but the terminology is used in the page that lists Working Group officers at least: https://www.khronos.org/about/working-group-officers/ Issue #1089 mentions GLSL, and not OpenGL **ES** Shading Language, but the latter is what WebGL uses, and so should be what browsers implement. The name `ESSL` is the official name for the ES variant, see: https://github.com/KhronosGroup/GLSL That repository only contains extensions and the issue tracker for the GLSL and ESSL specifications, but not the actual specifications. I did not set the `nightly.repository` property as a result (but that may be up for debate).
tidoust
added a commit
that referenced
this issue
Feb 29, 2024
This adds 2 additional specifications developed by the Khronos Group, as requested in #1089, and adjusts the code that was a bit too specific to WebGL specs and extensions accordingly. The notion of "Working Group" within the Khronos Group appears somewhat informal, but the terminology is used in the page that lists Working Group officers at least: https://www.khronos.org/about/working-group-officers/ Issue #1089 mentions GLSL, and not OpenGL **ES** Shading Language, but the latter is what WebGL uses, and so should be what browsers implement. The name `ESSL` is the official name for the ES variant, see: https://github.com/KhronosGroup/GLSL That repository only contains extensions and the issue tracker for the GLSL and ESSL specifications, but not the actual specifications. I did not set the `nightly.repository` property as a result (but that may be up for debate). glTF is not added to the "browser" category because browsers do not directly support glTF today.
|
The list now contains the formats identified in this issue. A couple of notes:
I'm closing the issue accordingly. Additional formats may be worth adding. Let's handle them through dedicated issues and pull requests! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Via #1008. Consider adding font/image/media formats commonly supported on the web. The main difficulty is that these specifications do not follow a well-known format.
The list includes:
The text was updated successfully, but these errors were encountered: