CFC: Transition the June 2019 DOM Standard Review Draft to CR

[LJWatson]

This is a Call For Consensus (CFC) to publish the June 2019 DOM Standard Review Draft as a Candidate Recommendation (CR).

Wide and horizontal review of the DOM Standard Review Draft was requested in August 2019 on a three month turnaround. Requests were sent to:

• APA WG (accessibility)
• HTML WG
• I18n WG (internationalisation)
• Privacy IG (privacy)
• TAG (technical architecture)
• W3C Chairs
• WebApps WG
• Web Security IG (security)

The requests and responses were tracked in issue #4. At the end of the review period no issues had been raised that block transition of the DOM Standard Review Draft to CR.

MDN Browser Compatibility Data was used to demonstrate implementation experience for the features of the DOM Standard Review Draft, and the results verified using Web Platform Tests.

There is one feature in the DOM Standard Review Draft that does not have two implementations: AbstractRange.

Per the Memorandum of Understanding between W3C and WHATWG, this will be indicated in the published CR as follows:

• The Status section of the CR will state that for W3C purposes AbstractRange is considered non-normative.
• A scripted annotation will be added into the margin of the CR at the point where the AbstractRange interface is defined, to indicate that for W3C purposes it is non-normative.

If you support the proposal to transition the June 2019 DOM Standard Review Draft to CR you do not need to do anything, but you are welcome to add a "thumbs up" to this comment or add a comment of support to this issue if you would like.

If you do not support the proposal please add a comment to this issue and explain your reason as clearly as possible.

This CFC will be open until the end of the day on Friday 22 November 2019. If you want to respond please do it before then.

Thank you.

[domenic]

A scripted annotation will be added into the margin of the CR at the point where the AbstractRange interface is defined, to indicate that for W3C purposes it is non-normative.

To be clear, the annotation would not be W3C/CR-specific, but instead a caniuse annotation, which the CR endorsement can mention the consequences of. See the MoU section in question:

As the W3C process requires implementation experience to advance beyond CR, while WHATWG process requires only implementation commitments, Review Drafts will include feature implementation status annotations in the margin. The granularity of the annotations should be such that they can be reasonable indicators of which features have implementation experience. The status indicators will be sourced from an external site or set of test cases, such as caniuse or wpt.fyi. The CR endorsement will mention that all features that do not have two implementations according to the annotations are at risk. The PR and REC endorsement will mention that all features which do not have two implementations are considered informative, not normative, for W3C PR/REC purposes. The necessary annotations already exist in the HTML Living Standard, and the mechanism will be added to the DOM Living Standard. WHATWG will welcome pull requests to add further annotations as needed. WHATWG will not add manually managed or finer-grained annotations for this purpose. W3C and WHATWG will collaborate on tooling to enhance the annotations.

[LJWatson]

This CFC received multiple expressions of support (thank you) and no objections. We will now request transition of the June 2019 DOM Standard review draft to CR on behalf of the HTML WG.

[sideshowbarker]

https://domspec.herokuapp.com/ is a draft of the DOM spec with annotations injected.

See in particular https://domspec.herokuapp.com/#interface-abstractrange

I believe that when we eventually publish an actual DOM Review Draft with those annotations, they should be sufficient for satisfying the “Review Drafts will include feature implementation status annotations in the margin” requirement in the MoU.

---

To be clear, the annotation would not be W3C/CR-specific, but instead a caniuse annotation, which the CR endorsement can mention the consequences of.

It turns out that it’s not possible to automate generating the necessary annotation for the AbstractRange section of the DOM spec using the existing features in Bikeshed to pull the data from Can I Use. See speced/bikeshed#1553 and Fyrd/caniuse#5187.

So instead I’ve been working on implementing a new feature for Bikeshed the pulls the data from MDN by way of https://w3c.github.io/mdn-spec-links/, so that Bikeshed-generated specs will have MDN annos similar to the ones the HTML spec has, and similar to the ones that Respec has a feature for generating.

speced/bikeshed#1564 is the Bikeshed PR with the patch that adds the MDN feature, and https://domspec.herokuapp.com/ shows the current output that patch produces for the DOM spec.

[sideshowbarker]

https://domspec-w3c-ready.herokuapp.com/ is a draft with the W3C logo and status bits added