CfC: Move DOM 4.1 to Candidate Recommendation #175
Comments
|
Microsoft and the Edge browser team strongly objects to W3C publishing another DOM Recommendation at this point. This isn't the time to perpetuate similar but different DOM standards, and create more pain for those struggling to figure out which specs to normatively reference, test against, document, or depend on in a website. It's time to get behind a common standard and work to improve it. Now that WHATWG operates under a formal IPR and governance policy, we and many others in the community are treating the WHATWG DOM Standard is the best one to work from. The W3C DOM participants have a lot of knowledge, experience, and are encouraged to contribute to a unified DOM effort. By giving thumbs down to this CfC we're not advocating any particular vision of how to develop a common DOM standard. But we are saying that publishing a DOM 4.1 CR now would perpetuate the sub-optimal status quo rather than encouraging a more collaborative future. |
|
I agree with Mike that it is time to get behind a common standard. I have proposed to the WHATWG a partnership whereby they continue to publish their Living Standard and W3C publishes a stable Recommendation by working together. We have not yet completed the negotiations, but we are on the agenda of the AC meeting to provide an update on progress. As soon as we converge on a common point-of-view, I plan to get advice from the WebPlatform WG. While I agree with the ultimate objective of partnership with the WHATWG, I note that we are not yet there. |
|
Google would like to delay this action. Thus far, forking was accepted as IPR benefits outweighed confusion. At this point, we'd like to delay this CR in order to give the W3C and WHATWG a chance to work out the right path moving forward. |
|
I agree with @michaelchampion (and will not attempt to rephrase & repeat his argument, as that does not seem productive). |
|
We support delaying this CfC until the negotiations @jeffjaffe mentioned are completed. |
|
We agree with @michaelchampion . Having multiple competing DOM standards forked from the same source leads to confusion about which one to use, where to report problems, and where to contribute, and leads to wasted effort maintaining two versions that could have moved the web further forward if it were used on a single effort. When the competing standards disagree, it leads to real problems for implementations and web developers. We'd like to figure out how to work together on a single DOM standard, and don't think that advancing DOM 4.1 to CR now helps us towards that goal. |
|
I support this CFC |
|
I support this CFC too. |
|
I support this CFC |
|
Without my chair's hat on... We know that Apple, Google, Microsoft, and Mozilla, consider the WHATWG to be the canonical version. We don't yet know whether the other 450+ W3C member organisations that represent the wider web platform agree with this position or not though. Until such time as that is known, or an agreement is reached between the two organisations, it seems premature for either organisation to request something of the other that it isn't willing to do itself. The case for a single spec has been well made in these comments. But it is predicated on the assumption that the WHATWG version will be it, and that is not a foregone conclusion. If the W3C was to halt work on this spec as a sign of good faith, would the WHATWG be willing to reciprocate the good faith and halt work on its version also, until such time as an agreement between the two organisations is reached or rejected? |
Discussions on the W3C DOM Editor Draft can continue; it is chartered and the charter is valid. But I do believe that this is a bad time to publish, as this means requesting consensus on a topic known to be divisive, likely triggering objections, and then having to spend time and energy resolving these objections, instead of spending that time and energy working on the ongoing W3C/WHATWG negotiations. As for requesting an equivalent stop at the WHATWG, I don't think that is relevant. First, the WHATWG does not have a equivalent of W3C publishing an ED onto TR, so there's nothing to be stopped. More over, if it is supposed to be a full stop of all activities on both sides: two competing standards is bad enough, (temporarily) having none, and thus no place at all to report / discuss issues, to normatively reference, etc, would be worse.
It is not just the browser vendors that consider WHATWG DOM canonical. The vast majority of the web standards ecosystem does work with the upstream version. Even W3C DOM has WHATWG DOM as a normative reference. That's accidental and caused by tooling I am sure, but that still gives you a hint of where the center of gravity is. This is not to say that WHATWG DOM is perfect, or that there is no need to improve either the document itself or how the two groups cooperate, but I do not think we should draw false equivalences. |
|
@LJWatson Well said. |
|
Without any Microsoft, W3C AB or WHATWG SG hat on: As @frivoal notes, it's problematic to stop the upstream maintenance work on DOM that all rely on. I don't see my comment as about stopping work, I see it as about converging efforts. Formal agreement between the organizations would be easier if there were more active collaboration between the people in the sub-communities. Some W3C working groups and WHATWG workstreams have figured out how to converge their efforts without formal agreement, such as I18N and Encoding. While I'm not sure that particular example is a template for how others should collaborate (e.g., why doesn't W3C just normatively reference Encoding?), it's working better than the situation with DOM (and HTML). Also, the WP WG charter says "For these specifications, the Web Platform Working Group should make an effort to work with the WHATWG editors to avoid differences between the WHATWG and Web Platform WG specifications that would harm interoperability on the Web. " I'm not aware of direct collaboration between the DOM editors in the 2 orgs. If, for example, the W3C editors were to find evidence that a feature in the WHATWG spec isn't actually interoperable on the web, don't just quietly remove it from the downstream version, file an issue/start a dialog about whether it's really got proper tests, in the implementation pipeline for browsers, polyfilled by real websites, etc.. WHATWG editors are empowered to make judgments, but sometimes they mis-judge what implemented reality is or will be, and the web will be better off if that feedback gets back to them, preferably with reference to tests and test results. (Web Platform Test is another example of productive WHATWG-W3C collaboration happening already). But the web will remain worse off if what should be a data-driven discussion becomes a political argument about whose spec is "canonical." Anyway I imagine I've annoyed colleagues in both WHATWG and W3C with these comments, but my hope is to start real dialog about how to move ahead in a more collaborative way, whatever W3C decides to do about DOM 4.1. |
|
Thanks @frivoal and @michaelchampion for your thoughtful replies. |
|
Can you suggest a way forward that minimises problems for people who rely on the W3C specification? The DOM 4 Recommendation is 2 1/2 years old, and there are significant differences in the current update. (For some context: If there were only one DOM specification that everyone worked on together at W3C, as a chair I would be looking to begin the publication process for DOM 4.2 already.) |
At a personal level, I totally agree that political arguments about whose spec is "canonical" are a waste of time, with the opportunity cost of distracting people from productive work that could benefit everyone. I also don't think there is such a thing as "the canonical spec". If there were, a clear-eyed analysis of data might well conclude that in english W3Schools fills that role, but badly because MDN also seeks to do so - or vice versa. |
It would help to hear from those people who rely on the W3C DOM Recommendations, to learn who they are and what problems they have with the WHATWG DOM Living Standard or the (scheduled to be semi-annual) DOM Living Standard Review Draft https://whatwg.org/workstream-policy#review-draft. Once we have a shared understanding of who the audience is and what their use cases are, we are more likely to get consensus on how to address their needs. |
|
@michaelchampion Your response is circular. W3C and WHATWG are trying to get to a shared understanding of how to rationalize two specs. While we are in the middle of doing that, you have proposed not progressing on DOM 4.1. Leonie asked how to move forward (presumably in the current timeframe - before WHATWG and W3C finish negotiating). Your response is to get a shared understanding. That reduces it to the problem we are already trying to solve in our bilateral negotiations. Hence it does not answer Leonie's question. |
|
Clarification of my previous post. I meant Chaals, not Leonie. |
|
@jeffjaffe I understand that you think my argument is "circular" but I am wearing several hats here: Wearing my Microsoft hat, I asked W3C not to advance DOM 4.1 at this time because the existence of different DOM standards creates pain for our engineers and customers. Now that we have joined the other browser implementers and refer to the WHATWG DOM living standard, we think the easiest way to end that pain is for W3C to not publish a standard that significantly differs from WHATWG's. Wearing my WHATWG Steering Group hat, I believe that advancing the DOM 4.1 / HTML 5.3 "forks" at this time perpetuates the conflict between the organizations and complicates the negotiations you refer to. You seem to believe that it perpetuates conflict/complicates the negotiations for the WG members who are also WHATWG participants to oppose DOM 4.1. I guess that illustrates the challenges of finding agreement. Wearing my AB/Community representative hat, I was trying to address @chaals question "Can you suggest a way forward that minimises problems for people who rely on the W3C specification?" by getting clarification on who those people are and what problems they are having. Depending on the audience for a DOM 4.1, I can imagine all sorts of answers to @chaals question that Microsoft (not to mention WHATWG) may not be enthusiastic about but the W3C membership as a whole would find valuable. In other words, get the information and build consensus about W3C's value-add among "the other 450+ W3C member organisations that represent the wider web platform" as @LJWatson put it. That might take longer than the "current timeframe", but if we are seeking a broad consensus on how to move forward it seems like the way to go. |
|
I think we're speaking at cross purposes; I don't have any issue with the WPWG continuing to work on the spec as they see fit, it's specifically the spec of signposting with a CR that I was asking to be delayed. |
|
@michaelchampion I was refering to your point:
In the W3C WHATWG negotiations, W3C already supplied the rationale of the people relying on the W3C specification in our "Premises" document. When we presented our Premises document, WHATWG did not want to discuss it - which I interpreted to mean that the WHATWG was willing to stipulate that this document already captured the needs of the broader community. That being the case, you know exactly the requirements why W3C needs to proceed with DOM 4.1 at this point in time. And as Chaals said, absent an agreement with WHATWG they need to move forward with this work. I get it that you have this confusing this with multiple hats. My advice to you is the following. Since your WHATWG SG hat understands the Premises which lead to needing DOM 4.1 you should explain it to your Microsoft hat. Once your Microsoft hat understands it, it should drop this objection; and it should also explain to your WHATWG hat to move on more rapidly in negotiations instead of throwing shade on the productive work of the Web Platform Working Group. |
|
@cwilso as a chair charged with trying to ensure the Working Group meets the charter it was given by the W3C and its members, publishing an updated spec as CR - and then PR - is an important part of how I understand "as they see fit" to do the work. As you are aware, delaying a CR automatically delays subsequent stages of the W3C spec life-cycle. It is unclear what benefit of this might have. While W3C produces named stable versions according to an agreed Process, as you know e.g. from working on CSS2 20 years ago, it aims to revise specifications "as appropriate", and considers this an important part of fulfilling its mission. |
Being far too busy these days, I am a bit late to the discussion, sorry for that. This is severely underestimating the real situation. Nobody using the DOM on a heavy daily basis does differently (with my recent new VP Engineering hat in a software company on, I can testify on that for my employer). It's honestly out of question to rely on the proposed DOM 4.1 to do anything "in production". But let's review the situation:
Draw your own conclusions. |
|
This resolution passes, with objections. The argument presented creates a weaker objection than "the current DOM 4.0 specification should be updated". No pathway to consensus has been identified, and the Working Group is chartered to produce an update to the DOM specification. The chairs believe that the outcome which raises the weakest technical objections is to proceed with a request for transition to CR. In long form... The argument raised is that two specifications produce confusion, and that negotiation to agree on a single specification is more important than, and would be prejudiced by, updating the existing W3C Recommendation. While there is some truth to the first assertion, it is a weak technical argument since in practice there are multiple sources people consider authoritative:
Work on DOM has been repeatedly rechartered over some years by W3C despite the existence of a WHATWG DOM specification. This suggests many W3C members have decided that multiple specifications is not the most critical problem, and they would like the W3C versions updated. That opposition to the publication of a standard is politically or commercially motivated is not sufficient grounds to dismiss it: Standards are developed and used or ignored in the context of a real market and real politics. The W3C process uses the work of participants in chartered Working Groups to seek an acceptable - including politically and commercially acceptable - technical resolution to a set of problems scoped as deliverables, and then relies on the W3C Director with the advice of the membership to determine whether to adopt that as a W3C Recommendation. The process places a high value on consensus, but where it cannot be achieved it is explicit in noting the Working Groups should move forward. All the objectors and many proponents in this case would be familiar with this, having been involved in the progression of EME to Recommendation. The technical objection that two specifications create confusion is weaker than the objection that a W3C Recommendation should be updated, and not doing so is a substantial disservice to those who read it. The non-technical argument, that the specification update should be withheld to facilitate ongoing negotiation, does not seem to hold. The negotiations in their current form have apparently been going since last year. They are a continuation of negotiations that have been occurring for more than half a decade. W3C deliberately choosing not to maintain the quality of its own work only makes sense in the context of a presupposed outcome of those negotiations, and is in that sense prejudicial to the outcome. In the contrary case, if the conditions can be found for all parties to agree to work together on one specification it appears helpful to the community who read the W3C specification that the change is as small as possible, which thus suggests the W3C should move the DOM 4.1 specification forward. |
|
@jeffjaffe As someone who is neither you or @michaelchampion , I read your response to him as dismissive and insulting, and it seems to have stopped @chaals from answering his legitimate question. The tone reads like you are addressing an unruly underling, rather than a key stakeholder. If that was not your intent, you may want to recalibrate your tone. Your response did not provide an answer to the question either. @michaelchampion asked for specific parties that are relying on the W3C DOM Recommendations, and asked to hear from them directly. You did not name any such parties. Nor did the confidentially shared document you referenced. (Regrettably, it is difficult for people who have seen this confidentially shared document to publicly discuss its contents.) I stand by my request that you recuse yourself from adjudicating this Formal Objection. |
|
Also note that @michaelchampion is unable to respond in this issue because @chaals has closed it to collaborators. So it's somewhat unfair to continue the dispute with him here. |
|
@othermaciej @michaelchampion On the "tone" point specifically, I have re-read my posting and I agree that I could have done a better job on tone. If @michaelchampion interpreted that as dismissive or insulting I publicly apologize for that. You also asked about the content of my posting, so let me explain further why I thought that @michaelchampion 's argument was circular. @chaals was searching for a path forward that minimizes the problems for people that rely on the W3C specification. @michaelchampion proposed an exercise where (in my interpretation) everyone on this thread would sufficiently understand the various motivations that have led to two different specs (in W3C and WHATWG). W3C and WHATWG SG have been discussing this for several months and while progress has been made we have not reached resolution. My point was that if we now take that set of discussions and put them as blockers to the DOM 4.1 CR transition discussion, it would likely take the same several months. Therefore, that approach would not imho address @chaals 's request for a path forward. Hence my suggestion to accelerate the W3C/WHATWG joint Workmode discussions. |
|
@jeffjaffe If you want to debate the substance of your disagreement with @michaelchampion further, I suggest you do so in a place where he can reply. He's not able to post in this issue any more, now that @chaals closed it and limited it to collaborators only. |
|
Note also the Formal Objection from Google at #177 |
|
I have unlocked the conversation, since it continues and to save having to track multiple issues. Please continue to be respectful and polite in discussion. |
|
Mozilla also formally objects to the transition of DOM 4.1 to Candidate Recommendation. (Also see Microsoft's objection in #176, Apple's objection in #175 (comment) , and Google's objection in #177.) Those three objections state both procedural and substantive concerns quite clearly. We agree with those concerns and don't feel the need to restate them, beyond noting that #177 explains how the first requirement for CR has not been met, #175 (comment) explains how the third has not been met, and we also believe the second has not been met given the lack of documentation of the changes to the WHATWG DOM Living Standard (a dependency). Instead we'd like to go back to the original concerns at the root of these objections. The first of these is that the W3C DOM specification is a fork of the WHATWG DOM specification. The active focus of discussion of issues in the specification, and maintenance of the specification, is at the WHATWG rather than at the W3C. But the W3C has forked the specification without documenting the rationale behind having a fork (aside from general reasons in the Web Platform WG Charter, none of which apply to this CR transition). But the existence of the fork, and the fact that the fork is built around a structure that purports to be a forum for discussion and maintenance of the specification, leads to confusion, as the W3C confuses some portion of newcomers to the community into believing that effort working on the specification is best spent on the fork rather than on the original. If this were done with a clear statement that the document is a fork (and what it is forked from) and a statement of how the W3C's goals differ from those of WHATWG, this would be more understandable. But instead it appears to be done based on a presumption that W3C is the legitimate forum, and therefore that newcomers are owed no explanation of the origin of the document or the rationale for focusing the efforts of those who stumble across the W3C DOM specification in a way that those efforts are less likely to be effective. The second underlying concern is that the W3C fork of the DOM has a substantial number of changes. These changes appear to have been driven by a small number of people and do not have community consensus around them, or wide review. For example:
|
|
Disruptive Innovations is also formally objecting to the transition of DOM 4.1 to Candidate Recommendation. The proposed document specifying interfaces that are different from the WHATWG DOM specification, different from what implementors are shipping and are not going to change (since they all follow the WHATWG version anyway), it is a source of confusion that will not qualify as a Standard. This objection is also based on my understanding of the situation, detailed here, and that remains unaddressed as a dissent. As an implementor, DOM 4.1 is completely worthless to me; the only version we (that means Disruptive Innovations, my new employer Privowny that is about to join W3C, and everyone I know in the industry) can follow is the WHATWG one. |
|
@dbaron thank you for your comments. We will consider carefully the differences between the specification and implementations, and the editorial issues you raise, before we take any further action with regard to transition along the Recommendation track. |
|
@othermaciej than you for your comments. I will leave the procedural issues for the W3C director to assess,. From previous contentious spec advancement decisions I believe the Director has refined the understanding of the role played by various parties to the dispute, and the need to ensure that decisions are made fairly, and will ensure that your request for @jeffjaffe to recuse himself from the decision-making process is noted. As far as I am aware, he is generally not part of making technical decisions anyway. I also dispute your assertion that his comments "interrupted the exchange". While a non-particcipant in the WG is able to make comments in this repository, the only actions that actually interrupt the exchange are editing comments or locking discussion, which is done by the chairs in cases where a simple apology does not seem sufficient follow-up from egregiously inappropriate comments, or as in this case where we believe the issue is closed and further discussion seems likely to be unproductive. |
I am a former DOM editor (Level 1, Level 2) and current DOM user. Interoperability is the reason we have standards. Without implementations, you don't have interoperability.
Given that, what are the plans to meet the requirements for CR? What counts as adequate implementation experience? Aren't the comments in this issue list an indication that wide review is showing that the stakeholders see issues? I'm not informed on all the details, but as a user, I'd like to see development continue in both places while moving toward an agreement on a single standard. If there are multiple standards governing essentially the same thing, that's bad for users like me, especially if each gains market share. I have no idea what the political considerations are, but the political considerations are not what users care about. |
|
Bloomberg is formally objecting to the transition of DOM 4.1 to Candidate Recommendation. We agree with the points already raised by Apple, Microsoft, Google, Mozilla, and Disruptive Innovations in this thread. We do not believe the W3C DOM 4.1 aligns with our interests and the interests of the Web platform as a whole. We believe the WHATWG DOM should remain the living standard for conforming implementations. |
|
Innovimax is Formally Objecting |
|
I, as an Invited Expert in the Web Platform WG, am formally objecting to the transition of DOM 4.1 to Candidate Recommendation. I would like to add my support to the points already raised by Apple, Microsoft, Google, and Mozilla; I do not feel a need to restate the points outlined them. I am also deeply concerned by the W3C CEO's conduct in this thread, agreeing with @othermaciej that he appeared "dismissive and insulting"; this appears to go against the CEPC. I am also concerned by the W3C CEO appearing within a Working Group's Call for Consensus, when he is not a member of the WG, undermining the ability of the WG to make its own decision (given his position of power within the W3C), and then justifying his position by pointing at discussions and documents not, as far as I am aware, accessible by the majority of people in the WG (and, as such, making it impossible for the majority of the WG to even evaluate the arguments he has presented). As the Process says I should propose changes that would remove the formal objection:
|
|
I totally agree with #177 and similar objections. W3C, please think about developers |
|
@gsnedders @gsnedders I have already acknowledged earlier in this thread that my tone could have been better and I have already apologized for it. So +1 to your points. |
|
@jeffjaffe I'm aware; I'm just sufficiently concerned about the potential consequences of someone in a position of power acting in such a way in a WG's CfC, and how that might affect people's willingness to respond (especially with dissent) to the CfC. |
|
@gsnedders Fair point. Which is why I am trying to make my penitence clear. |
|
@jeffjaffe I think @gsnedders 's point is not only, or even primarily about tone. Because of your position, by taking sides in a WG's CFC, even in the most courteous manner, you change nature of the vote, from “does anyone disagree with $FOO” to “does anyone disagree with $FOO enough to stand up to authority”. Individuals and cultures vary, and some may be more or less sensitive to this effect than others, but regardless I think this is not desirable. |
|
@frivoal Thanks Florian for the additional point. I agree. I need to be more careful about this. |
|
@jeffjaffe What @frivoal said was my point, and your comment was worsened by your tone. |
|
@frivoal @gsnedders Got it. I think each of you have articulated nicely what I need to avoid in the future. |
|
There is apparently some confusion as to the status of this CfC. Given technical issues raised which merit serious consideration, the resolution is that the CfC has not passed. We will examine the issues raised as the next step, and any future plan to move the specification forward will result in a new CfC. |
|
A note on participation in discussions, from a co-chair. The conditions that govern participation in issue discussions are essentially those of GitHub itself, the W3C Code of Conduct, and W3C's IPR policies. (To make that clearer, in the next few days I will link them specifically to this repository). Like anyone else who is not a formal participant in the Web PLatform Working Group, but who holds opinions on the work we do, Jeff Jaffe will continue to be welcome to participate in discussions subject to those conditions. I am grateful that Jeff apologised for the sarcastic tone of one of his posts - a community that holds itself to high standards is one of the things we strive for in the Web Platform WG. The discussion would likely be more productive, and feel less threatening for many who find it difficult to engage in confrontational discussion or challenge those they regard as "authority", if everyone held themselves to the high standards we expect. Obviously that applies both to the narrower conversation in the issue itself, and the wider set of references to it, especially those that are a matter of public record. |
This runs contrary to your comment above. Does this mean you are reopening the decision having been presented with new information? If so, can you unambiguously record that it has been reopened? |
|
@chaals Should I take your lack of response here to mean that the decision hasn't been reopened? I note you "must do so upon request from a group participant", per Process. I would like clarity on this; the chairs have declared following this CfC that there is consensus and that there is not consensus, and per Process it would appear we've made a decision (to proceed with a transition request to advance DOM 4.1 to CR) and then made the opposite decision, and haven't clearly reopened the decision between the two. |
|
@gsnedders this CFC did not pass and will not be reopened. As @chaals noted: |
This is a call for consensus on the proposal
Move DOM 4.1 to Candidate Recommendation.
Please reply before the end of Sunday 25 March 2018 by either providing a thumbs-up to this issue, or a comment explaining the reason for objecting. Silence will be considered assent to the outcome.
The text was updated successfully, but these errors were encountered: