Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tons of new specs #1008

Closed
BenjaminAster opened this issue Jul 13, 2023 · 9 comments
Closed

Tons of new specs #1008

BenjaminAster opened this issue Jul 13, 2023 · 9 comments

Comments

@BenjaminAster
Copy link

I was working on my own browser spec collection for myself, using w3c/groups as a starting point and manually adding lots of stuff, partially by looking at the interfaces in the window object in Chrome's JavaScript console – until I realized the existence of this repo and webref. This has the disadvantage of having wasted a lot of time, but also the advantage of being able to diff my spec list with yours and finding the differences.

Here are specs that I believe should be added to this repo:

Specs that might be too unofficial or unmaintained to be in browser-specs, or that don't technically match the criteria

Specs that I think should be removed from browser-specs:

Various other things:

Could some W3C person please either add the specs and modifications themselves or give me the OK and tell me which specs not to add so I can make a PR myself?
@tidoust
Copy link
Member

tidoust commented Jul 14, 2023

Many thanks for the list, @BenjaminAster! I'll need some time to review the list in detail (I don't think I'll have time in the next couple of weeks in particular). Initial thoughts below.

The scope of browser-specs has evolved over time, and continues to evolve, but the list of specs it contains is not meant to be exhaustive. Rather, roughly, the list of specs that have "enough traction" to be considered part of the web platform, or that people need for cross-referencing purpose. We tend not to add early proposals or specs flagged as unofficial.

Specs in browser-specs get crawled by Reffy to maintain Webref, which in turn gets used to maintain IDL extracts in Web Platform Tests, cross-reference databases in spec authoring tools, CSS grammar parts in MDN pages, etc. Before we add a spec, we tend to ask ourselves: why is the spec needed? In many cases, the answer is straightforward. In some cases, typically for proposals raised in Community Groups, that's a judgment call, and we try to integrate feedback from the consumers of the list that we're aware of. If you can tell us what you're trying to achieve with the list, we might better be able to take your perspective into account.

Specs that we identified and that, we feel, are in the "too early to add" category get added to the monitor.json file, and reviewed every few months. Specs that, we believe, won't ever be added are listed in ignore.json. Some of the specs that you suggest adding to the list are in these files, e.g., WebXR Marker Tracking Module, Handwriting recognition, Web Smart Card API, Web Monetization, etc.

We also do not add specs that have been abandoned or got merged into some other spec, e.g., execCommand, Provisional Identifiers for WebRTC's Statistics API, Visual Viewport (merged into CSSOM View).

There remains a number of specs in your list that we missed, or that could perhaps be added to the list!

Quick comments on some of the specs that you'd like to see removed:

  • Writing Promise-Using Specifications, W3C Patent Policy, W3C Process Document, A Method for Writing Testable Conformance Requirements are in the list for cross-referencing purpose. They do not have "browser" in their "categories" property to distinguish them from specs that are more directly targeted at browser implementation.
  • Document Object Model (DOM) Level 2 Style Specification is also in the list for cross-referencing purpose (be that from also outdated specs). It has a "standing": "discontinued" property to clarify that it has been discontinued.
  • The CSS working group tends to prefer references to CSS2.1 (a Recommendation) than to CSS2.2 (a Working Draft)

Quick comments on "Various other things":

  • Where do you get the "2.1" and "2.2" from for SVG? I'm not clear that this concept exists in the SVG Working Group. I don't know yet what SVG Next is supposed to be.
  • The URL of the Editor's Draft of the CSS Animation Worklet spec url has not yet been updated in the published version of the spec: https://www.w3.org/TR/css-animation-worklet-1/ That is the source of truth for browser-specs.
  • The missing level for CSS Style Attributes is also because the published spec does not have one (groups are not always consistent with themselves ;)): https://www.w3.org/TR/css-style-attr/
  • Similar for WebCrypto, the WebAppSec WG took over maintenance of the spec but has not yet published a new version of the spec: https://www.w3.org/TR/WebCryptoAPI/. This probably applies to other specs as well (Encrypted Media Extensions comes to mind).

@BenjaminAster
Copy link
Author

Thanks! Sorry, I didn't catch a few things here, especially stuff like the two JSON files you mentioned, and the "categories" array. And since the repo description says it's about "specifications used to build web browsers", I thought maybe the documents like "Writing Promise-Using Specifications" are out of scope for this list.

My concrete use case is that I'm building basically something like a frontend for webref – an index and search engine for specs, CSS properties, JS interfaces & functions, HTML elements etc. And for that, I do want to have the bleeding-edge things like handwriting recognition, many of which are already implemented (experimentally) in Chromium, so that when I stumble across e.g. some JS interface in the wild or when I explicitly want to get to the definition of something (including experimental Chromium stuff), I can simply type it in there and be linked to the spec. But if they're not in scope for this repo, that's ok, I'll simply augment this list with some specs that I crawl myself.

  • execCommand: The HTML spec explicitly states that the execCommand() method is defined in [EXECCOMMAND]. Has it really been abandoned or merged into another spec?
  • DOM Level 2 & CSS2.1: Ok, I understand. I'll exclude them in my project then.
  • SVG: Sorry, I mixed the numbers here (probably confused with CSS2), the Readme for the SVGWG repo lists the svg2-draft version as "SVG 2" and the svg-next one as "SVG 2.1" (although the Readme hasn't been updated in five years). The svg-next version simply has some new stuff like the <mesh> element, but all of them don't have any actual browser implementation I thinks, so yeah, the nightly URL should probably stay as svg2-draft.
  • Animation Worklet, Style Attributes & Crypto: Oh, ok, got you! So you're simply taking the "Editor's draft" URL and the WG that the TR spec links to.

@tidoust
Copy link
Member

tidoust commented Aug 30, 2023 •
edited
Loading

Here is a first split of the lists into lists of specs to consider, and lists of specs that browser-specs already handles one way or the other.

Specs that are not in any list and should be considered for inclusion somewhere:

Ignored, typically because they are not targeted at browsers, but perhaps worth re-considering now that browser-specs is more open to specs that don't specifically target browsers:

Need to mark as obsoleted by ECMAScript spec:

In the list already:

In the monitor list for now for some reason. These specs get reviewed for inclusion every few months:

Ignored on purpose (e.g., no longer worked on, not a real proposal, incorporated in another spec):

Specs that don't follow a well-known format and cannot be added for now even if we wanted to:

@dontcallmedom
Copy link
Member

My thoughts on some of the specs:

* [ ]  Model Loader API: https://webmachinelearning.github.io/model-loader/

I think work on this has stopped, so I don't think it's worth adding (but will double-check)

* [ ]  Payment Method Encryption: https://w3c.github.io/webpayments-crypto/
* [ ]  Tokenized Card Payment: https://w3c.github.io/webpayments-methods-tokenization/
* [ ]  The MerchantValidationEvent interface: https://w3c.github.io/merchant-validation/

I think these have been abandoned (the activity on the repos has been to mark them as "not exposed"; it may be worth getting them more explicitly marked as abandoned though)

* [ ]  QUIC API for Peer-to-peer Connections: https://w3c.github.io/p2p-webtransport/
* [ ]  QUIC API for Client-to-Server Connections: https://w3c.github.io/p2p-webtransport/cs.html

Not sure how likely these would get implemented in the short term if at all.

* [ ]  Object RTC (ORTC) API for WebRTC: https://draft.ortc.org/

I think there is no expectation this will get implemented in browsers at this point.

Ignored, typically because they are not targeted at browsers, but perhaps worth re-considering now that browser-specs is more open to specs that don't specifically target browsers:

* [ ]  Mathematical Markup Language (MathML) Version 4.0: https://w3c.github.io/mathml/
* [ ]  XML Entity Definitions for Characters: https://w3c.github.io/xml-entities/
* [ ]  Digital Publishing WAI-ARIA Module 1.1: https://w3c.github.io/dpub-aria/
* [ ]  Digital Publishing Accessibility API Mappings 1.1: https://w3c.github.io/dpub-aam/

These make sense to me.

* [ ]  Web Payments HTTP Messages 1.0: https://w3c.github.io/webpayments-http-messages/

Another case of an abandoned Web Payment spec.

Specs that don't follow a well-known format and cannot be added for now even if we wanted to:

* WebP Container Specification (implemented in all three browser engines!): https://developers.google.com/speed/webp/docs/riff_container

* WebP Lossless Bitstream: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification

* COLR — Color Table: https://learn.microsoft.com/en-us/typography/opentype/otspec191alpha/colr

* APNG Specification (implemented in all three browser engines!): https://wiki.mozilla.org/APNG_Specification (but note that the list has the newer [PNG spec](https://w3c.github.io/PNG-spec/))

FWIW, each of these are referenced by an existing spec in web-specs (epub33 for WebP, css-fonts-4 for COLR, and HTML for APNG).

tidoust added a commit that referenced this issue Aug 30, 2023
@tidoust
Flag TC39 proposals merged into main spec as obsolete
c69f1c5 
Via #1008

The update also includes specs that have already been merged into the 2024
edition of the EcmaScript specification, and internationalization proposals
that have been merged into the 2024 edition of the ECMA-402 specification.
@tidoust tidoust mentioned this issue Aug 30, 2023
Merged
tidoust added a commit that referenced this issue Aug 30, 2023
@tidoust
Flag TC39 proposals merged into main spec as obsolete (#1037)
2f70714 
Via #1008

The update also includes specs that have already been merged into the 2024
edition of the EcmaScript specification, and internationalization proposals
that have been merged into the 2024 edition of the ECMA-402 specification.
tidoust added a commit that referenced this issue Aug 30, 2023
@tidoust
Add Audio Session and MSE registry/registrations
3d21584 
Via #1008

All specs are developed/maintained by the Media WG.
@tidoust tidoust mentioned this issue Aug 30, 2023
Merged
tidoust added a commit that referenced this issue Aug 30, 2023
@tidoust
Add Audio Session and MSE registry/registrations
2e541c1 
Via #1008

All specs are developed/maintained by the Media WG.
tidoust added a commit that referenced this issue Aug 30, 2023
@tidoust
Add Audio Session and MSE registry/registrations (#1038)
bcea1f8 
Via #1008

All specs are developed/maintained by the Media WG.
@BenjaminAster
Copy link
Author

BenjaminAster commented Aug 30, 2023 •
edited
Loading

@tidoust Thanks for looking into the specs! Some time has passed since my original comment; here are a few things I want to add or comment on:

@tidoust
Copy link
Member

tidoust commented Aug 31, 2023

  • execCommand: As mentioned in my second comment, I'm not convinced that execCommand should be excluded from browser-specs. I know it's an extremely incompatible mess, and the spec is in early unofficial draft status etc., but it's referenced by the HTML spec, and if you were to build a new browser today, you would have to follow the spec in order to be web compatible.

The spec selection criteria that we try to follow are arguably fuzzy but start with "The spec is stable or in development". I would prefer things to be in a better shape but, for better or worse, execCommand is neither stable nor in development. The spec itself starts with "This spec is incomplete and it is not expected that it will advance beyond draft status. [...] The features described in this document are not implemented consistently or fully by user agents, and it is not expected that this will change in the foreseeable future".

  • MathML 4: Many things from MathML that are not in MathML-Core are implemented in Firefox or WebKit.

Adding MathML to the list makes sense, although I would add it without "browser" in its "categories" property. MathML-Core is supposed to represent the interoperable subset of MathML implemented in browsers. If there are many things implemented in browsers from MathML that are not in MathML-Core, the best would be to report them in the MathML-Core repository.

  • XML, XML Namespaces, XPath & XSLT: I guess it's intentional they are left out since historically, they were not meant primarily for browsers? All browsers do support these, and they are required for the de facto web to function (SVG, XHTML, DOMParser, XSLTProcessor, document.evaluate(), etc.).

Ah, I would tell the history the other way round ;) They were meant for browsers, got implemented, but browser implementations stalled at version 1.0, while XPath and XSLT evolved to version 3.1. In other words, the latest versions are not what ships in browsers. I need to think some more on how to represent these specs in the list.

One of the spec selection criteria is "The spec is being developed by a well-known standardization or pre-standardization group". This is meant to avoid spending time listing specs proposed by individuals until they have at least started their journey on the standardisation road.

Also the Chrome Status page says "No active development", which should signal that this proposal is not currently being implemented in Chromium.

To be considered. We usually add TC39 proposals when they reach stage 3. The Source Map spec says it is at stage 0.

  • GLSL: Shading language for WebGL.
  • glTF: File format for 3D models. AFAIK this is implemented in WebKit for the element.
  • Media formats? Various more image, video, audio, font, etc. formats are not in browser-specs. Should they be added or is this out of scope? Or is it that you would but can't add them like with WebP?

That extends the scope a bit, but it would make sense overall. We're currently indeed somewhat stuck because the code won't know how to extract meaningful info from these specs, as they follow a different structure (some of them likely don't have an HTML representation either).

Side note: the <model> element is a bit like <img> and could be used to render models in glTF, USD, etc. I believe that the current early implementation in WebKit only supports USD for now though.

@BenjaminAster
Copy link
Author

The WICG also just published a new draft specification "Web Preferences API": https://wicg.github.io/web-preferences-api/.

@tidoust
Copy link
Member

tidoust commented Sep 8, 2023

The WICG also just published a new draft specification "Web Preferences API": https://wicg.github.io/web-preferences-api/.

Thanks! For info, a job runs weekly to report new specs developed in well-known groups (see for instance #1044 for this week's report). Job can miss proposals, especially when they appear among others in a single repository. It should report that proposal next time it runs.

tidoust added a commit that referenced this issue Oct 10, 2023
@tidoust
Some updates based on #1008
1c137cd 
- Add WebXR Plane Detection
- Add WebXR Meshing API
- Add WebXR Mesh Detection Module
- Add WebBluetooth Scanning API
- Add Managed Configuration API
- Add MathML4, as non browser spec
- Monitor Private Aggregation API (pending w3c.json at least)
- Ignore a few additional specs (not required as these specs are not found
but that makes the rationale explicit)
tidoust added a commit that referenced this issue Oct 11, 2023
@tidoust
Some updates based on #1008 (#1082)
366134e 
- Add WebXR Plane Detection
- Add WebXR Meshing API
- Add WebXR Mesh Detection Module
- Add WebBluetooth Scanning API
- Add Managed Configuration API
- Add MathML4, as non browser spec
- Monitor Private Aggregation API (pending w3c.json at least)
- Ignore a few additional specs (not required as these specs are not found
but that makes the rationale explicit)
tidoust added a commit that referenced this issue Oct 12, 2023
@tidoust
More updates based on #1008
f6b7f07 
- Add No-Vary-Search proposal
- Add iframe Credentialness
- Add DPUB ARIA (as non-browser spec)
- Add DPUB AAM (as non-browser spec)
- Monitor p2p-webtransport pending clarification of status
- Ignore Math AAM (no longer worked on)
- Update ignore rationale for webpayments-http-messages
- Drop EPUB Working Group from ignore list
tidoust added a commit that referenced this issue Oct 12, 2023
@tidoust
More updates based on #1008
9952b1f 
- Add No-Vary-Search proposal
- Add DPUB ARIA (as non-browser spec)
- Add DPUB AAM (as non-browser spec)
- Monitor iframe Credentialness (pending w3c.json fix)
- Monitor p2p-webtransport pending clarification of status
- Ignore Math AAM (no longer worked on)
- Update ignore rationale for webpayments-http-messages
- Drop EPUB Working Group from ignore list
This was referenced Oct 12, 2023
Open
Closed
Closed
tidoust added a commit that referenced this issue Oct 12, 2023
@tidoust
More updates based on #1008 (#1086)
5b37b09 
- Add No-Vary-Search proposal
- Add DPUB ARIA (as non-browser spec)
- Add DPUB AAM (as non-browser spec)
- Monitor iframe Credentialness (pending w3c.json fix)
- Monitor p2p-webtransport pending clarification of status
- Ignore Math AAM (no longer worked on)
- Update ignore rationale for webpayments-http-messages
- Drop EPUB Working Group from ignore list
@tidoust tidoust mentioned this issue Oct 12, 2023
Merged
@tidoust
Copy link
Member

tidoust commented Oct 13, 2023

Most of the specs listed in this issue have now been added to the main list, the monitoring list or the ignore list. I created follow-up issues to deal with the remaining (which require a bit more investigation or code changes): #1087, #1088, #1089.

I'm closing this issue as a result. Feel free to raise additional issues if you feel that we should revisit some of choices we made. And thanks again for the input, @BenjaminAster!

@tidoust tidoust closed this as completed Oct 13, 2023
@tidoust tidoust mentioned this issue Jul 29, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dontcallmedom @tidoust @BenjaminAster