> Serious question: why are the W3C still publishing or trying to publish standards for DOM and HTML and probably a few others, when no one that matters cares about them?
There is a potential legitimate role for the two-track approach, if WHATWG represents a moving target of what browser vendors have agreed to implement and essentially is the vehicle for documenting hmthe agreed future common web platform, and W3C presents a versioned publication of the stable, widely implemented, currently usable state at a particular point of time; the W3C version would then be the target for conservative app developers that need something that works everywhere today, the WHATWG standard would be what people making browsers and other user agents would target, and what more ambitious developers willing to deal with “can I use...?” pitfalls would be guided by.
Why cant people just use an older copy of the WHATWG standard as the new "stable" documentation? This is basically how caniuse.com and browserslist work today, allowing developers to precisely describe their compatibility targets and even automate their builds.
It seems unnecessary to have an entirely separate organization to just copy/paste/publish new "versions" of existing archives.
> Why cant people just use an older copy of the WHATWG standard as the new "stable" documentation?
Because the order of incorporation into the standard and the order of implementation and stabilization aren't the same, and some fesutres may be implemented incompletely in some browsers, so that what is stable and usable is a subset of features (and sometimes a subset of functionality within a particular feature) that doesn't correspond to any particular version of the LS. So you'd need manual curation.
> It seems unnecessary to have an entirely separate organization
Perhaps, though the audience and thus interested parties for the implementor-focussed spec and the developer-focussed spec are different.
The WHATWG is actually the only organization I know of that publishers a developer-focused specification; see https://html.spec.whatwg.org/dev/. (We only do it for HTML currently.)
Anyway, I agree with the grandparent poster that caniuse.com is a much better approach to documenting the interoperable subset than copying and pasting someone else's spec, and trying to delete the parts that are not interoperable by some threshold. We actually have caniuse.com boxes in the margin of the HTML Standard: see for example https://html.spec.whatwg.org/multipage/scripting.html#attr-s...
Finally, it's worth noting that we only incorporate features into WHATWG Living Standards if they have multiple implementer interest; see https://whatwg.org/working-mode#additions
I don't really understand how this would make the two-track approach legit. Couldn't they just version the specification under WHATWG if that's what they're after?
I just can't see a reason for the W3C to be handling any of this anymore except for money reasons.
Many years ago I tried to get a membership to the W3C as I wanted to provide a voice for a company I worked for (and for myself, honestly) but found out that the lowest level of membership was many thousands of dollars. How can anyone who isn't already very well established ever be properly represented there?
Then you check out WHATWG and, as far as I can tell, there are never fees associated with being a member and participating.
Yeah, we try to make the WHATWG a welcoming place for all, with no pay-to-play structure. Please feel free to provide your voice there! We've gotten a lot of good community contributions and ideas.
W3C process dictates that two implementations exist, not that all major browsers implement the whole standard. Thus, a W3C fork of the standard is of no practical use to “conservative app developers”.
If you need to target specific (probably legacy) browsers, you check caniuse.com. By the way, the WHATWG HTML standard integrates little boxes with caniuse.com data. That is indeed useful to developers.
There is a potential legitimate role for the two-track approach, if WHATWG represents a moving target of what browser vendors have agreed to implement and essentially is the vehicle for documenting hmthe agreed future common web platform, and W3C presents a versioned publication of the stable, widely implemented, currently usable state at a particular point of time; the W3C version would then be the target for conservative app developers that need something that works everywhere today, the WHATWG standard would be what people making browsers and other user agents would target, and what more ambitious developers willing to deal with “can I use...?” pitfalls would be guided by.