w3c / dom

Moved to https://dom.spec.whatwg.org/
60 stars 18 forks source link

Merge Shadow DOM into DOM 4.1? #150

Closed chaals closed 6 years ago

chaals commented 7 years ago

Update Aug 29: This is a formal call for consensus to merge Shadow DOM into the DOM 4.1 spec.

Silence will be assumed to indicate acceptance of the outcome, but positive responses are preferred and should be provided before 17 September.

To support the proposal please add a thumbs up, to disagree please provide an explanation of why.

yongsheng commented 7 years ago

thanks, chaals. please raise your concerns if any problem.

yongsheng commented 7 years ago

If no objection, it'll be into 4.1 .

awwright commented 6 years ago

As a member of the general public, I'd just note I prefer to see modular specifications that build on each other, where that's logical. (However, the documents should serve a specific purpose. A "Shadow DOM" specification is appropriate, a "Level n" document that requires comprehending n-1 levels of documents below it is not.)

DOM is used more than just Web browsers, however a combined document seems to favor browser user-agents over other kinds of user-agents or DOM implementations.

yongsheng commented 6 years ago

@awwright reasonable. the shadow dom spec is not directly merged into DOM 4.1. It's still be a standalone document. 4.1 spec will introduce related statements by considering the conditions when user agents support shadow dom.

Thanks for your comments.

yongsheng commented 6 years ago

@chaals has a different opinion on this.

chaals commented 6 years ago

For closure (and my apologies for the delayed response): Given support here and elsewhere (including from the effectively former editor of Shadow DOM) we will go ahead with the merge.

chaals commented 6 years ago

@awwright we have an open Call for Consensus on stopping development of the standalone Shadow DOM spec, and merging its content into the relevant specifications - primarily DOM.

Note that DOM 4.1 is a standalone specification, in the sense that it doesn't rely on knowing its predecessors. The DOM family of specs is somewhat modularised - there are various smaller APIs and things like UI Events that are separate, but Shadow DOM seems like a bad choice for an extra spec.

In addition there is nobody working on the spec itself, which means it is out of date - and my personal opinion is that we would be better off with an "explainer" than maintain a completely separate spec for people who currently know DOM and want to learn about this one new bit. People who come to the DOM spec for the first time are (again, in my opinion) better off having the relevant stuff from Shadow DOM included.