
W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM - klez
https://www.w3.org/blog/news/archives/7753
======
snek
To clarify why WHATWG exists and why W3C lost power over the HTML spec:

Around 2004 W3C abandoned organizational effort on HTML in favor of things
like XHTML2, XEvents, semantic web, etc. The WHATWG was formed in reaction to
that, rewriting HTML completely from its W3C HTML 4.0 version for example to
make it better for web applications and to specify things in more detail.

Since the formation of WHATWG, W3C HTML specs became copy-pastes (often not
even correct copy-pastes) in an effort to satisfy paying member companies
([https://github.com/w3c/charter-
html/issues/14#issuecomment-1...](https://github.com/w3c/charter-
html/issues/14#issuecomment-108606731)).

You can see everything WHATWG maintains here:
[https://platform.html5.org/](https://platform.html5.org/) (they are the green
question mark)

The W3C still maintains a good chunk web standards though, such as CSS, Wasm,
web security, etc.

~~~
austincheney
That explains the HTML spec but not the DOM spec.

~~~
olliej
The DOM is specified as part of the HTML spec.

The whatwg HTML spec defines exactly how html is parsed, and exactly how every
element interacts the scripting environment. Just defining the grammar is not
sufficient.

Historically for instance something like

<bold>foo<italic>bar</bold>baz</italic>

Produced a different DOM tree in different browsers. WHATWG specified what
should actually happen. IIRC IE managed to produce a DOM graph rather than a
tree in the above example.

~~~
austincheney
The DOM is a completely separate unrelated specification.
[https://dom.spec.whatwg.org](https://dom.spec.whatwg.org)

~~~
olliej
fair point. I was conflating whatwg spec and html5 (Actually, it's possible
they were at one point the same spec - there was some work over the last 5 or
so years to stop putting literally everything in a single spec document,
unfortunately after a decade of web engine work everything turns into a single
amorphous blob)

~~~
austincheney
They were never the same. The closest thing is that the DOM spec and W3C’s XML
Schema spec were joint publications for several years.

~~~
olliej
What are you talking about? I am not talking about the W3C's nonsense, I was
fairly clear that I was talking about the actual _real_ spec, which is html5,
via the WHATWG [1]

What you claimed is absolutely wrong.

Please note that it defines the DOM interfaces for all of the core elements,
and more or less every DOM API, including all elements, as well as most
programmatic types - even things like the XHR objects. They used to all be in
a single giant "HTML living standard" document, and have in the relatively
recent past been split into separate spec docs (many of which reference the
original "living standard").

[1] [https://html.spec.whatwg.org](https://html.spec.whatwg.org)

~~~
austincheney
The WHATWG DOM spec was spun out of W3C DOM level 3. Neither document was ever
associated with or aligned to any version of HTML, though the WHATWG did try
something like that and backed off when all the browser vendors refused to
give them the time of day. Now the WHATWG document is largely the document of
record and W3Cs DOM level 4 is largely a snapshot of the WHATWG document.

None of this is either confusing or a mystery. It’s all out there in the open
and the people who maintain these documents respond to email. I typically
avoid talking about the DOM online because many developers aren’t aware of
what it is and are less aware of its history and sometimes people get
sensitive about it.

------
ChrisSD
I still maintain that the "living standard" is an oxymoron. It's a
collaborative browser dev document. Don't get me wrong, that's great. However
for everyone else an unversioned document, any part of which can change at any
moment, is not what's usually thought of as a standard.

~~~
userbinator
This obsession with "living" and constant change seems to be mostly confined
to the web --- instead of settling on a spec and then leaving it alone and
"doing what you can with what you have", those working on this stuff seem more
inclined with continuing to make browsers change.

I suspect at least part of the reason is to build a high barrier to entry and
preserve the monopoly, keeping out competitors, given who the people in these
groups work for.

My personal opinion on this is to stop feeding the monopoly and refuse to use
anything other than basic HTML for static content sites.

~~~
austincheney
> I suspect at least part of the reason is to build a high barrier to entry
> and preserve the monopoly

That is far too grand a motive. The reality is that the average web developer
has a shelf life of about 5 years or is primarily focused elsewhere, such as
Java or C#. That said consider the people who do this work with 100% focus.
These people are typically not the same developers who are performing graduate
level statistical analysis, building artificial intelligence, or resolving
quantum computing. The hiring expectations for front-end developers in the
corporate world tend to skew much lower, and the historical average salaries
for these positions reflect that. Taking this into account I suspect the real
reason for the constant churn is that many of these developers want things to
be _easier_ everything else be damned.

~~~
mynegation
You are already downvoted into oblivion and rightfully so, but I just wanted
to add my perspective as a backend developer (and the one who did post-
graduate level mathematical stuff at that) who now manages a team of back and
front end developers and plays with front end development for toy projects.
The sheer amount of complexity and required knowledge for front end
development is simply baffling to me. These folks have to know such disparate
technologies as CSS, HTML, Javascript as a bare minimum and it never stops
there. Typescript, templating engines, CSS preprocessors, huge and
continuously evolving javascript ecosystem, evented concurrency (please take
me back to my threads and semaphores), asynchronous state management in
complex UIs with non-trivial interdependencies... Compared to this stochastic
calculus is a breeze.

~~~
egeozcan
Totally agree. Also: I'm strongly against calling people "Front-End Developer"
or anything like that at all. Where does front-end start? Where does it end?
What is full-stack, does it imply you can do embedded? I've seen many listings
that count PHP as one of the front-end requirements. This is just a term that
should make the HR's job easier, and it does that badly.

~~~
Cyberdog
We web devs actually have pretty solid definitions for "front-end," "back-
end," and "full-stack." The back end deals with work on the server done after
an incoming HTTP request comes in and involves preparing the HTTP response,
including preparing the outgoing data for the templating layer if applicable
(eg, when doing web page responses rather than JSON, XML, or binary
responses). The front end deals with building templates such that that data
becomes a standard web page, using CSS to style that page, and using
JavaScript to implement client-side interactivity. A full-stack developer will
be constantly switching between work from both sides of this divide rather
than primarily focusing on one or the other.

If a job listing for a front-end developer is expecting applicants to know PHP
beyond a "writing templates" level, it's either a poorly-written job listing
or its creator has unrealistic expectations of its applicants - sadly, neither
case is very uncommon in this industry.

At any rate, someone calling themselves a full-stack developer isn't implying
they can do embedded, as that sort of stuff is pretty far afield of web
development.

------
Multicomp
Extremely condensed version:

W3C is giving up publishing future HTML and DOM standards. They will focus on
writing 'recommendations' for the WHATWG's living standards.

Versioned vs living HTML discussions aside, I personally admit some mild
sadness that the original group responsible for maintaining Sir TBL's work on
HTML has been forced to give up.

~~~
cotelletta
These are the same people who created XHTML, an ivory tower idea nobody was
waiting for... who didn't support the most popular layout method at the time,
tables, in their new styling language CSS.

W3C became irrelevant because they kept thinking they could just tell the
entire web what to do, that they'd make enormous technical investments to
satisfy the W3C's latest fashions.

I interacted with them once, over their seamless iframe proposal. I had to
point out that the two biggest uses of iframes at the time, i.e. Twitter
embeds and Facebook apps, could not make use of it, despite being a perfect
fit. They just hadn't considered that.

~~~
boomlinde
_> These are the same people who created XHTML, an ivory tower idea nobody was
waiting for... who didn't support the most popular layout method at the time,
tables, in their new styling language CSS._

You certainly could lay out pages using tables in XHTML, but the point of the
standard in the first place was to enable semantically sound documents for the
sake of interoperability and to facilitate separation of concerns. So maybe if
you authored XHTML documents that was already an important consideration to
you.

On a side note, now that the web development industry seems to have
collectively given up any ambitions for semantically sound documents it's
strange that the criticism against table-based layouts prevails.

~~~
amyjess
I honestly don't think either was the purpose. XHTML existed to make parsing
easier.

The only things you couldn't do in XHTML 1.1 Transitional that you could do in
HTML were having unclosed tags and using uppercase in tag names. That's it.

Now yeah, the strict version tried to force you into semantically sound
documents... but that was completely orthogonal to XHTML vs. HTML. Both XHTML
and HTML were available in both transitional and strict forms.

The real problem is that HTML is a massive pain in the ass to parse. You can
close tags out of order, some tags can't even be closed (<hr>), some tags can
_optionally_ be closed (<p>), nothing is case-sensitive, and because of how
flexible SGML is, you need a DTD to properly parse any SGML implementation
(fun fact: SGML allows for a bunch of different markup styles, but the HTML
DTD explicitly disallows most of them). XHTML sought to eliminate all that by
mapping HTML onto XML, which was _much_ easier to parse.

~~~
spiralx
Could you have unquoted attributes in transitional?

~~~
amyjess
Ah, I just checked, and no you can't. So I guess that's a third difference.
Thanks for the correction!

Another correction I noticed when looking that up: I meant to say XHTML 1.0
Transitional, not 1.1. 1.1 was Strict-only.

~~~
spiralx
And thinking about it weren't value-less attributes also illegal? I remember
doing a lot of

    
    
        <button disabled="disabled">...</button>
    

in XHTML, instead of

    
    
        <button disabled>...</button>
    

in HTML.

Even SGML has problems with expressing an attribute like that from what I
remember reading of someone's attempt to specify HTML 5 using an SGML DTD.

------
jrochkind1
On the one hand, good.

On the other, it seems like just complete capitulation by the W3C; WHATWG
makes all the real decisions still, W3C now performs important administrative
services for free, turning the "living standard" into an actual usable
standard, without actually having any meaningful power over the results.
WHATWG gets to do the part that matters without having to do the hard part,
W3C does the hard part for them without any control over what matters.

On the other other hand, sometimes when the battle is already lost, formal
capitulation is all that's left.

The browser vendors took control of the web standards process from any body
that might represent/balance multiple constituencies/interests, and that's
just how it is now.

~~~
mcchampion
W3C did try to balance multiple constituencies for HTML, but it couldn't find
consensus among them, and broad consensus is the basis for its authority.
WHATWG didn't so much take control of the standards process as recognize that
what actually works on the web defines the "stadard"

It's not a capitulation, it's a way to exert influence in a world that
respects rough consensus and running code more than formal processes and
authority. Under the agreement, W3C has the power to ratify (or not) changes
to HTML/DOM that align with the needs of its broad community for
accessibility, internationalization, privacy, security, etc. The agreement
provides a way for experts in those "horizontal" areas to participate more
effectively in WHATWG to get improvements made upstream, rather than
downstream in what amounted to a fork.

And yes, W3C provides the service of providing vetted snapshots of the Living
Standards into more formal standards that governments and other standards
bodies can reference and ratify. That's adding real value for some
constituencies.

~~~
jrochkind1
If they choose "not to ratify" something... will it have any effect on browser
behavior at all? I don't think so. It'd just be a standard none of the
relevant software cares about. Pretty useless to anyone. (Much like current
W3C html standards...)

Seems to me W3C will straight up be acting as administrative staff for WHATWG,
providing free labor to do the "hard parts" of providing a useful standard,
without much decision-making ability.

Without much decision-making ability is indeed the status quo. Now they're
providing some free labor too. But it's certainly less pointless than what
they were doing before, so.

~~~
mcchampion
> If they choose "not to ratify" something... will it have any effect on
> browser behavior at all?

W3C has no authority to change browser behavior, no. But they CAN influence
browser behavior by providing expert assistance to promote W3C's traditional
values (accessibility, internationalization, privacy, etc.) in WHATWG.

We'll have to see if W3C's ratification or not has an impact on the larger web
ecosystem, but it would probably get key customers' (and regulators) attention
if W3C refused to ratify changes to HTML, DOM, etc. on accesibility or privacy
grounds. Browser developers may respect W3C's supposed authority to set
standards, but they definitely do respect the opinions of customers and
authority of regulators.

------
inglor
In practice I've found that web standards are mostly driven by people who are
willing to spend the time and effort to iron our all the edge cases.

I've had a very pleasant experience contributing to things like `fetch` and
negative experiences contributing to some other things - essentially it's a
"people problem" more than a technology problem.

~~~
kevingadd
I find the pleasantness of the standards process depends on how many people
have strong opinions about the thing you're working on. Being involved in
'new' standards like fetch or gamepad or webgl is generally pretty relaxed
because while it's interesting to many people, there aren't a bunch of people
with Past Experience with the new api/standard and they aren't about to
dedicate a bunch of time to doing it themselves.

Coming in to try and fix problems or propose improvements for existing stuff
like canvas or XHR or whatever is another matter entirely, as you've probably
noticed. Thanks for helping make fetch good!

------
BinaryIdiot
It's probably an unpopular opinion but I'm all for progress that may
eventually lead to W3C's complete irrelevance. I've talked with folks at the
WHATWG before, _Anyone_ can provide input and work with them. With the W3C
it's, what, like $30k for the cheapest option and that barely gets you in the
door. The W3C is too expensive to ever let small businesses or individuals
have impact.

I'd love to see more groups like the WHATWG specifically for this reason.

~~~
frivoal
There were serious issues with the way HTML was done at W3C, and this
agreement between W3C and the WHATWG is a good thing.

However, all W3C specs are developed in the open, nowadays on github, and
feedback from anyone anywhere is taken seriously. Don't like something about
css? go here: [https://github.com/w3c/csswg-
drafts/issues](https://github.com/w3c/csswg-drafts/issues). Something wrong
with SVG?
[https://github.com/w3c/svgwg/issues](https://github.com/w3c/svgwg/issues). An
issue with the Payment Handler API? [https://w3c.github.io/payment-
handler/](https://w3c.github.io/payment-handler/). Dislike the way W3C itself
works? That's here:
[https://github.com/w3c/w3process](https://github.com/w3c/w3process)

Yes, the W3C is a membership based organization, and if you want to vote for
instance on who gets to be on its Advisory Board, or have a say in the Charter
of Working Groups, you need to be a member, and pay.

For the WHATWG, you don't get to vote on who's on the Steering Group, and you
don't get a say on what new Workstreams are started / changed / stopped, even
if you did want to pay. That's up to Google, Apple, Microsoft and Mozilla.
Sure anybody can suggest stuff (but that's true at the W3C too), but they
decide, and there's no way into that club.

Not to claim that W3C is perfect. Plenty of improvements are needed. But
claiming that small business or individuals cannot participate just isn't
true.

~~~
BinaryIdiot
Thank you. These are fair points. When attempting to talk to various folks
years ago the WHATWG always made it easier for me but I see your point.

------
martin_a
Maybe it's just me, but I've never heard about the WHATWG before. And for
everybody like me, that acronym stands for "Web Hypertext Application
Technology Working Group".

~~~
skrebbel
WHATWG is basically the browser vendors sidelining W3C to discuss what
features HTML etc should have. The news today is that the W3C finally accepted
that situation.

~~~
domenicd
> WHATWG is basically the browser vendors sidelining W3C to discuss what
> features HTML etc should have.

One way of looking at it is who has final say what ends up in the documents.
That seems to be what you're discussing.

In the W3C, that's the Director, Tim Berners-Lee. Except, as pointed out
elsewhere in this thread, he has delegated all his decision-making powers to
W3C staff. So ultimately it is the W3C CEO and the folks he hires.

In the WHATWG, that's the browser vendors (i.e., the WHATWG Steering Group). I
find the WHATWG model to make more sense, as I think what ends up in specs
should match what the implementers plan to do; that makes for a more useful
spec ecosystem for everyone. When you diverge too far from that model, you get
circa-20004 W3C, i.e. XHTML 2, XForms, XEvents, etc.

A different way of looking at it is who contributes to the discussion and
development of features. In the W3C, that's paying member companies
([https://www.w3.org/Consortium/fees](https://www.w3.org/Consortium/fees),
$2.25-$77k/year in the US). Although anyone can comment on GitHub, to
contribute ideas that get incorporated into the specification, you need to be
a W3C member, for IPR reasons. (Or invited expert, but that has its own
problems; see [https://medium.com/@tobie/w3c-doesnt-help-its-invited-
expert...](https://medium.com/@tobie/w3c-doesnt-help-its-invited-experts-it-
should-2fb36ae9f720.)) In the WHATWG, anyone can contribute; the IPR concerns
are taken care of by signing an agreement, somewhat like an open-source
project CLA, but that agreement does not require paying membership fees.

Overall, I think the WHATWG structure, of being open to input from all
(instead of pay-to-play), with the spec tracking what browsers intend to
implement (instead of tracking what W3C staff deems good), is a pretty great
model for standardization.

~~~
hungryfoolish
>Overall, I think the WHATWG structure, of being open to input from all
(instead of pay-to-play),

Thats not entirely fair. The WHATWG is also pay-to-play in a way - the browser
makers have disproportionally higher power, even more so than the w3c model
where there is at least some form of consensus forming among a group of people
with more international representation. Now technically anyone in the world
can open a github issue (w3c also does it though now), but thats about what
anyone can do to oppose something in the spec that the browser makers have
their hearts set on.

~~~
domenicd
Hmm, you seem to have skipped over some of my points.

The WHATWG is open to input from all, but only things browsers are willing to
ship get into the specs. So yes, that's more power. No disputing that. But I
would rather not have specs full of unimplemnted fiction, even if that fiction
has consensus among paying member companies.

The W3C is not open to input from all. If you open a GitHub issue contributing
an idea, but do not pay member fees, they cannot incorporate your idea into
the spec, because of Intellectual Property Rights concerns. There is no way in
the W3C to say "I sign over my IPR rights" without also paying thousands of
dollars per year.

~~~
frivoal
> The W3C is not open to input from all. If you open a GitHub issue
> contributing an idea, but do not pay member fees, they cannot incorporate
> your idea into the spec, because of Intellectual Property Rights concerns.
> There is no way in the W3C to say "I sign over my IPR rights" without also
> paying thousands of dollars per year.

This is not true: [https://www.w3.org/2019/Process-20190301/#contributor-
licens...](https://www.w3.org/2019/Process-20190301/#contributor-license)

------
ksec
W3C will now publish a Recommendation instead of a "version" as such. The
Recommendation will be from a "Review Draft" published by WHATWG, this draft
will then go through the W3C process (Candidate Recommendation → Proposed
Recommendation → Recommendation).

And then there is patent exclusion ( What? )

Anyway I don't see anything new to developers. Apart from the politics and two
parties bury the hatchet.

~~~
chrisseaton
Why don't W3C just leave it to WHATWG entirely? Why do we need two groups
involved? Why should I put any value in what W3C recommends? What would they
ever recommend instead of WHATWG?

~~~
klez
> Why should I put any value in what W3C recommends?

For the same reason you put any value in, e.g., ISO or ANSI. Because others
recognize them as _the_ standard organization and put value in what they
recommend.

~~~
danarmak
But no browser maker recognizes the W3C standard or claims to implement it, so
what good is it?

~~~
klez
That no browser maker recognizes W3C's standard is a bit misleading. MDN (i.e.
Mozilla) quotes the w3c recommendations all over the place.

Google, from what I found around, cites nothing, not even WHATWG.

Webkit cites MDN (which cites w3c) as a source.

~~~
danarmak
If I complain to Mozilla that they deviate from the W3C spec in some respect,
will they treat that as a bug, or will they more likely say "no-one implements
this, so no website uses this, so we have no reason to be the first to
implement this because we don't think this is part of the spec is really
important"?

~~~
kevingadd
Depends on the deviance. If it's 'this was changed in the whatwg spec' the
answer will probably be 'the next w3c spec will document this change, for now
here's <an explanation and/or an update to mdn>'. If the deviance breaks
production apps sometimes Mozilla will roll it back, it's happened before. In
other cases they'll treat it as a bug and fix it.

~~~
danarmak
Thanks, that's encouraging to hear!

Although I still worry about the case where _fixing_ the deviance would
_break_ production apps. Potentially break them, since people won't complain
until you release the breaking browser version. That's what's usually kept
browsers from hewing to standards.

------
domenicd
Folks may find the more-detailed blog post linked at
[https://www.w3.org/blog/2019/05/w3c-and-whatwg-to-work-
toget...](https://www.w3.org/blog/2019/05/w3c-and-whatwg-to-work-together-to-
advance-the-open-web-platform/) to be more clear.

Also, for the full details, here is a direct link to the agreement:
[https://www.w3.org/2019/04/WHATWG-W3C-MOU.html](https://www.w3.org/2019/04/WHATWG-W3C-MOU.html)

------
Athas
This looks like W3C capitulating:

> WHATWG maintains the HTML and DOM Living Standards

Which is understandable, since all of the main implementers of HTML are active
in WHATWG, not so much W3C.

What will be the concrete impact of this agreement?

~~~
domenicd
The biggest concrete impact, in my opinion, will be the removal of confusion
in the web developer community around where things are specified. Currently
W3C forks
([https://wiki.whatwg.org/wiki/Fork_tracking](https://wiki.whatwg.org/wiki/Fork_tracking))
are often linked to as authoritative, or misleading show up in Google search
results higher than the document they are forked from.

Per the Memorandum of Understanding at
[https://www.w3.org/2019/04/WHATWG-W3C-MOU.html#transition](https://www.w3.org/2019/04/WHATWG-W3C-MOU.html#transition),
after the W3C first marks a WHATWG Review Draft as a W3C Recommendation, all
the forks will be marked as "Superceded" with redirects to the WHATWG
originals.

------
jl6
Sounds like a recognition of WHATWG as the master, with W3C becoming more of a
publishing / vetting organization for snapshots of the standard?

~~~
tannhaeuser
I guess it's more a recognition of the limited resources of both W3C and
WHATWG, of the fact that there's a need for a "real" fixed-in-time and
versioned document describing HTML rather than a collaboration workspace
(WHATWG's "living standard") and W3C's choice to not die on the particular
hill of redacting WHATWG texts. Though practically speaking, W3C HTML 5.2 (the
last completed recommendation) was sponsored by The Paciello Group and MS
before that, and with MS' withdrawal from browser development they also gave
up redacting W3C HTML to fit IE's features set. I would love to be corrected
by an insider, but that's what I could make up from publically available info.

~~~
gsnedders
As far as I'm aware, MS continued to be involved with the W3C HTML much longer
than other browsers due to the W3C patent policy, which the WHATWG only had
any equivalent of as of December 2017.

Note also the W3C specs weren't really redacted versions of the WHATWG spec,
especially in later years: they were pretty much complete forks and moving
changes between them non-trivial.

------
xg15
Out of couriosity, does the WHATWG have any commitment to keep the "review
drafts" meaningful (e.g., by orienting the things that are actually supported
by browsers along them)?

Will it mean anything if one of them becomes a W3C Recommendation?

If the W3C sends a draft back with requests for corrections, will anyone from
WHATWG actually be motivated to make those corrections?

Or is this more of a "pick any commit you like and we can declare it the
'review draft' if that makes you happy" kind of thing?

Also, by this agreement, does the W3C have any avenues to influence HTML/DOM
design work that exceed those of an average volunteer an the WHATWG mailing
list?

------
firecall
Is WHATWG pronounceable?

~~~
louniks
I instinctively read it as "what-wee-gee"

~~~
hober
That is how a lot of us say it.

------
DhanushDivara
Good

------
sonnyblarney
The only thing that matters is what Chrome and iOS Safari decide to do. Sadly.

------
jsgyx
So W3C is signing to confirm their irrelevance?

~~~
klez
FWIW, w3c publishes and standardize a lot more than just HTML and DOM. So
calling it irrelevant seems a bit of a stretch.

~~~
geezerjay
I would also add that having third-parties propose specifications to
standardization bodies is a widely established practice. In fact, standards
are supposes to reflect industry practices and are a way to establish common
ground.

------
chronicler
Impressive

