Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CfC: Move DOM 4.1 to Candidate Recommendation #175

Closed
chaals opened this Issue Mar 18, 2018 · 58 comments

Comments

Projects
None yet
@chaals
Copy link
Collaborator

chaals commented Mar 18, 2018

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.

@chaals chaals added the question label Mar 18, 2018

@michaelchampion

This comment has been minimized.

Copy link

michaelchampion commented Mar 22, 2018

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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Mar 23, 2018

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.

@cwilso

This comment has been minimized.

Copy link

cwilso commented Mar 23, 2018

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.

@frivoal

This comment has been minimized.

Copy link

frivoal commented Mar 23, 2018

I agree with @michaelchampion (and will not attempt to rephrase & repeat his argument, as that does not seem productive).

@hober

This comment has been minimized.

Copy link
Member

hober commented Mar 23, 2018

We support delaying this CfC until the negotiations @jeffjaffe mentioned are completed.

@dbaron

This comment has been minimized.

Copy link
Member

dbaron commented Mar 23, 2018

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.

@DavidMacDonald

This comment has been minimized.

Copy link

DavidMacDonald commented Mar 26, 2018

I support this CFC

@zqzhang

This comment has been minimized.

Copy link
Member

zqzhang commented Mar 26, 2018

I support this CFC too.

@hmin

This comment has been minimized.

Copy link

hmin commented Mar 26, 2018

I support this CFC

@LJWatson

This comment has been minimized.

Copy link

LJWatson commented Mar 28, 2018

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?

@frivoal

This comment has been minimized.

Copy link

frivoal commented Mar 29, 2018

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.

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.

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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Mar 29, 2018

@LJWatson Well said.

@michaelchampion

This comment has been minimized.

Copy link

michaelchampion commented Mar 29, 2018

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.

@LJWatson

This comment has been minimized.

Copy link

LJWatson commented Mar 29, 2018

Thanks @frivoal and @michaelchampion for your thoughtful replies.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 2, 2018

@michaelchampion

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.)

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 2, 2018

@michaelchampion

But the web will remain worse off if what should be a data-driven discussion becomes a political argument about whose spec is "canonical."

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.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 2, 2018

(The call for a way forward is open - @frivoal, @cwilso, @hober, @dbaron, and everyone else, feel free to help find a consensus here...)

@michaelchampion

This comment has been minimized.

Copy link

michaelchampion commented Apr 2, 2018

Can you suggest a way forward that minimises problems for people who rely on the W3C specification?

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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 2, 2018

@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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 2, 2018

Clarification of my previous post. I meant Chaals, not Leonie.

@michaelchampion

This comment has been minimized.

Copy link

michaelchampion commented Apr 2, 2018

@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.

@cwilso

This comment has been minimized.

Copy link

cwilso commented Apr 2, 2018

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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 2, 2018

@michaelchampion I was refering to your point:

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.

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.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 3, 2018

@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.

@therealglazou

This comment has been minimized.

Copy link

therealglazou commented Apr 4, 2018

We know that Apple, Google, Microsoft, and Mozilla, consider the WHATWG to be the canonical version

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:

  • is a browser vendor going to conform to W3C DOM 4.1? Extremely unlikely, and that's probably too optimisitic already.
  • are other implementors going to conform to W3C DOM 4.1? Possibly but browser vendors remain the largest attractor here and interoperability issues will arise and everyone will eventually follow the same path
  • is the DOM 4.1 effort worth the money, the Staff investment, the potential negative image, the fight with WHATWG? Most certainly not.
  • has the WHATWG version of DOM helped the situation on DOM interop and progress? Yes, tremendously.
  • where has the DOM expertise been during the last fifteen years? At WHATWG.
  • is DOM 4.1 complexifying a situation that does not need it? Absolutely, a zillion times.

Draw your own conclusions.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 9, 2018

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:

  • implementation data
    • most actual implementations match neither specification perfectly at any given moment
  • Instructional and tutorial material
    • this is used by people for obvious reasons
  • organisational or institutional policy
    • standardisation seeks to help these to harmonise. That process is an ongoing approximation to a changing reality, and such policies are therefore widespread and divergent

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.

@chaals chaals closed this Apr 9, 2018

@w3c w3c locked as resolved and limited conversation to collaborators Apr 9, 2018

@othermaciej

This comment has been minimized.

Copy link
Member

othermaciej commented Apr 11, 2018

@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.

@othermaciej

This comment has been minimized.

Copy link
Member

othermaciej commented Apr 11, 2018

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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 11, 2018

@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.

@othermaciej

This comment has been minimized.

Copy link
Member

othermaciej commented Apr 11, 2018

@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.

@othermaciej

This comment has been minimized.

Copy link
Member

othermaciej commented Apr 11, 2018

Note also the Formal Objection from Google at #177

@w3c w3c unlocked this conversation Apr 12, 2018

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 12, 2018

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.

@dbaron

This comment has been minimized.

Copy link
Member

dbaron commented Apr 12, 2018

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:

  • Many sections of the WHATWG DOM Living Standard describe a DOM interface, give a non-normative summary of the interface's methods for web developers (marked up in a delimited section with an appropriate heading), and then give normative text describing the conformance requirements for implementations. The W3C DOM specification removes the styles that set off the authoring requirements section, making it appear that there are simply two undifferentiated sets of descriptions of each interface method and property, with two potentially contradictory normative definitions. Lack of objection to duplicate normative definitions of many parts of the spec is a sign that it has not had wide review.
  • Many of the key changes made in the WHATWG DOM specification to improve interoperability have not been reflected in the W3C DOM specification. For example, changes for compatibility with webkit prefixes and animation events in the definition of invoke in the WHATWG specification made over two years ago have not been ported to the definition in the W3C specification.
@therealglazou

This comment has been minimized.

Copy link

therealglazou commented Apr 12, 2018

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.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 13, 2018

@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.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 13, 2018

@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.

@jonathanrobie

This comment has been minimized.

Copy link

jonathanrobie commented Apr 13, 2018

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.

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.

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.)

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.

@arybkablp

This comment has been minimized.

Copy link

arybkablp commented Apr 13, 2018

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

This comment has been minimized.

Copy link

innovimax commented Apr 13, 2018

Innovimax is Formally Objecting
I hope this is all just a big misunderstanding

@gsnedders

This comment has been minimized.

Copy link

gsnedders commented Apr 14, 2018

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:

  • Given the ongoing discussions about the future relationship between the WHATWG and W3C, I do not think it is beneficial to advance any document derived from any WHATWG specification along the W3C Recommendation Track until those discussions are concluded. The WG may continue to work on the specification in editor's drafts and publish working drafts. As such, the proposed change here is "withdrawing the attempt to advance to CR until the WHATWG and W3C have decided on their future relationship".

  • Per Process, a CR "must document how adequate implementation experience will be demonstrated". The WG has no yet documented this. I suggest, based on the CSS WG's normal text:

    For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature and of each difference in behaviour to the WHATWG DOM specification as of commit c80e0176d9565d2832ae3d535414faff7f6e7dda. Each feature or difference may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:

    independent: each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.

    interoperable: passing the respective test case(s) in the official DOM test suite, or, if the implementation is not a Web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.

    implementation: a user agent which:

    1. implements the specification.
    2. is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or "nightly build"). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability.
    3. is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).

    I am adding the requirement for implementation for each difference so that we can demonstrate implementation of the W3C DOM 4.1 specification as opposed to the WHATWG DOM specification and merely coincidentally testing the intersection of behaviour between the two specifications.

@akalongman

This comment has been minimized.

Copy link

akalongman commented Apr 15, 2018

I totally agree with #177 and similar objections. W3C, please think about developers

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 15, 2018

@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.

@gsnedders

This comment has been minimized.

Copy link

gsnedders commented Apr 15, 2018

@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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 15, 2018

@gsnedders Fair point. Which is why I am trying to make my penitence clear.

@frivoal

This comment has been minimized.

Copy link

frivoal commented Apr 16, 2018

@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.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 16, 2018

@frivoal Thanks Florian for the additional point. I agree. I need to be more careful about this.

@gsnedders

This comment has been minimized.

Copy link

gsnedders commented Apr 16, 2018

@jeffjaffe What @frivoal said was my point, and your comment was worsened by your tone.

@jeffjaffe

This comment has been minimized.

Copy link

jeffjaffe commented Apr 16, 2018

@frivoal @gsnedders Got it. I think each of you have articulated nicely what I need to avoid in the future.

@yoavweiss

This comment has been minimized.

Copy link

yoavweiss commented Apr 20, 2018

Akamai Technologies would like to formally object DOM 4.1 moving to CR for the procedural reasons stated before by Apple, Google, Mozilla and Microsoft.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 25, 2018

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.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

chaals commented Apr 25, 2018

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.

@gsnedders

This comment has been minimized.

Copy link

gsnedders commented Apr 25, 2018

@chaals

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.

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?

@gsnedders

This comment has been minimized.

Copy link

gsnedders commented May 23, 2018

@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.

@LJWatson

This comment has been minimized.

Copy link

LJWatson commented May 23, 2018

@gsnedders this CFC did not pass and will not be reopened. As @chaals noted:
<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.<

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.