Skip to content
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.

Google Formal Objection to CR Transition of DOM4.1 #177

Open
henceproved opened this issue Apr 11, 2018 · 3 comments
Open

Google Formal Objection to CR Transition of DOM4.1 #177

henceproved opened this issue Apr 11, 2018 · 3 comments

Comments

@henceproved
Copy link

Google raises a Formal Objection to the transition of DOM4.1 to Candidate Recommendation.

We would like to reiterate our statement on the CfC that this is particularly bad timing for this transition. W3C has noted before that two specs covering the same subject with normative differences between them is a design flaw. Given that there is an opportunity to change this design flaw, it is not appropriate to advance the DOM4.1 spec at this time. The argument provided by the chairs was that the charter was approved, hence this transition is justified. However, there are several dependencies that have changed since the charter was approved, and those should be reported and considered by the chairs, as per W3C Process.

As per the W3C Process document, the following are some of W3C’s requirements for advancement to candidate recommendation. Our concerns on those inline.

  • must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,

    • The Working Group charter notes the requirement of multiple implementations. In its current state, Chrome will not implement the DOM4.1 spec, and is not aware of any other browser engine that will do so. There are considerable differences between the W3C DOM 4.1 and WHATWG DOM Living Standard (including but not limited to: use of invalid Web IDL, event dispatch, shadow DOM integration, custom elements integration, ranges, and tree traversal), which is what Chrome implements. Those verifiable differences will show divergence from DOM4.1 in implementations.
    • The charter also states that “A comprehensive test suite for all features of a specification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed before transition to Candidate Recommendation”. The current test suite tests the WHATWG DOM LS, and is not appropriate or comprehensive for the purpose of testing W3C DOM 4.1 (for instance, any test that uses KeyboardEvent or TouchEvent does not reflect how events are specified in W3C DOM 4.1).
  • CR documents are expected to set exit criteria, which is missing from this proposed transition, so reviewers will not have a chance to properly evaluate transitions in this regard.

In addition to the CR transition requirements, W3C process details guidance on building consensus and decision making.

  • “Where unanimity is not possible, a group should strive to make consensus decisions where there is significant support and few abstentions”
    This proposal did not have “significant support”. There was only one argument of support registered and that was from a member of W3M, not from a working group member. There were six statements of dissent. Even considering the votes, 14 to 12 cannot be considered significant support with little opposition.
  • “Groups should favor proposals that create the weakest objections.”
    In this case, support seems weak and objections seem strong. As stated earlier in this FO, and on the CfC, this is not a good time for this transition. The Working Group should take some time to analyze the normative differences between the W3C DOM4.1 and WHATWG DOM, and work to resolve them, with the understanding that most browser (and other) implementations do consider the WHATWG DOM the canonical version, and work to minimize differences.

With these concerns in mind, Google formally objects to this Candidate Recommendation Transition. Our biggest concern is the lack of engagement and discussion, and the absence of any attempts to resolve major differences in the Working Group from several participants.

@chaals
Copy link
Collaborator

chaals commented Apr 13, 2018

@henceproved thank you for these comments.

They outline technical areas of concern that Wide Review is intended to uncover, and which we will indeed consider carefully before making any request for transition.

We will likewise publish the proposed exit criteria. As is our working practice, they are materially the same as for the DOM 4 specification.

@othermaciej
Copy link
Member

For reference: DOM 4 apparently didn't have a CR, and thus no CR. exit criteria.

The DOM 4 PR draft said this:

The criteria for this document to enter the Proposed Recommendation stage is to have all of the features of this specification supported by a minimum of two independent and interoperable user agents. Note that if this Last Call is successful this specification will skip Candidate Recommendation and go directly to Proposed Recommendation.

It seems unlikely DOM 4.1 could meet the equivalent of those criteria as written.

@henceproved
Copy link
Author

Thanks @chaals for acknowledging the concerns raised. We look forward to having them addressed, and to reviewing the published exit criteria.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants