
HTML 5.1 is a W3C Recommendation - okket
https://www.w3.org/blog/news/archives/5932
======
bryanlarsen
This is a completely irrelevant document. Browser makers follow standards
written by the WHATWG (Web Hypertext Application Technology Working Group),
not the W3C.

I'm horribly oversimplifying, but to see the full ugliness, just google
'whatwg w3c'

~~~
roblabla
Any specific article explaining what the difference between the two are ? My
google being in french, I don't get much results...

~~~
positivecomment
You already got many relevant answers but just in case you need it again,
[https://www.google.com/ncr](https://www.google.com/ncr) redirects to the
international version.

~~~
j_jochem
For me, this redirects to the German version (I'm in Germany on a device with
a German locale). I'd really love to have a way to tell Google to only show
English-language hits.

~~~
tauchunfall
Just append `&hl=en` to the URL. This should work.

I've set my browser to English as default and use `&hl=de` to tell Google to
mix some German hits into the query result.

------
WoodenChair
From section 1.5:

 _It must be admitted that many aspects of HTML appear at first glance to be
nonsensical and inconsistent.

HTML, its supporting DOM APIs, as well as many of its supporting technologies,
have been developed over a period of several decades by a wide array of people
with different priorities who, in many cases, did not know of each other’s
existence.

Features have thus arisen from many sources, and have not always been designed
in especially consistent ways. Furthermore, because of the unique
characteristics of the Web, implementation bugs have often become de-facto,
and now de-jure, standards, as content is often unintentionally written in
ways that rely on them before they can be fixed._

That kind of says it all when it comes to web standards!

~~~
Torgo
I think about this when I am using XMLHttpRequest in a web worker, and can't
actually get an XML document back because you don't have access to an xml
parser because there's no dom in web workers.

~~~
andrewmcwatters
Why would you use XMLHttpRequest in a web worker? Why would you not just
delegate working with the result to a web worker? The requests shouldn't
dispatch any faster.

~~~
Torgo
only point here is it was it was explicitly created for getting back an xml
document (by microsoft, outside of any standards body, no less) while 99% of
the time it's returning text or json, and in a web worker this XML tool
literally can't return an XML document at all.

~~~
EdSharkey
What you're saying is technically true, but only because the XML classes are
historically also (unfortunately) DOM classes. It's too bad that XML DOM can't
be made into Transferrables (losing their DOM'iness) in modern browsers and
thus usable in Web Workers. I suppose XML isn't that widely used in the
browser, so that would never happen.

Read the history of XHR and you'll get a fascinating look at how clever teams
can slip real innovation into products just by tickling the right business
folks' ears.

[http://www.alexhopmann.com/story-of-
xmlhttp/](http://www.alexhopmann.com/story-of-xmlhttp/)

> Which is the real explanation of where the name XMLHTTP comes from- the
> thing is mostly about HTTP and doesn’t have any specific tie to XML other
> than that was the easiest excuse for shipping it so I needed to cram XML
> into the name (plus- XML was the hot technology at the time and it seemed
> like some good marketing for the component).

------
wppick
> This specification should be read like all other specifications. First, it
> should be read cover-to-cover, multiple times. Then, it should be read
> backwards at least once. Then it should be read by picking random sections
> from the contents list and following all the cross-references.

Not sure if this is serious. [https://www.w3.org/TR/2016/REC-
html51-20161101/introduction....](https://www.w3.org/TR/2016/REC-
html51-20161101/introduction.html#how-to-read-this-specification)

~~~
Manishearth
It's mostly an import of the whatwg spec, which gets whimsical at times.

That is actually a pretty accurate representation of how reading entire specs
with intent to implement goes. I've done this twice with the xhr and file
specs :) Maybe not the reading backwards part.

------
Osiris
Is there a document somewhere that summaries the proposed changes from HTML 5
to 5.1?

~~~
piotrkubisa
I assume this document [1] may cover some changes.

[1]: [https://www.w3.org/TR/2016/REC-
html51-20161101/changes.html#...](https://www.w3.org/TR/2016/REC-
html51-20161101/changes.html#changes)

~~~
0x0
Interesting that "Having title, or writing email to a friend does not make an
img missing alt conformant." What if you write an email to an enemy?
[https://www.w3.org/TR/2016/REC-
html51-20161101/changes.html#...](https://www.w3.org/TR/2016/REC-
html51-20161101/changes.html#changes-to-existing-features)

~~~
rudolf0
>What if you write an email to an enemy?

Then I would probably prefer to use <blink> and <marquee>.

------
yuhong
I have been thinking of the "HTML5" buzzword and its problems for a while now.

~~~
moron4hire
Care to elaborate? What specifically is wrong with HTML5? And how is it
particularly worse than other offerings?

~~~
lucideer
I don't think this is what yuhong was referring to, but there's a lot wrong
with HTML5. Googling "w3c whatwg", as one commenter suggested, won't give you
any real insight into the mess, but it will hint at it.

TL;DR The above document is irrelevant and should be ignored. Popular
browsers' implementations define the HTML5 that most devs will want to target,
and those browser vendors are members of the competing WHATWG body. They will
largely ignore the W3C copy.

~~~
LukeShu
Those browser vendors are also members of W3C. That's not why W3C HTML5 is
irrelevant.

WHATWG HTML ( _formerly_ HTML5) is "rolling release"; the only version numbers
are the "Last Modified" date at the top of the document. Meanwhile, W3C HTML5
has defined releases that are thoroughly scrutinized, reviewed, and debated in
endless committee meetings.

One of these models is good for rapid-release and fast iteration. The other
isn't.

Finally, W3C members are large companies, not individuals (with a few notable
exceptions, like Aaron Swartz). WHATWG members are mostly individuals, many of
whom are ordinary web developers who don't work on browser implementations.
This difference is largely the raison d'être of WHATWG; it was the perception
of many that W3C standards were diverging from what actual web developers
wanted.

~~~
domenicd
Hi there, one of the WHATWG HTML editors here.

> Meanwhile, W3C HTML5 has defined releases that are thoroughly scrutinized,
> reviewed, and debated in endless committee meetings.

While this was true in the past, these days it's not really the case. They
mostly just copy and paste our work without scrutinizing it, and usually
without understanding it (as can be seen by the bugs they introduce during the
copy-and-paste process). There aren't really any technical deliberations or
committee meetings, and they don't follow a well-defined process; the most
recent fork (from which HTML 5.1 is based) was actually done without the
knowledge of the membership, and broke several aspects of W3C process while
doing so.

Why do they do this? Well, it seems to be largely an issue of institutional
face-saving. See e.g. [https://github.com/w3c/charter-
html/issues/14#issuecomment-1...](https://github.com/w3c/charter-
html/issues/14#issuecomment-108606731): "When the HTML WG co-chairs and Team
presented our proposed After HTML5 plan to the W3C Advisory Board earlier this
year, we received a clear message that it was not appropriate to delegate or
assign the maintenance of a W3C Recommendation outside the organization." In
other words, since they started copying and pasting back in the day with HTML
5.0, they can't stop now.

Meanwhile there's actually a lot of interesting deliberation between web
developers and browser vendors over in the WHATWG HTML Standard's bug tracker.
[https://github.com/whatwg/html/pulse](https://github.com/whatwg/html/pulse)
might give a reasonable overview. Compare to
[https://github.com/w3c/html/pulse](https://github.com/w3c/html/pulse).

Some relevant corroborating links:

\- [https://annevankesteren.nl/2016/01/film-
at-11](https://annevankesteren.nl/2016/01/film-at-11) when this all started

\-
[https://wiki.whatwg.org/wiki/Fork_tracking](https://wiki.whatwg.org/wiki/Fork_tracking)
monitoring the ongoing copy-and-paste-induced confusion

\-
[https://github.com/w3c/html/issues/364](https://github.com/w3c/html/issues/364)
wherein they monitor our tree for things to copy and paste over

\-
[https://github.com/w3c/html/commit/19fcaf241f4417b2078bc26bf...](https://github.com/w3c/html/commit/19fcaf241f4417b2078bc26bf957b196e1d76154)
example commit of them copying and pasting our work en masse (Spot the bugs
introduced! It's a fun game!)

~~~
kuschku
So, when will the WHATWG finally fix the HTML standards?

Get rid of all the backwards compatibility shit, and actually create strict,
and simple standards, with no unexpected behaviour, that only parse valid
documents, and where anyone can write an implementation?

Because that’s the definition of a standard.

That’s what a standard is supposed to be.

Standards, from paper standards to screws to fucking cucumber regulations are
supposed to be more strict than what came before them, so anyone can easily
accept only one type, and know it will work.

The WHATWG "standards" don’t fulfil the definition of standard in the least.

They are a strict superset of everything all implementers accept, making it a
larger and more complicated mess with every single iteration.

So when will the WHATWG, as you say it’s now the legitimate standards body, do
what it, as standards body is supposed to do, and deprecate currently used
behaviour to replace it with stricter, simpler, standard behaviour?

Yes, that will break the web, but yes, it will also improve it.

~~~
yuhong
Because it would not be useful to any real web browsers.

~~~
kuschku
That’s not any justification – you standardize things so other people can
easier work with them, create competing browsers, libraries, etc, and so more
innovation happens.

If you just document what already exists for the benefit of existing
implementors, great, you just got Microsoft Office Open XML.

That, and nothing more, is everything that can result from such a mindset.

