You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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,”
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.
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.
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.
The text was updated successfully, but these errors were encountered: