Charter must state a reason when duplicating work done elsewhere

[frivoal]

(I have raised similar issues before, but in order to discuss only what is still relevant, I'm opening a new one).

Some deliverables of the Web Platform working group originate and are being maintained elsewhere, In particular in the WHATWG.

The charter does say that "The Web Platform Working Group should make an effort to avoid differences between WHATWG and Web Platform WG specifications that harm interoperability on the Web", but it does not make any mention of why the work is duplicated.

Rephrasing / summarizing a point I've made before:

Whether that "effort to avoid differences" is successful or not should be view in the light of what the goal of maintaining the specification separately is. Differences that are a consequence of that goal are likely justified, while those that are not are issues.

I don't know what that goal is. I am not being facetious here, nor do I believe that there's no goal. However, I strongly suspect that one of the reasons we have not written it down is that different people have different rationales for this, and these various goals are mutually incompatible.

I am sure that any difference introduced is justified based on what the people who made them understand the goal to be. However, the continued inability to write that goal down make be believe that it is not a consensus based goal.

Not knowing what the mandate of the WG is, I have no basis to judge whether it's actions are appropriate or not, and therefore refrain from commenting on calls for consensus and the like. If a large part of the group's membership has a similar attitude, we'll have consensus by exhaustion rather than consensus by agreement.

Proposed solution. The charter should either:

• Give a high level motivation as to why the WG needs to take on some work items that are already being worked on in different forums, specifically listing goals and non goals. This should be used both to evaluate whether any particular specification should indeed be taken on by the working group, and to evaluate whether divergence from the other version are justified by the goal(s) or failures in making an effort to avoid differences.
• drop all items that originated elsewhere and are still maintained there

[michaelchampion]

" I strongly suspect that one of the reasons we have not written it down is that different people have different rationales for this, and these various goals are mutually incompatible."

That may well be true. One possible rationale for the WP WG taking on specs that WHATWG is developing upstream is to get the broad patent commitments that come with W3C Recommendations. Until such a time that WHATWG operates under an IPR policy that generated credible royalty-free patent commitments, this is a defensible reason for duplicating the specs. But I'm not sure folks on the W3C side would agree this is the main value add from the W3C version of HTML, DOM, etc. And I'm pretty sure folks on the WHATWG side don't consider this a sufficient reason for the duplication. But the larger community benefits from the outcome of this inefficient and error-prone system so long as people look to the Living Standards as the up-to-date version and the W3C versions as a guide to what has binding patent commitments.

In a better world than the one we currently live in, WHATWG Living Standards would have patent commitments, and W3C Recommendations would be efficiently maintained to accurately reflect how the web works today, and the two communities would work out some sort of division of labor to prevent duplication of work. I can dream can't I ? :-)

[jeffjaffe]

On 5/15/2017 10:15 PM, Florian Rivoal wrote:

(I have raised similar issues before, but in order to discuss only what is still relevant, I'm opening a new one).

Some deliverables of the Web Platform working group originate and are being maintained elsewhere, In particular in the WHATWG.

The charter does say that "The Web Platform Working Group should make an effort to avoid differences between WHATWG and Web Platform WG specifications that harm interoperability on the Web", but it does not make any mention of why the work is duplicated.

Rephrasing / summarizing a point I've made before https://github.com/w3c/charter-html/issues/112#issuecomment-236336472:

Whether that "effort to avoid differences" is successful or not should be view in the light of what the goal of maintaining the specification separately is. Differences that are a consequence of that goal are likely justified, while those that are not are issues.

I don't know what that goal is. I am not being facetious here, nor do I believe that there's no goal. However, I strongly suspect that one of the reasons we have not written it down is that different people have different rationales for this, and these various goals are mutually incompatible.

I am sure that any difference introduced is justified based on what the people who made them understand the goal to be. However, the continued inability to write that goal down make be believe that it is not a consensus based goal.

Not knowing what the mandate of the WG is, I have no basis to judge whether it's actions are appropriate or not, and therefore refrain from commenting on calls for consensus and the like. If a large part of the group's membership has a similar attitude, we'll have consensus by exhaustion rather than consensus by agreement.

Proposed solution. The charter should either:

• Give a high level motivation as to why the WG needs to take on some work items that are already being worked on in different forums, specifically listing goals and non goals. This should be used both to evaluate whether any particular specification should indeed be taken on by the working group, and to evaluate whether divergence from the other version are justified by the goal(s) or failures in making an effort to avoid differences.

I'm not sure how "high level" a motivation you want.

W3C's goal has always been and continues to be to publish a stable, RF protected set of standards for the web platform using OpenStand approaches [1] as encapsulated by the W3C process [2]. In cases that other forums are also working on these specifications we seek to partner with them so we have a cohesive community working on these specifications. We are not always successful in attracting the other forums to partner with us. In the case of the WHATWG we explicitly call out an objective to avoid differences which would harm interop.

Btw, if you (or others) can help us improve partnerships with other forums that would be much appreciated.

[1] https://open-stand.org/ [2] http://www.w3.org/2017/Process-20170301/

• drop all items that originated elsewhere and are still maintained there

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22m9QryutOsViiQhn3IfbPE4n3qkjks5r6QbRgaJpZM4Nb6X5.

[stevefaulkner]

A co-editor of the HTML spec here. I can only talk to my motivation for working on HTML at W3C. It affords me and interested members of the community more opportunity to provide accessibility related normative and informative content in HTML. Why don't I just contribute at WHATWG? I do, but the priorities and ideological orientations of the editors of the WHATWG spec are different to mine and the community I work with. This sometimes leads to an ossification of incomplete or incorrect information in the WHATWG spec, that I am able to avoid in the W3C spec. In general I do not duplicate content in my editing and do not seek to minimise differences, except where that minimisation improves interoperability and outcomes for users with disabilities. The centre of gravity for accessibility related aspects of the web platform, including implementation in browsers, continues to be at the W3C. It is still also the place where stakeholders with a commitment to accessibility, regardless of their affiliation with browser vendors, get a seat at the table.

[frivoal]

I'm not sure how "high level" a motivation you want.

The kind of statement @michaelchampion just made probably should be condensed a bit before being put in a charter, but it is a clear stance from which we can derive conclusions about which document should be covered, and what kind of divergence is desirable.

One possible rationale for the WP WG taking on specs that WHATWG is developing upstream is to get the broad patent commitments that come with W3C Recommendations. Until such a time that WHATWG operates under an IPR policy that generated credible royalty-free patent commitments, this is a defensible reason for duplicating the specs. But I'm not sure folks on the W3C side would agree this is the main value add from the W3C version of HTML, DOM, etc. And I'm pretty sure folks on the WHATWG side don't consider this a sufficient reason for the duplication. But the larger community benefits from the outcome of this inefficient and error-prone system so long as people look to the Living Standards as the up-to-date version and the W3C versions as a guide to what has binding patent commitments.

This is a reasonable stance. If that is our primary goal, I would expect to see only two types of differences between W3C drafts and WHATWG drafts:

• postponing less mature features to later revisions so that the current one can got to REC
• When WHATWG specs differ from actual implementations and WHATWG editors refuse change their spec accordingly, the W3C specs should match implementations rather than the WHATWG spec, since implementations are what need patent protection. Any other change would seem undesirable, as it takes effort to make despite not being justified by the goal, and can even make the work of determining where the two specification differ harder, probably leading to accidental differences between the two. In this scenario, the fact that most implementors work with the WHATWG document rather than with the w3c document (as I have repeatedly heard from implementors) is mostly a non issue.

Does that make sense to you @michaelchampion ?

With this as a goal, I'd still be a little bit confused as to why we maintain our own copy of specs from WHATWG and not from the IETF, but at least I'd know what to expect about those we do handled.

I'd note that the current modus operandi of the WebPlat WG does not seem to match that, and has a much more independent editorial control that what I suggested above.

A co-editor of the HTML spec here. I can only talk to my motivation for working on HTML at W3C. It affords me and interested members of the community more opportunity to provide accessibility related normative and informative content in HTML. Why don't I just contribute at WHATWG? I do, but the priorities and ideological orientations of the editors of the WHATWG spec are different to mine and the community I work with. This sometimes leads to an ossification of incomplete or incorrect information in the WHATWG spec, that I am able to avoid in the W3C spec.

This specific accessibility argument, as well as its generalization (The W3C consensus based process and the community it enables leads to better specifications that take the needs of more stakeholders into account) also seem valid, but I think it leads to different conclusions from the point @michaelchampion made. Under this goal, our editorial independence is a valuable feature, not a bug. The current modus operandi of the WebPlatform WG seems more compatible with this vision.

On the other hand, the fact that the community is at best fragmented, and arguably WHATWG centric is a double problem: not only does it limit the benefits of consensus and broad review, but also it means there is a pretty high chance that implementors may fail to notice substantive improvements and differences present in our specification but not in the WHATWG's, rendering our potentially better work irrelevant.

In this case, identifying and addressing the reasons that cause many implementors to only or primarily work with WHATWG drafts should be a top priority, and the Success Criteria of the WG should probably explicitly call for trying to establish our version of such specs as the primary reference over its alter-ego in the mind of most implementors. Otherwise, regardless of technical merits our spec risk ending up being fiction, and IPR protections that don't match implementations aren't that useful.

[jeffjaffe]

On 5/16/2017 2:17 AM, Florian Rivoal wrote:

With this as a goal, I'd still be a little bit confused as to why we maintain our own copy of specs from WHATWG and not from the IETF, but at least I'd know what to expect about those we do handled.

We have a pretty good understanding with IETF about where their scope ends and where our scope begins.

[frivoal]

We have a pretty good understanding with IETF about where their scope ends and where our scope begins.

Indeed IETF and W3C typically don't step on each others toes, there isn't really a problem to be solved there.

The problem is with WHATWG documents. I do not think we should be stepping on each others toes just because we're used to do so, and merely stating that we'll make an effort to avoid hurting each other along the way is too weak. If either party simply stopped working on specs the other is working on, there would be no divergence and duplication of effort. From a WebPlatform WG point of view, why the WHATWG will not stop working on such specs is immaterial. They've made it clear that they would not. If that were to change, we'd take that into account, but for now, it's not changing.

So we can decide to unilaterally stop the duplication. If we chose not to, and decide to bear the cost, and take the compatibility and confusion risk of having diverging specs, we need a reason.

And as I said above, the various reasons I've heard seem to demand conflicting courses of action, as I discuss in my previous comment. So we not only need to have "at least one reason", we need to be explicit about what we're after, so as to make sure that the actions taken are not in conflict with that.

[jeffjaffe]

On 5/16/2017 5:52 AM, Florian Rivoal wrote:

We have a pretty good understanding with IETF about where their scope
ends and where our scope begins.

Indeed IETF and W3C typically don't step on each others toes, there isn't really a problem to be solved there.

The problem is with WHATWG documents. I do not think we should be stepping on each others toes just because we're used to do so, and merely stating that we'll make an effort to avoid hurting each other along the way is a too weak. If either party simply stopped working on specs the other is working on, there would be no divergence and duplication of effort.

Thanks for your continued effort to find some logical way to partner with the WHATWG.

I've put a great deal of energy into that myself and failed. I tried to make it an AB priority for 2017 and was voted down by the AB. So I certainly am looking for fresh ideas.

I don't think this particular idea works. The WHATWG in the past has started to work on specs that originated in W3C and W3C is still working on. So the result of your policy could be that the WHATWG could start working on everything W3C is working on, and we would be bound by this policy to stop everything. This would not be a very good service for us to provide to our stakeholders, nor would it ensure (what I described in my previous post) that we deliver a standard Web Platform which is RF and follows OpenStand.

From a WebPlatform WG point of view, why the WHATWG will not stop working on such specs is immaterial. They've made it clear that they would not. If that were to change, we'd take that into account, but for now, it's not changing.

So we can decide to unilaterally stop the duplication. If we chose not to, and decide to bear the cost, and take the compatibility and confusion risk of having diverging specs, we need a reason.

And as I said above, the various reasons I've heard seem to demand conflicting courses of action, as I discuss in my previous comment. So we not only need to have "at least one reason", we need to be explicit about what we're after, so as to make sure that the actions taken are not in conflict with that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-301732797, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22nJm8H67s1GrufnuYBorB5v9tFGhks5r6XHlgaJpZM4Nb6X5.

[tantek]

I tend to find Florian's reasoning fairly compelling here, W3C could be doing a better job reducing confusion over duplicated work. In particular:

@frivoal wrote:

So we not only need to have "at least one reason", we need to be explicit about what we're after, so as to make sure that the actions taken are not in conflict with that.

And we also need to measure that supposed benefit of that one reason & what we're after, and whether that is worth the costs of doing so (e.g. costs of W3C resources, time, etc., costs of introducing/continuing/fueling confusion among web developers etc.).

I'm pretty convinced at this point that the answer is no, in general it is not worth it to have WPWG duplicate work being done in W3C. The only potential exception I'm unsure about is HTML, for the reasons that @stevefaulkner provides, and frankly because so much divergence has occurred there (some good, some bad, like old contentious debates being relitigated), it's not clear how to even attempt a path towards reconvergence with HTML.

@stevefaulkner wrote:

The centre of gravity for accessibility related aspects of the web platform, including implementation in browsers, continues to be at the W3C. It is still also the place where stakeholders with a commitment to accessibility, regardless of their affiliation with browser vendors, get a seat at the table.

I appreciate this and accept it is not to be underestimated.

To me this signals that all versions of HTML could/would benefit from a delta document from HTML that specifically adds/patches accessibility related items, a "W3C HTML Accessibility" spec as it were. The advantage of such a spec is that such accessibility enhancements would get properly highlighted rather buried in the W3C's copy of HTML 5.x which browser implementers in general don't bother reading. If there was a separate "W3C HTML Accessibility" spec that worked as a delta from WHATWG HTML, I'm guessing more browser implementers might read that to see what the W3C accessibility consensus has documented. This is just floating an idea to stir thinking, not a concrete proposal, and no response is needed.

I agree with @frivoal's "Proposed solution" in his opening description, and would add:

• Each spec that is duplicating work that is happening at WHATWG explicitly note that in the charter and provide the specific reason(s) explaining why and what the benefits are of W3C doing so for that spec, and how those benefits outweigh the confusion generated by duplicating a spec actively maintained elsewhere.

If a charter cannot provide such reasons for working on a spec, especially one where another body is already doing maintenance on it, that spec should not be in the charter's scope.

[frivoal]

So the result of your policy could be that the WHATWG could start working on everything W3C is working on, and we would be bound by this policy to stop everything.

No, because my proposed policy is not to stop working on anything they also work on, but rather to either stop working on it or state why we continue. "nobody reads their fork" would be a good reason to continue when they fork our work. Conversely, absent other reasons, "nobody reads our fork" could be a good reason for stopping.

As @michaelchampion and @stevefaulkner stated, there can be good reasons to continue working on a document even if the other is has more developer mind-share. But as @tantek suggests, the accessibility needs may be better served by a separate document, and the IPR needs may be better served by less divergence. Or not. But at least, stating what the goals are less us discuss what the best way to achieve them is.

[jeffjaffe]

On 5/16/2017 8:48 PM, Florian Rivoal wrote:

So the result of your policy could be that the WHATWG could start
working on everything W3C is working on, and we would be bound by
this policy to stop everything.

No, because my proposed policy is not to stop working on anything they also work on, but rather to either stop working on it or state why we continue. "nobody reads their fork" would be a good reason to continue when they fork our work. Conversely, absent other reasons, "nobody reads our fork" could be a good reason for stopping.

As @michaelchampion https://github.com/michaelchampion and @stevefaulkner https://github.com/stevefaulkner stated, there can be good reasons to continue working on a document even if the other is has more developer mind-share. But as @tantek https://github.com/tantek suggests, the accessibility needs may be better served by a separate document, and the IPR needs may be better served by less divergence. Or not. But at least, stating what the goals are less us discuss what the best way to achieve them is.

Yes, there are always reasons. So that gets back to my original question to you: "how high level an explanation do you want?". I provided an explanation in my first response which pretty much explains why we work on our specs. I believe that WHATWG has their reasons as well.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-301954019, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22uH0gzZG2-rBLnWMnILRcWEu-2C0ks5r6kPRgaJpZM4Nb6X5.

[jeffjaffe]

On 5/16/2017 5:08 PM, Tantek Çelik wrote:

I tend to find Florian's reasoning fairly compelling here, W3C could be doing a better job reducing confusion over duplicated work. In particular:

@frivoal https://github.com/frivoal wrote:

So we not only need to have "at least one reason", we need to be
explicit about what we're after, so as to make sure that the
actions taken are not in conflict with that.

And we also need to measure that supposed benefit of that one reason & what we're after, and whether that is worth the costs of doing so (e.g. costs of W3C resources, time, etc., costs of introducing/continuing/fueling confusion among web developers etc.).

I'm pretty convinced at this point that the answer is no, in general it is not worth it to have WPWG duplicate work being done in W3C.

Did you mean "done in WHATWG". What would you say about work recently started in W3C and forked to the WHATWG? Your formula seems to be a formula to ultimately stop everything in W3C.

The only potential exception I'm unsure about is HTML, for the reasons that @stevefaulkner https://github.com/stevefaulkner provides, and frankly because so much divergence has occurred there (some good, some bad, like old contentious debates being relitigated), it's not clear how to even attempt a path towards reconvergence with HTML.

I have argued at the AB (with little success) that we should be trying.

When we agreed to work together with the WHATWG in (roughly) 2008, we were much further apart. We hadn't even started working on HTML5 at that point! Yet we managed to create a partnership that worked for several years. It worked, basically, until W3C decided that the world wanted a standard HTML5 and the WHATWG felt that we were not ready to move it to REC level (due to LS).

IAC, I agree with you we should not relitigate the past. But if we could partner with them in 2008, we can certainly do the same today.
Our specs are much closer together than they were then. Our test frameworks are the same. The W3C process is much more agile. If there is a will there is a way.

@stevefaulkner https://github.com/stevefaulkner wrote:

The centre of gravity for accessibility related aspects of the web
platform, including implementation in browsers, continues to be at
the W3C. It is still also the place where stakeholders with a
commitment to accessibility, regardless of their affiliation with
browser vendors, get a seat at the table.

I appreciate this and accept it is not to be underestimated.

To me this signals that all versions of HTML could/would benefit from a delta document from HTML that specifically adds/patches accessibility related items, a "W3C HTML Accessibility" spec as it were. The advantage of such a spec is that such accessibility enhancements would get properly highlighted rather buried in the W3C's copy of HTML 5.x which browser implementers in general don't bother reading. If there was a separate "W3C HTML Accessibility" spec that worked as a delta from WHATWG HTML, I'm guessing more browser implementers might read that to see what the W3C accessibility consensus has documented. This is just floating an idea to stir thinking, not a concrete proposal, and no response is needed.

I agree with @frivoal https://github.com/frivoal's "Proposed solution" in his opening description, and would add:

• Each spec that is duplicating work that is happening at WHATWG explicitly note that in the charter and provide the /specific/ reason(s) explaining why and what the benefits are of W3C doing so for /that spec/, and how those benefits outweigh the confusion generated by duplicating a spec actively maintained elsewhere.

If a charter cannot provide such reasons for working on a spec, especially one where another body is already doing maintenance on it, that spec should not be in the charter's scope.

I have provided the rationale elsewhere in this thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-301916215, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22u3R4NJEVJPGN4uYZeOQj6JtV-enks5r6hBrgaJpZM4Nb6X5.

[frivoal]

So that gets back to my original question to you: "how high level an explanation do you want?". I provided an explanation in my first response which pretty much explains why we work on our specs.

Phrasing aside (as we can always tweak that), what @michaelchampion or what @stevefaulkner said are the level I would expect. Yours seem to generic: it says why in general it is good to standardize things and to do so in a standards body like ours, and how we liaise with other standard bodies, but it does not explain away this particular document or sets of document needs to be edited here despite the redundancy.

What would you say about work recently started in W3C and forked to the WHATWG? Your formula seems to be a formula to ultimately stop everything in W3C.

I do not think we should systematically stop working on documents that are handled both at the W3C and at WHATWG. Only about doing so when there is no sufficient reason to continue, and “we are a standards body with a good process” is not on its own a sufficient reason. When there are good specific reasons, they should be stated explicitly, weighted against the cost of maintaining the document, and if benefits exceed the costs, used to evaluate whether the general approach and individual actions serve that goal.

[LJWatson]

I'll take a deep breath and propose some words. I've focused on the HTML specification for the moment, but here goes...

"The Web Platform WG works on the HTML specification in order to protect it under the W3C Patent Policy. It also develops the HTML standard with contributions from a broad range of stakeholders, including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security. This ensures that HTML remains royalty free for use by implementors and authors, and that it is a robust and reliable standard that is relevant to all stakeholders."

We can (and assuredly will) bikeshed the words, but hopefully this will give us something to start from.

[michaelchampion]

@jeffjaffe asked:

What would you say about work recently started in W3C and forked to the WHATWG?

What are you referring to? Does “W3C” include Community Groups?

My thoughts on this thread:

• I hope the charter is explicit about work it plans to do that is downstream from WHATWG. That certainly includes HTML and DOM, possibly others.

• I agree with @frivoal and others that the charter should be clear about W3C’s value add. @LJWatson 's text it a good start (but needs to mention WHATWG e.g. “It also enhances the HTML Living Standard  with contributions from a broad range of stakeholders ….”)

• I like @tantek 's idea of refactoring the HTML accessibility work so that it extends / “deltas” the HTML Living Standard to better meet accessibility (and perhaps other “horizontal”) criteria. I would not want to hold up spinning off the Service Worker WG until that can be done, but it’s an idea to seriously explore for the next recharter.

As for the WHATWG relationship, I agree with @jeffjaffe that it should be possible to re-build some sort of partnership, but the first move is mutual trust-building. W3C might feel that HTML and DOM are “theirs” because they originated at W3C, but WHATWG feels that W3C let them rot from lack of maintenance (or outright rejection in the case of HTML circa 2004) and they deserve respect for revitalizing them as Living Standards. I definitely understand Steve’s concerns about “ the priorities and ideological orientations of the editors of the WHATWG spec are different to mine” and “ W3C… is still also the place where stakeholders with a commitment to accessibility, regardless of their affiliation with browser vendors, get a seat at the table”. But it’s worth noting WHATWG has become less “ideological” recently, and has published code of conduct https://wiki.whatwg.org/wiki/Code_of_Conduct and work mode guidelines https://whatwg.org/working-mode that imply some of @stevefaulkner 's concerns have been recognized and addressed.

Bottom line: I believe that it would be a respectful gesture to WHATWG for the WP WG charter to be explicit that some of its work is downstream from various Living Standards, and be clear about the value W3C proposes to add (patent commitments, wider review, and especially accessibility improvements).

[jeffjaffe]

On 5/17/2017 1:33 PM, Michael Champion wrote:

@jeffjaffe https://github.com/jeffjaffe asked:

What would you say about work recently started in W3C and forked
to the WHATWG?

What are you referring to?

The two most recent examples would be Shadow DOM and Custom Elements.

Does “W3C” include Community Groups?

My thoughts on this thread:

*

I hope the charter is explicit about work it plans to do that is
downstream from WHATWG. That certainly includes HTML and DOM,
possibly others.

*

I agree with @frivoal <https://github.com/frivoal> and others that
the charter should be clear about W3C’s value add. @LJWatson
<https://github.com/ljwatson> 's text it a good start (but needs
to mention WHATWG e.g. “It also enhances the HTML Living Standard 
with contributions from a broad range of stakeholders ….”)

*

I like @tantek <https://github.com/tantek> 's idea of refactoring
the HTML accessibility work so that it extends / “deltas” the HTML
Living Standard to better meet accessibility (and perhaps other
“horizontal”) criteria. I would not want to hold up spinning off
the Service Worker WG until that can be done, but it’s an idea to
seriously explore for the next recharter.

As for the WHATWG relationship, I agree with @jeffjaffe https://github.com/jeffjaffe that it should be possible to re-build some sort of partnership, but the first move is mutual trust-building. W3C might feel that HTML and DOM are “theirs” because they originated at W3C, but WHATWG feels that W3C let them rot from lack of maintenance (or outright rejection in the case of HTML circa 2004) and they deserve respect for revitalizing them as Living Standards. I definitely understand Steve’s concerns about “ the priorities and ideological orientations of the editors of the WHATWG spec are different to mine” and “ W3C… is still also the place where stakeholders with a commitment to accessibility, regardless of their affiliation with browser vendors, get a seat at the table”. But it’s worth noting WHATWG has become less “ideological” recently, and has published code of conduct https://wiki.whatwg.org/wiki/Code_of_Conduct and work mode guidelines https://whatwg.org/working-mode that imply some of @stevefaulkner https://github.com/stevefaulkner 's concerns have been recognized and addressed.

Bottom line: I believe that it would be a respectful gesture to WHATWG for the WP WG charter to be explicit that some of its work is downstream from various Living Standards, and be clear about the value W3C proposes to add (patent commitments, wider review, and especially accessibility improvements).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-302167789, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22vqRwEQTQRDU7tNg0RN4PVRr8oXSks5r6y-EgaJpZM4Nb6X5.

[dwsinger]

a few random thoughts

• as Florian and others imply, neither W3C nor WhatWG are willing (for good reason) to promise to walk away if the other body is working in, or starts working in, a given area
• though we tend to speak of the other body as ‘them’, we are, in fact, for the most part one community (people work in both WhatWG and W3C);
• at the W3C, we’ve been trying hard over the last several years to reduce the motivation to have this dual-body system; more agility, better tooling, and so on; but some of the motivations are personal, historical, or intrinsic;

(One of the intrinsic issues we struggle with is the W3C’s historical insistence on accepting input from all ‘as equals', and the whatwg’s insistence on reflecting reality; we probably never will resolve what happens when the population and reality diverge — at least, it’s a problem societies, and political theorists, have struggled with for millennia).

I think both bodies should rightly be hesitant to pick up work started in the other, but there are reasons; I support Florian’s request to be clear what those reasons are when we do it. For HTML, I doubt we need to say a lot at W3C; it’s hard to imagine the consortium walking way from a foundational specification, and it deserves the patent policy coverage.

Another reason might be the need to get an imprimatur that is recognized by other standards bodies, regulators, and the like.

David Singer Manager, Software Standards, Apple Inc.

[stevefaulkner]

@tantek wrote:

To me this signals that all versions of HTML could/would benefit from a delta document from HTML that specifically adds/patches accessibility related items, a "W3C HTML Accessibility" spec as it were. The advantage of such a spec is that such accessibility enhancements would get properly highlighted rather buried in the W3C's copy of HTML 5.x which browser implementers in general don't bother reading.

I think there is a misunderstanding. The HTML accessibility implementation aspects are largely developed at the W3C, the WHATWG defers to these. https://w3c.github.io/html-aam/ in browsers and http://w3c.github.io/html-aria/ for use of ARIA attributes in HTML. Implementers don't look to whatwg for these things at all.

The issue is around the HTML specification as a specification for the rest of us, those that are not browser implementers. A vastly larger and more diverse audience. Who come to the HTML spec looking for information on how to use HTML and to understand the semantics of HTML. This is what I personally have been working on at the W3C, as it is not a high priority for the browser centric focus of the WHATWG. I do not believe in this case a separate delta is the way to go, as it ghetto-ises accessibility information for developers that should be and is, in the w3c HTML spec, an integral part of the author advice and requirements, as it should be.

@michaelchampion wrote:

I definitely understand Steve’s concerns about “ the priorities and ideological orientations of the editors of the WHATWG spec are different to mine” and “ W3C… is still also the place where stakeholders with a commitment to accessibility, regardless of their affiliation with browser vendors, get a seat at the table”. But it’s worth noting WHATWG has become less “ideological” recently

The WHATWG is not organized to have non browser vendor stakeholders, it is very much a meritocracy of a subset of the browser vendors. Issues are decided by editors alone. So no, the publication of a code of conduct has not allayed my fears and realities of trying to work within the WHATWG structure. As real world interaction by myself and others on issues has continued to be problematic, and i can wander into a reddit thread where editors of HTML at whatwg, denigrate and besmirch mine and others work on w3c at HTML. I understand from a browser implementer centric view of HTML, the information contained in the HTML spec and the priority of providing good up to date author conformance advice and requirements is of less importance, but the vast majority of people that use the HTML spec are not browser implementers, and we need to provide for the many, not only the few.

I noted down my thoughts on this back in 2105 Thoughts on “Notes from the future of HTML session at TPAC”.

As far as HTML is concerned I would be happy to see a separation of concerns, where those that want to concentrate on the browser implementation aspects do so in whatever forum suits and those that want to work on the author related aspects of HTML do so likewise.

[chaals]

There are a variety of reasons why members want W3C to work on a spec that someone else is working on. Examples I know of include:

• A belief that W3C provides better security/accessibility/privacy/i18n/something else review
• A preference for contributions to be created under the W3C Patent Policy. (Note that by default we aim not to copy wwg work into the spec - much as hixie aimed to avoid using W3C content when he was working on the wwg specs. Although we're less religious about it - both versions are published under open copyright terms).
• A preference for working in an organisation that has a broader approach to determining key stakeholders than "a few browser-makers who effectively dominate the market between them", especially for deciding whose input to a consensus is considered relevant
• A belief that W3C provides a broad global reach and a respected source for distribution of its work, that is not matched by e.g. wwg, ISO, or other alternative versions.

For all I know, there may be many other reasons behind individual members' preferences.

[chaals]

While I think the discussion of this question is important, given the variety of reasons people have for what they want in or out of a charter this doesn't seem a valuable addition to the charter so much as an invitation to engage in second-guessing the rationales behind AC review, or to dump review comments (some of which are not made publicly and potentially some of which are Team-confidential) in toto into the charter.

The mandate of the WG is to work on the specifications that are listed as deliverables, to seek explicit approval from the AC to add anything to that list, and effectively if something is going to be dropped to inform the AC that this is the case - as we have done at AC meetings in particular.

I note that in the particular re-charter proposed here, we're looking for advice on whether or not to take up two deliverables produced through incubation and W3C-based processes, and whether to split off a piece of work in order to clarify an IPR/participation situation. None of the above seems directly related to the questions raised in this issue.

[frivoal]

I note that in the particular re-charter proposed here, we're looking for advice on whether or not to take up two deliverables produced through incubation and W3C-based processes, and whether to split off a piece of work in order to clarify an IPR/participation situation. None of the above seems directly related to the questions raised in this issue.

This is making me regret not formally objecting last time. On the previous charter and the one before it (but I wasn't an AC the first time), I raised the same issue. Last time I said in my AC review that I really thought it was important and hoped we could make progress on it, but would not object because I realized it takes time. A charter later, we're at the same point.

Invoking the fact that this isn't a new problem to call for focusing on more contemporary questions leaves a sour taste.

There are a variety of reasons [...] a preference for contributions [...] we aim not to copy wwg work [...] The mandate of the WG is to work on the specifications that are listed as deliverables

Alright, then I misunderstood the charter the two previous times. I kind of thought, since it was the only thing listed, that avoiding divergence from the WHATWG version was the most important objective, that we may fail occasionally because reasons, but that would be driving us.

You seem to be stating the exact opposite: that the primary mandate of the WG is to do independent work on all of these specs, the ones being also maintained at WHATWG not being a special case, and that the "make an effort to avoid differences" clause merely means "don't break the web", which being part of our normal modus operandi make this clause a no-op.

Ok, fair enough, it is possible to read the charter that way.

But I think this reinforces my initial point. The charter is vague, and ought to be clarified, because otherwise anybody can read what they want into it, from "we shall do our utmost to be as close a possible to WHATWG" to "WHATWG is irrelevant, we're doing independent work here". It is entirely possible that the editors have been doing what the member ship wants. It also seems possible to me that what the editors have been doing is almost the opposite of what the membership wants. It is also possible that the vast majority of the membership doesn't care one bit either way because we're far into consensus by attrition territory.

The fact that I can read the charter, look at what the editors and chairs have been doing, and have no clue as to whether you're doing a great job at what you were chartered to do or the very opposite is a problem.

I am not being facetious here. Compare with the i18n WG for instance, which also has a deliverable that overlaps with the WHATWG. That charter uses very similar wording: "The Working Group will work [...] to avoid differences [...] that would harm interoperability". However, over there, it means that the WG literally uses the WHATWG document as the editor's draft and puts a giant red and gold glowing warning on their TR spec inviting people to read the WHATWG document for the latest updates.

If the same phrasing can be the basis for that practice as well as the total editorial independence you advocate, then it is so broad as to be meaningless. Which is what this issue is about.

[michaelchampion]

@chaals noted:

I note that in the particular re-charter proposed here, we're looking for advice on whether or not to take up two deliverables produced through incubation and W3C-based processes, and whether to split off a piece of work in order to clarify an IPR/participation situation.

Right, although as Florian points out, it's also an opportunity to incrementally clarify a point of much contention over the years -- what value does W3C think it adds to the upstream WHATWG specs? This will help the membership assess W3C's investment in these specs at the next substantial rechartering opportunity.

[therealglazou]

Cf. my bullet point in my "message to all AB candidates".

mchampion said "what value does W3C think it adds to the upstream WHATWG specs?". Maybe we could also consider the value implementors - our users - think W3C adds to the upstream specs, ahem? About "mutual trust-building", there is no mutual trust. Let's be clear and let's avoid political correctness please : W3C considers WHATWG folks as painful revolutionaries, and WHATWG folks consider W3C as a retirement house. And no, I am not even exaggerating.

To be very clear, there is one single reason we have duplicates of that kind, and I said it myself during an AC meeting roughly 13 years ago so it's minuted somewhere: « the W3C cannot afford letting the flagship spec leave the consortium; in terms of image, it would be disaster ». It is a disaster.

As a reminder, after the Tokyo AC meeting (2006?) when the renewed work on HTML was discussed, W3C could have invented a new-style WG, between WHATWG and what legacy W3C stakeholders expected. It never happened that way, up to the point the new W3C HTML WG became a paragon for "overprocess" and "lack of pragmatism". Almost everybody stopped participating. The new HTML WG never attracted WHATWG people, it made them flee. It never attracted browser vendors, it made them flee. It never attracted me, it made me flee. It almost never attracted anyone, period.

Eleven years later, W3C's still trying. Trying what, I don't really know, but it's still at it. Turn it every way you want, it's not any more a problem of « W3C is not agile enough » in the present. It really is « W3C did not listen » in the past. Done. Too late. Move on, please. 5.0 triggered some press because of the number and the logo, not the contents. Nobody cares about the contents. It kills me to say it but nobody cares, absolutely nobody, and I don't even care myself. Most importantly, our users - implementors - don't care. Nothing left to see here.

In that light, the html work, the DOM work and more recent others duplicates from WHATWG at W3C are wasted money, wasted time, wasted energy and confusion for everyone. Furthermore, they not only make the W3C ridiculous, they make it desperate.

[dwsinger]

Hi Daniel

I agree with much of what you say here. Yes, the W3C has taken a lot of the steps that were necessary when WhatWG was forming — more open, more agile, more pragmatic, and so on — but that was then. Persuading people that the work to set up an alternative is not needed is much easier than persuading them to tear down a functioning alternative that they have already created.

I think we need to do what Florian asks: just be clear about why we are doing what we’re proposing, and why it makes sense. I agree with you for HTML; it’s a flagship spec. that the W3C cannot walk away from. (I have to say I find it quite funny that W3C and WhatWG each remove material from the other’s work that they say is too speculative or not well enough supported.)

On May 22, 2017, at 14:10 , Daniel Glazman notifications@github.com wrote:

Cf. my bullet point in my "message to all AB candidates".

mchampion said "what value does W3C think it adds to the upstream WHATWG specs?". Maybe we could also consider the value implementors - our users - think W3C adds to the upstream specs, ahem? About "mutual trust-building", there is no mutual trust. Let's be clear and let's avoid political correctness please : W3C considers WHATWG folks as painful revolutionaries, and WHATWG folks consider W3C as a retirement house. And no, I am not even exaggerating.

To be very clear, there is one single reason we have duplicates of that kind, and I said it myself during an AC meeting roughly 13 years ago so it's minuted somewhere: « the W3C cannot afford letting the flagship spec leave the consortium; in terms of image, it would be disaster ». It is a disaster.

As a reminder, after the Tokyo AC meeting (2006?) when the renewed work on HTML was discussed, W3C could have invented a new-style WG, between WHATWG and what legacy W3C stakeholders expected. It never happened that way, up to the point the new W3C HTML WG became a paragon for "overprocess" and "lack of pragmatism". Almost everybody stopped participating. The new HTML WG never attracted WHATWG people, it made them flee. It never attracted browser vendors, it made them flee. It never attracted me, it made me flee. It almost never attracted anyone, period.

Eleven years later, W3C's still trying. Trying what, I don't really know, but it's still at it. Turn it every way you want, it's not any more a problem of « W3C is not agile enough » in the present. It really is « W3C did not listen » in the past. Done. Too late. Move on, please. 5.0 triggered some press because of the number and the logo, not the contents. Nobody cares about the contents. It kills me to say it but nobody cares, absolutely nobody, and I don't even care myself. Most importantly, our users - implementors - don't care. Nothing left to see here.

In that light, the html work, the DOM work and more recent others duplicated from WHATWG at W3C are wasted money, wasted time, wasted energy and confusion for everyone. Furthermore, they not only make the W3C ridiculous, they make it desperate.

David Singer Manager, Software Standards, Apple Inc.

[therealglazou]

Yes, the W3C has taken a lot of the steps that were necessary when WhatWG was forming — more open, more agile, more pragmatic, and so on — but that was then

No it did not. WHATWG started back in 2004 after almost 3 years of warning on XHTML2 from the whole community including browser vendors (I was there, saw Microsoft complain, did complain myself with Beth Epperson on behalf of Netscape). WHATWG started because W3C did NOT take the steps that were necessary. The very first step W3C took was in 2006, announcing the re-creation of a HTML WG, and it was probably already too late. Then the group was launched. If I skip the first months, the next 3 chairmen were absent OR dictator OR the contrary of pragmatism. Everyone warned about it again, no result, just like when we warned about XHTML2. Then came unconference fashion, community groups and now incubation. So basically, W3C is losing what was its own philosophy while gaining nothing.

No the W3C is not open. Its management is opaque and remains opaque. Individuals still can't join a WG. No the W3C is not agile, and I don't even think it can become agile without being rebuilt. And no the W3C is certainly not pragmatic, pragmatism would make it recognize html is dead at W3C.

I agree with you for HTML; it’s a flagship spec. that the W3C cannot walk away from.

This is not what I said, I said it's the reason why it happens. To be even clearer, W3C's "strategy" on html is based on a 13 years old decision that the flagship spec must not fall. It HAS fallen, period and hiding the truth behind a plaster (the WG) and words (communication) won't change it.

[LJWatson]

@Chaals

"While I think the discussion of this question is important, given the variety of reasons people have for what they want in or out of a charter this doesn't seem a valuable addition to the charter so much as an invitation to engage in second-guessing the rationales behind AC review, or to dump review comments (some of which are not made publicly and potentially some of which are Team-confidential) in toto into the charter.">

I think we should include something in the charter. The AC will have the opportunity to let us know if it's a fair representation, when the charter goes for AC review.

@MichaelChampion suggested acknowledging the WHAT WG in the text I proposed. Here's an attempt to do this: "The Web Plat form WG and the WHAT WG both produce versions of the HTML specification. The Web Platform WG works on the HTML specification in order to protect it under the W3C Patent Policy. It also develops the HTML standard with contributions from a broad range of stakeholders, including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security. This ensures that HTML remains royalty free for use by implementors and authors, and that it is a robust and reliable standard that is relevant to all stakeholders."

@TheRealGlazou

"Individuals still can't join a WG.">

You might want to look at the AG WG as an example that demonstrates otherwise. It has 81 participants from 37 member organisations, and 26 Invited Experts (IE). In other words, more than 25% of the WG consists of individual participants.

[chaals]

@LJWatson:

@michaelchampion suggested acknowledging the WHAT WG in the text I proposed. Here's an attempt to do this: "The Web Platform WG and the WHAT WG both produce versions of the HTML specification. The Web Platform WG works on the HTML specification in order to protect it under the W3C Patent Policy. It also develops the HTML standard with contributions from a broad range of stakeholders, including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security. This ensures that HTML remains royalty free for use by implementors and authors, and that it is a robust and reliable standard that is relevant to all stakeholders."

Patent Policy protection may be primary for some members, as suggested in this text. But I would likely request changes, since while it is a valuable feature of W3C and important to the work, it isn't one of the 3 core reasons for asking W3C to continue developing HTML. Global recognition, Governance Model, and quality review in some key horizontal areas are all more important.

[chaals]

@michaelchampion:

[this discussion, orthognal to the questions asked in this proposal to change the current charter, is] also an opportunity to incrementally clarify a point of much contention over the years …

It is unclear to me whether this question needs to be resolved for this charter change, which is to add two deliverables and split one out for administrative purposes. I guess that will become clear when the W3C members review the charter.

… what value does W3C think it adds to the upstream WHATWG specs?

As far as I am concerned, the WHATWG spec for HTML is not upstream. It develops in parallel, under different procedures, with slightly different audiences. The editorial team, in particular, look to make sure we're not unconsciously breaking the web by introducing incompatible changes or failing to follow reality, and changes made first to W3C specs are, as applicable given the different approaches, taken into the WHATWG specs.

The same might be the case for e.g. ISO HTML (except they are so slow it's not a realistic case), and is the same as the fact that implementation - both in terms of browser support and HTML published to the Web - are effectively versions of HTML developing in parallel.

That said, I think there are a number of values I outlined above, and which I am aware of as variably important to different W3C members, in each case ranging from irrelevant to critical across a different subset of the membership whose motives I believe I understand.

[wseltzer]

This question is distinct from adding deliverables to Web Platform, so I suggest that it not hold up the advancement of WebPlatform recharter.

[therealglazou]

You might want to look at the AG WG as an example that demonstrates otherwise. It has 81 participants from 37 member organisations, and 26 Invited Experts (IE). In other words, more than 25% of the WG consists of individual participants.

IEs don't do Spec Reviews nor Charter Reviews. I am speaking of official participation. Furthermore, IEs don't join, they are invited and that's entirely different.

[frivoal]

This question is distinct from adding deliverables to Web Platform, so I suggest that it not hold up the advancement of WebPlatform recharter.

The proposed charter was not only about adding/splitting/removing deliverables, but also about a charter extension. For a charter extension, longstanding issues that should already have been addressed one or two charters ago are absolutely in scope.

While we're at it, this prompted me to check if there were more differences. Since I don't think a diff was provided, here's one: http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F11%2Fwebplatform-charter.html&doc2=http%3A%2F%2Fw3c.github.io%2Fcharter-html%2Fwebplat-wg.html

Besides minor rephrasings, I note that one paragraph was dropped form the scope section, even though that difference is not listed in the changes section. I've open an issue about that.

[michaelchampion]

@wseltzer wrote:

This question is distinct from adding deliverables to Web Platform, so I suggest that it not hold up the advancement of WebPlatform recharter.

Agree. I had let hope overrule experience in my suggestion to make a conciliatory gesture with a respectful reference to the upstream WHATWG specs and a statement of what additional value W3C hoped to add. Given that one of the chairs doesn't even agree that the WHATWG specs are upstream, and disagrees with the widespread belief that the primary value add comes from the patent commitments, I doubt if @frivoal's issue can be resolved in this charter.

[frivoal]

Given that one of the chairs doesn't even agree that the WHATWG specs are upstream, and disagrees with the widespread belief that the primary value add comes from the patent commitments, I doubt if @frivoal's issue can be resolved in this charter.

I have some doubts too, but under the circumstances, is it reasonable to grant a charter extension? Especially when this issue was raised on the previous 2 instances of this charter, and dealing with it in parallel has mean not dealing with it.

I had let hope overrule experience [...]

It goes both ways.

I am not sure I want to let the hope that this issue will be worked on if we approve charters that do not address it overrule the experience that it will be ignored until the next renewal, at which point we won't have time to handle such a thorny issue and will need to approve the charter so that work can proceed, but surely we'll deal with it before the 2021 charter. Or the one after.

[dwsinger]

On May 22, 2017, at 20:26 , Daniel Glazman notifications@github.com wrote:

Yes, the W3C has taken a lot of the steps that were necessary when WhatWG was forming — more open, more agile, more pragmatic, and so on — but that was then

No it did not.

You are missing my point. We have started to do NOW what should/could have been done THEN. If we had taken action in those days, the outcome might have been different. But there is a lot of difference between closing the barn door with the horse inside, and closing the horse inside after the door has been open for several years. What might have been sufficient then is not sufficient now.

No the W3C is not open. Its management is opaque and remains opaque.

It’s improving; changing.

Individuals still can't join a WG.

Sure they can. They can ask their AC to make the commitment, if they are in a company, and they can ask to be an IE.

No the W3C is not agile,

I said it was improving. There is still much to do.

David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

On May 23, 2017, at 5:40 , Daniel Glazman notifications@github.com wrote:

You might want to look at the AG WG as an example that demonstrates otherwise. It has 81 participants from 37 member organisations, and 26 Invited Experts (IE). In other words, more than 25% of the WG consists of individual participants.

IE don't do Spec Reviews nor Charter Reviews. I am speaking of official participation.

IEs are as much a member of the public as anyone else and we invite comment from them, and we tend to take public comment quite seriously.

David Singer Manager, Software Standards, Apple Inc.

[jeffjaffe]

On 5/23/2017 10:56 AM, Florian Rivoal wrote:

Given that one of the chairs doesn't even agree that the WHATWG
specs are upstream, and disagrees with the widespread belief that
the primary value add comes from the patent commitments, I doubt
if @frivoal <https://github.com/frivoal>'s issue can be resolved
in this charter.

I have some doubts too, but under the circumstances, is it reasonable to grant a charter extension? Especially when this issue was raised on the previous 2 instances of this charter, and dealing with it in parallel has mean not dealing with it.

I had let hope overrule experience [...]

It goes both ways.

I am not sure I want to let the hope that this issue will be worked on if we approve charters that do not address it overrule the experience that it will be ignored until the next renewal, at which point we won't have time to handle such a thorny issue and will need to approve the charter so that work can proceed, but surely we'll deal with it before the 2021 charter. Or the one after.

I think this issue can be discussed at two levels.

One level is the literal request of this issue "state a reason when duplicating work done elsewhere". For this issue I had proposed text early in this thread which I thought could be supported as a logical explanation both by those who are most passionate about the work in W3C and those that are most skeptical about the work in W3C. I didn't see any substantive attacks on my proposal - yet my proposal did not seem to get any traction. Accordingly, I am willing to withdraw my proposal.

One of the reasons that I am willing to withdraw my proposal is because I think that the paper exercise of "stating a reason" is far less important than the second level of discussing this issue.

The second level of discussing this issue is to actually get the two communities (W3C and WHATWG) that are doing overlapping work to work more closely together. To me, that's the real issue. It is not all that important that we write down in the Charter why there is duplicate work. It is amazingly important that we minimize that duplicate work by being a single team.

Again, if anyone can help facilitate that discussion with the WHATWG, I and the rest of W3C would be very happy to work on the real issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-303424775, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22kazdVQIe1x5wqV7KAYwWfKR-tGcks5r8vOWgaJpZM4Nb6X5.

[LJWatson]

@MichaelChampion:

I had let hope overrule experience in my suggestion to make a conciliatory gesture with a respectful reference to the upstream WHATWG specs and a statement of what additional value W3C hoped to add. Given that one of the chairs doesn't even agree that the WHATWG specs are upstream, and disagrees with the widespread belief that the primary value add comes from the patent commitments, I doubt if @frivoal's issue can be resolved in this charter.>

We haven't given up yet. Let's make this work if we can.

The WebPlat chairs and team discussed this today, and I agreed to take another run at finding some words that took into account everyone's comments. Here they are: "The Web Platform WG and the WHAT WG both produce versions of the HTML and DOM specifications. The Web Platform WG works on the HTML and DOM specifications for many reasons, including:

• The specifications are protected under the W3C Patent Policy, ensuring that HTML and DOM remain royalty free for use by implementors and authors;
• The specifications are developed with contributions from a broad range of stakeholders including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security;
• The specifications are produced by a globally recognised standards organization, with a governance model that is designed to find consensus amongst the many diverse constituents of the web platform."

I've tried to find words that encompass the most likely reasons people choose to work on HTML at W3C, but which do not (I hope) reopen old wounds. It would afterall be a good thing if we could find a way for W3C and WHAT WG to work together again in the future.

All that said, we don't want to hold up this charter review any longer than we have to. Most importantly, we don't want to hold up the people who want to get work done.

Unless there are strenuous and tangible objections to the proposed text, I suggest we include it in the charter and get it out to the AC for review?

@frivoal thanks for spotting the other issue. I think it was an oversight, but will look into it and either reinstate it or provide a rationale.

[chaals]

I "closed" this automatically (and unintentionally) by committing a change that added Léonie's text proposed above. Reopened in case its necessary

[frivoal]

@jeffjaffe

I agree that the second level (finding a way to work together) is the more important goal. The reason I insist on the first level (stating the reason) is that I see it as a necessary precondition: unless the W3C stakeholders are in rough agreement on what our position is, we cannot hope to clearly and consistently communicate to the WHATWG what that position is, to explain our actions, or to have a productive dialog as to what adjustment to our ways or theirs could lead to closer cooperation.

@LJWatson Thank you for the proposed text (and thank @michaelchampion for the earlier draft) . I think it does capture much of what has been said here. I would add one more thing to it based on what @chaals described the work mode to be, since it seems a direct and important consequence of the reasons you quoted. Proposal (additions compared to your text in bold):

The Web Platform WG and the WHAT WG both produce versions of the HTML and DOM specifications. The Web Platform WG works on the HTML and DOM specifications for many reasons, including:

• The specifications are protected under the W3C Patent Policy, ensuring that HTML and DOM remain royalty free for use by implementors and authors;
• The specifications are developed with contributions from a broad range of stakeholders including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security;
• The specifications are produced by a globally recognised standards organization, with a governance model that is designed to find consensus amongst the many diverse constituents of the web platform.

Based on these considerations, recognizing the different governance and priorities of the WHATWG, and in full awareness that these documents originated at the WHATWG, the Web Platform WG does not treat the WHATWG as upstream for ongoing work, and intends to exercise independent editorial control over these specifications. The Web Platform Working Group should nonetheless make an effort to avoid differences between WHATWG and Web Platform WG specifications that harm interoperability on the Web.

(the bit in italic does not change how the work is/will be conducted, and therefore could be considered optional, but giving credit where credit is due is good, and the previous text did include recognition that these documents originated at the WHATWG)

I do not know if this would get the approval of the AC or if some members may think that their goals are in conflict with this, but it does seems to reflect the reality of how these specifications are handled today, and is specific enough to that people can meaningfully say whether or not they agree with this policy.

If this (or minor tweaks to it) gets the approval of the AC, I think we will have a significantly clarified charter.

If it does not, that would mean that (part of) the AC opposes the current working mode, and I would then suggest that for this charter update we strictly limit the modifications to the changes in deliverables, that we do not extend the duration this time, nor include the scope change discussed in #142, and keep working at trying to resolve this issue in anticipation of the next full-scale charter renewal.

[therealglazou]

@jeffjaffe said:

The second level of discussing this issue is to actually get the two communities (W3C and WHATWG) that are doing overlapping work to work more closely together

We spent the last eleven years trying to achieve that. With little to no success. My discussions with some key whatwg members during Lisbon TPAC were enlightening on that point. Could you please explain what could be done, after eleven years of little or no success following changes I would qualify as « desperate », to finally ease the pain and bridge the gap? I'm not buying a lone « yes, we can » any more while W3C struggles with hyper-crucial and immediate financial issues elsewhere. Please explain why and how this is still worth the huge investment.

Addendum: sorry, I don't see "W3C and WHATWG" as "doing overlapping work". WHATWG works, we fork.

[LJWatson]

@frivoal Thanks for proposing the additional text.

I don't think it's helpful to state where these specifications originated. In their current form, both specifications represent work done at W3C, at WHAT WG, and (for HTML at least) in collaboration between the two. The purpose of the charter is to describe the work that will be done, not to reopen painful (and likely unwinnable) arguments.

Speaking for myself, I find it clumsy and unnecessary to state that the WG has editorial control over its specifications. That said, I've tried to include the salient points from your proposed content in a way I hope will be uncontentious.

"The Web Platform WG and the WHAT WG both produce versions of the HTML and DOM specifications. The Web Platform WG works on these specifications for many reasons, including:

• The specifications are protected under the W3C Patent Policy, ensuring that HTML and DOM remain royalty free for use by implementors and authors;
• The specifications are developed with contributions from a broad range of stakeholders including implementors and authors, as well as specialists in accessibility, internationalisation, privacy, and security;
• The specifications are produced by a globally recognised standards organization, with a governance model that is designed to find consensus amongst the many diverse constituents of the web platform. Based on these considerations, the Web Platform WG exercises independent editorial control over these specifications. The WG nonetheless endeavours to minimize differences between the WHAT WG and W3C versions that affect interoperability."

[frivoal]

@LJWatson This tweaked wording is acceptable to me. It seems a like a fairly accurate and sufficiently complete description of how the group operates and why.

As long as we don't forget to give proper credit to the original authors of each specification within the specification itself (but we need to be careful about that), I don't think it's that big a deal if the charter doesn't say so.

As for whether it is necessary to state that we exercise independent editorial control, I think it is, since it could other approaches are possible and have been applied in different groups or at different times. Because of this possible ambiguity, it is useful to state what it is we do.

[jeffjaffe]

On 5/24/2017 3:33 AM, Daniel Glazman wrote:

@jeffjaffe https://github.com/jeffjaffe said:

The second level of discussing this issue is to actually get the
two communities (W3C and WHATWG) that are doing overlapping work
to work more closely together

We spent the last eleven years trying to achieve that. With little to no success. My discussions with some key whatwg members during Lisbon TPAC were enlightening on that point. Could you please explain what could be done, after eleven years of little or no success following changes I would qualify as « desperate », to finally ease the pain and bridge the gap?

I don't have any magic solutions or I would have already implemented them. As with the Good Friday Agreement, there are often seemingly intractable problems (far worse than W3C/WHATWG) that go on for decades. Often a change or maturing of attitude is what is needed for resolution. That often comes about when someone trusted by both sides helps both sides understand that the world would be a better place if folks just try to get along.

I'm not buying a lone « yes, we can » any more while W3C struggles with hyper-crucial and /immediate/ financial issues elsewhere.

I don't understand what improved collaboration with WHATWG has to do with financial issues. Other than reduced duplication in theory frees us talent so we can all do more.

Please explain why and how this is still worth the huge investment.

I'm not proposing any huge investment.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/charter-html/issues/139#issuecomment-303642432, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN22jiDyBy3-mO_56bgfk53i73DpoO3ks5r891IgaJpZM4Nb6X5.