Thanks. The TL;DR seems to be that, instead of sticking to documenting what is, the W3C is (either deliberately or through incompetence) trying to push their own "vision" for DOM 4.1 without browser buy-in.
Let's say you are a) owning and b) managing a project that three competing teams are working on in parallel.
If you will not curate the project you will have one team adding <marquee> and another team adding <blink>...
In real world you would invite dedicated architect or team of architects to define the spec that all 3 teams will implement.
All that WHATWG vs W3C flame is about bazaar vs cathedral management style I think.
Origins of the mess: W3C itself has no architects on board - they are just trying to moderate votes of others. Where each vote has an obvious weight (weight(Google) > weight(JohnButSmart)).
In contrary WHATWG has professional architect on top of the construct - Ian Hickson. In fact WHATWG was created by him. But Ian is associated with Google and that makes WHATWG legitimacy a bit questionable.
There is a formal group, the Steering Group, which represents the browsers that implement WHATWG standards, and serves as the point of final appeal if the community doesn't come to a consensus on its own. But this is similar to the W3C appeals track where if all the paying member companies don't come to consensus, they appeal to "The Director" as the ultimate decider. ("The Director" is nominally Tim Berners-Lee, but recently all Director decisions have been made by W3C management "on behalf of" The Director.)
To me, this is giving browser makers even more power over HTML than they have otherwise.
Of course, we have lots of work to do, and if you or anyone else are able to devote a good chunk of time to standards work, we'd love to have more editors---no matter what company they work for.
Browser engine developers comprise the steering group, since ultimately we want the specs to reflect what will be implemented in web browsers, so the best way to resolve disputes about what should be in the spec is by asking the people who will be spending their resources to implement it what they think. I think this is probably the right way to go, instead of "The Director" having the final voice.
Thats actually nice to know, but specifically about HTML (which is one of the most important specs the whatwg works on) it's all browser makers. (That too, majority of them from one particular browser maker).
>I think this is probably the right way to go, instead of "The Director" having the final voice.
I think having a better mix of people in the decision making process than just browser makers would be the right way to go. I understand that browser makers have to implement the specs, but the web community as a whole has to use the specs to build the web of the future - and as such, people from non-browser companies should have a greater say in the final voice.
Bloomberg is know for its Terminal. It seems they have a program where you can extend their terminal with web applications. Presumably Bloomberg didn't built a renderer themselves but there are custom APIs. So they are something between a browser maker and a UI framework like Electron.
Disruptive Innovations is a firm by Daniel Glazman, formerly of Netscape and of the CSSWG fame. His main product seem to be continuing the Editor part of the original Mozilla Suite based on the Gecko Layout Engine. There seems to be an NVU Editor and rather new an Editor called BlueGriffon which also does ePub and maybe his custom WebBooks format.
In fact, I would say that it's not quite like a cathedral and bazaar here.
The W3C is like a legislative committee. Lots of things done by committee vote. Formal process that must be gone through to advance beyond committee. Petty politics that screw with actually getting things done. The committee chair having the ability to block work by procedural means.
The WHATWG is more like an open forum. The work happens out in the open. Anyone can participate in the discussion (the W3C committees frequently have private meetings, there have been private mailing lists, and so on). There are a few people who have commit rights to the repo, so who actually control what goes in and what doesn't, but they are generally willing to let in changes that have broad support, and are implementable, rather than letting such features get held up by political processes.
Besides the difference in structure, there's just a difference in attitudes. The W3C tends to strongly favor certain principles, like accessibility and modularity, but to the exclusion of compromise for technical reasons or real-world reasons. They also seem to have a tendency to get very attached to particular ways of doing things, without being willing to compromise. I think the biggest example of this was longdesc; it was never implemented properly in pretty much any browser, and very few people actually followed the spec and had it point to a URL (many people just copied the alt tag, or provided a longer description in the attribute instead of a URL), so even if browsers or screen readers had implemented it, the content wouldn't be useful. But people in the W3C made a big stink about removing this, and spent a lot of time and effort fighting and litigating over that, rather than actually trying to work on a different feature that could gain wider adoption.
The WHATWG tends to take a more pragmatic approach; pave the cowpaths, if there are differences between implementations do it in the most sensible way that preserved compatibility.
Now, what the WHATWG has produced hasn't always been the best; there are times when it's made mistakes in its approach. The drag and drop spec, which had been reverse-engineered from IE's drag and drop support, was a pretty bad; not sure if it's gotten better since.
But overall, the WHATWG has been a lot more productive in getting standards done that are actually used on the web, because they involve the implementers, and don't override them with tedious, drawn out, political battles over obscure features that no one uses.
Additionally, the W3C has some private mailing lists, does private working group meetings, and so on. So yeah, the WHATWG is a lot more open when it comes to input.
For all the web platform stuff (I don't know about the semweb and digital publishing side of things), you can basically ignore the existence of the private mailing lists (they get basically no traffic, and people like me start screaming whenever anyone tries to have a technical discussion there). I'd rather they didn't exist, but realistically they're not a barrier to participation.
The F2F meetings and telecons are more problematic (because both are inherently exclusionary, either in time or in travel), but those are at least publicly minuted and any resolution from them can be overturned.
10-15 years we were told that use of <table>s for layout purposes was terribly wrong. Without any reliable alternative mechanism.
Here is my proposal to W3C CSS WG to add flow property and flex units: https://www.terrainformatica.com/w3/flex-layout/flex-layout.... It covers as flexbox as grid features under the same mechanism. Yet it establishes robust framework for other layout methods.
Note it is dated April, 5, 2009. It took us almost 10 years to have something matching that.
So neither W3C process nor WHATWG process is perfect - there is no reliable feedback from customers (web designers) to browser vendors.
What if browser would provide us just abstract DOM with minimal HTML/CSS implementation and some extensibility/plug-ins mechanism with something like Java.
In this case we, the community, can provide better implementations:
main {
flow: HolyGrailLayout(params) url(/layouts/HolyGrail.class);
}
<main>
<header>
<footer>
<aside>
</main>
In this case W3C will be able to perfectly fit its role - high-level management of all this.
No one can manage the reality up to need of toilet paper in full. USSR tried and where did it go?
That's what Houdini layout extensions are about, if that work ever comes to fruition that will indeed be a pretty major advance for web design.