search

w3c / browser-specs

A machine-readable list of Web specifications
Other
225 stars 45 forks source link

Tons of new specs #1008

Closed BenjaminAster closed 1 year ago

BenjaminAster commented 1 year ago

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 commented 1 year ago

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:

Quick comments on "Various other things":

BenjaminAster commented 1 year ago

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.

tidoust commented 1 year ago

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 commented 1 year ago

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).

BenjaminAster commented 1 year ago

@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 commented 1 year ago
  • 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 commented 1 year ago

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

tidoust commented 1 year ago

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 commented 1 year ago

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!