CR Request for DOM Review Draft — Published 15 June 2020 -- shortname: DOM

[siusin]

Document title, URLs, estimated publication date

DOM Review Draft — Published 15 June 2020
https://www.w3.org/TR/2021/CR-DOM-20210525/

Abstract

DOM defines a platform-neutral model for events, aborting activities, and node trees.

Status

This Living Standard is also endorsed as a W3C Candidate Recommendation under the terms of the Memorandum of Understanding. For those purposes, it contains the following metadata:

Canonical version / latest Living Standard:
https://dom.spec.whatwg.org/
This version:
https://dom.spec.whatwg.org/review-drafts/2020-06/
W3C Version Mnemonic:
DOM 2020-06
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

The W3C HTML Working Group co-produced this document under the W3C Patent Policy and the 15 September 2020 W3C Process Document. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Link to group's decision to request transition

w3c/htmlwg#16

Changes

• Add StaticRange constructor
• Use self.origin instead of document.origin
• Define ParentNode's replaceChildren()
• Avoid enqueuing a tree mutation record when there is no mutation
• Use self.origin instead of document.origin
• Replace child text content change steps
• Address infinite loop in TreeWalker's nextNode()
• Change add/remove event listener behavior for service workers
• Define the onabort event handler IDL attribute
• Add the DOM XPath interfaces
• Add StaticRange constructor
• Catch errors while upgrading customized built-in elements
• Avoid enqueuing "disconnectedCallback" on detached custom elements
• Add delegatesFocus to attachShadow and flag to ShadowRoot
• Define the onslotchange event handler IDL attribute
• Run adopt as part of insert

Requirements satisfied

None.

Dependencies met (or not)

None.

Wide Review

w3c/htmlwg#14
No substantive issues.

Issues addressed

There are still open issues for DOM, but the editors believe this review draft is good enough to move to CR.

Formal Objections

None.

Implementation

No at-risk features for this version.

Patent disclosures

https://www.w3.org/2004/01/pp-impl/44556/status

[siusin]

@plehegar
Is there any change to the URL of the MoU? Is it ok we still use the 2019 MoU for this publication?

[plehegar]

yes, since the new MoU hasn't been ratified yet.

[swickr]

Snapshot of current state of reactions to w3c/htmlwg#16

[swickr]

Transition approved.

[siusin]

@sideshowbarker could you add a W3C status to the review draft please? see the draft CR status approved by the director.

[siusin]

@sideshowbarker ping?

[sideshowbarker]

Note that we have one at-risk feature: AbortSignal.abort() https://dom.spec.whatwg.org/#ref-for-dom-abortsignal-abort①
(I had previously said we had none, but found this after doing some manual doublechecking)

And as soon as I have the W3C-ready version of https://dom.spec.whatwg.org/review-drafts/2020-06/ wrapped up, I’ll post another comment here.

(I got stalled on battling with some Bikeshed stuff, and some quirks of the WHATWG build tools — e.g., the build for the WHATWG review drafts makes them get output without MDN annotations, but we need MDN annotations in the W3C-ready review drafts, so it’s necessary to manually change options and re-build before the W3C status section can be added, but then the annotations don’t get styled correctly because due to the fact we’re starting from an older revision, there’s a missing stylesheet link that needs to be manually re-added, etc etc…)

[sideshowbarker]

Note that we have one at-risk feature: AbortSignal.abort() https://dom.spec.whatwg.org/#ref-for-dom-abortsignal-abort①
(I had previously said we had none, but found this after doing some manual doublechecking)

Update: It turns out I was actually right the first time, when I said we had no at-risk features. Further investigation today reveals that AbortSignal.abort() was implemented in WebKit back in March — and so along with the implementation in Firefox, that gives us the two implementations we need in order to formally consider the feature not at-risk.

[sideshowbarker]

The DOM 2020-06 review draft now has the changes necessary to make it ready for Candidate Recommendation publication:

https://dom.spec.whatwg.org/review-drafts/2020-06/

[plehegar]

this is not waiting on the Director, who already approved. this is waiting for announcement, which is part of the publication. @siusin , I believe this is on you.

[sideshowbarker]

Well, even though I somewhat hesitate to point this out, in just the last couple of days I’ve come across a feature for which the spec text is in a state such that I believe our process obligates us in principle to list it as at-risk in this CR draft.

The feature is element.getAttributeNames(), and the state of the spec text is that its requirements are currently stated as:

The getAttributeNames() method steps are to return the qualified names of the attributes in this’s attribute list, in order; otherwise a new list.

…and the specific problem is that in no browser engines does getAttributeNames() actually return qualified names — instead for attributes with qualified names (that is, attributes that are in a namespace), all browser engines return the un-qualified local names of the attributes (just as they would for attributes that are not in a namespace).

There’s a spec issue about this at whatwg/dom#985 and I believe it’s most likely to be resolved by the spec text changing to instead say:

The getAttributeNames() method steps are to return the local names of the attributes in this’s attribute list, in order; otherwise a new list.

…and then all browser engines would be in conformance with the spec (or in other words, the spec would be requiring what browsers actually do, rather the requiring something that none of them actually do).

However, even if that change were made to the spec sources today, that wouldn’t resolve the problem for our purposes — since we’re not taking the living-standard version of the source to CR, but instead taking the https://dom.spec.whatwg.org/review-drafts/2020-06/ spec snapshot to CR.

So I guess I need to take out the part of Status section of the https://dom.spec.whatwg.org/review-drafts/2020-06/ that says this:

This specification has no features which are considered at-risk for the purpose of the W3C Candidate Recommendation.

…and I need to replace that with this:

The following features are at-risk for the purpose of the W3C Candidate Recommendation:

• element.getAttributeNames()

And since that during our overall transition of this spec snapshot to ultimate Recommendation, there’s pretty much zero chance that two browser engines are going to change their behavior to start returning qualified names from element.getAttributeNames(), then I think we can anticipate that in the published Recommendation, we’re going to need to list element.getAttributeNames() as “non-normative for the purpose of this Recommendation”.

Listing such a fundamental feature as non-normative seems pretty odd on the face of it. But there we have it.

Or else somebody please correct me if I’m mistaken about what our process requires. I’d be very happy to be wrong here.

[sideshowbarker]

As a follow-up to my previous comment, I guess I should point out that the requirements for element.getAttributeNames() didn’t change after the time we took the https://dom.spec.whatwg.org/review-drafts/2019-06/ snapshot to Rec.

So at https://dom.spec.whatwg.org/review-drafts/2019-06/#dom-element-getattributenames, our current DOM Rec has exactly the same (wrong) requirement — but of course the Status section of that Rec doesn’t call out that feature as “non-normative for the purpose of this Recommendation” (because we didn’t catch this until now).

So it’s unclear to me what if anything our process now requires us to do for that previously published Rec.

I’d certainly personally prefer that the answer be, We don’t need to do anything for that at this point.

I understand at least that after we bring that https://dom.spec.whatwg.org/review-drafts/2020-06/ snapshot to Rec, we can (or must, per the process requirements?) mark that previous Rec as superseded, with a reference to the newer Rec.

But in fact our process obligations in this case require something more for dealing with the current Rec than just taking some action after we complete the current transition, then I’d like to know what else needs to be done, so I can do it.

[siusin]

Thanks @sideshowbarker .

@swickr @plehegar what's your opinion on this feature?

We'll hold the publication for today.

/cc @deniak

[sideshowbarker]

@siusin Actually, this turned out to be another fire drill.

Basically, I had just misread the spec requirements.

So to be clear: All browsers do in fact conform to the spec requirements for element.getAttributeNames() — that is, they do return the qualified names, as the spec requires.

Therefore, the This specification has no features which are considered at-risk for the purpose of the W3C Candidate Recommendation statement in the draft is in fact correct.

The main reason for my confusion was that in testing, I had thought I was properly using element.setAttributeNS() to set that qualified names, but I actually wasn’t. So while I wasn’t getting back what I expected, I was in fact getting back what I had actually specified.

So anyway, the good news is that we can go ahead with publication. Sorry for the unnecessary noise and alarm.

[plehegar]

https://www.w3.org/TR/2021/CR-dom-20210608/