W3C declares HTML5 standard complete | Hacker News Reader

W3C declares HTML5 standard complete

techcrunch.com

232 pointsdarklrd79 comments

http://www.cnet.com/au/news/html5-is-done-but-two-groups-sti...

""The real problem is of course that the W3C is still copying our work even after we asked them to stop doing that," [Anne] van Kesteren said. It's legal, but "oftentimes it comes pretty close [to] or is actual plagiarism."

It's one of many instances of copying, Hickson said. "For reasons that defy my understanding, the W3C staff refuse to treat the WHATWG as a peer organization" that relies on WHATWG's work, he said. Instead, it creates its own copies of some standards. "They'll eventually say they have a 'final' version, and then they'll stop fixing bugs. It's very sad."

It's amusing to me to watch the WHATWG people complain about the W3C having the temerity to put out revisions to their own specification, and then complaining about how the W3C is copying their work. Would they rather W3C put out an ENTIRELY DIFFERENT HTML specification from theirs? Would that be better for anyone at all?

Yes, actually. We'd encourage the HTML working group to do original work. Many W3C working groups do that, e.g. the webapps working group worked on web components and various other specs, and it helps the web platform.

So they should reinvent the wheel when there are good solutions out there?

Isn't the whole point of standards to stop that sort of thing happening?

I get that you may feel that someone is just appropriating your work rather than doing their own but if your aim is to build a standard then reusing things is probably going to be part of doing that.

No, they shouldn't reinvent the wheel at all. They should reference the WHATWG specs, like they do IETF and Ecma specs.

There's no "reusing" going on here, just plain old copying-and-pasting.

What makes this really funny for me is that WHATWG fully appropriated the spec that W3C wrote for HTML and the DOM, as well as the names HTML and DOM.

The specs were written from scratch, because the W3C holds the copyright on them (the old specs are also of relatively little use). The spec now called HTML5 was officially called Web Applications 1.0 till after the W3C HTML WG was (re-)chartered.

I dunno, perhaps if the W3C and WHATWG produced radically different specifications, one of them would be explicitly rejected by everyone and thus die a clean death. That might be better than having two very similar, equally authoritative, but subtly different specifications, one of which is sort of but not quite a snapshot of the other.

Equally authoritative? I had no idea WHATWG was drafting specifications, let alone considered authoritative.

Many of the foundational specifications of the web are authored and maintained by the WHATWG these days: https://spec.whatwg.org/

- DOM, HTML: obvious

- URL, Encoding, Fetch: foundational building blocks

- XHR, Fullscreen, Notifications: important features

There are also other up-and-coming specs like Books, Figures, Streams, or Loader (the latter two not listed).

The spec site doesn't load for me on Firefox with RC4 disabled:

  Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)

Well, perhaps you haven't kept up then. It's a while since W3C was considered either authoritative or relevant for the modern web.

HTML5 is most all WHATWG.

The other huge accomplishment of HTML5 is completely standardizing many fundamental parts of the web that previously were a mess of browser incompatibilities. 6 years ago, if you wanted to parse HTML, you might reach for BeautifulSoup, or libxml, or Hpricot, or Nokogiri...and they would all be subtly different in the parse tree they produced. And they couldn't do any better, because if you viewed the page in IE, or Firefox, or Chrome, or Safari, you might get a different parse tree.

Now, IE9+, Firefox, Chrome, and Safari are all basically guaranteed to look at the same page in the same way, and the "toolsmith" parsers like Gumbo or html5lib are all rapidly converging on the standard. So it's finally possible to see a page the way a browser sees it.

> Now, IE9+, Firefox, Chrome, and Safari are all basically guaranteed to look at the same page in the same way, and the "toolsmith" parsers like Gumbo or html5lib are all rapidly converging on the standard. So it's finally possible to see a page the way a browser sees it.

The web projects I have to take part on, are a distant reality from that description.

Are you talking about inconsistent HTML parsing or inconsistent CSS rendering? The latter is much more of a pita than the former.

Right, this. There's still a lot of experimental features that are implemented differently or not at all in one or more of the big three. But I can't remember the last time that I've had different browsers produce fundamentally different DOM trees from the same document, even when I'm using invalid attributes or made-up tags (coughangularcough).

If you stick to the basics of CSS that have been around for a decade or so, both of them are basically solved problems. Browsers are remarkably uniform in how they handle the stuff that was a PITA in 2008.

The problem is that expectations adjust too, and now we want all these new HTML5 features that were just pioneered in a single browser a couple years ago. Those have a lot of cross-browser issues.

In many environments, expectations don't have to adjust. With corporate clients, expectations were never reasonable in the first place, and many common requirements that have been around for decades still aren't reasonable.

Clients often demand idiocy like "pixel perfection," specific fonts, custom scaling behavior for size (including application-controlled zooming), and other things that simply aren't part of the paradigm for accessing websites through web browsers.

Between that and the fact that going "beyond the basics of CSS" is a pretty common thing, browser interfailure is still a real problem. It's not as bad as it used to be, but the problem is still there, and many of us are still dealing with it regularly.

Is there any particular reason? Requiring support for older or legacy browsers?

I just recently wrapped up a project utilizing customized Twitter Bootstrap / CSS3 / HTML5 and I was pleasantly surprised at how smooth everything went between IE/Chrome/Safari/FF. This is the first time, in a long time, that everything just "worked."

All projects tend to require IE 8+, specific versions of FF, Safari and Chrome.

Oh and the fun that is working with native iOS, Android and WP browsers.

Then put on top, whatever web framework might be required by the customer.

The fun starts when the UI isn't working pixel perfect to those Photoshop mockups or the cool HTML 5 effect that can only be partially implemented in all browser versions mentioned in a "Request For Proposal".

I always try to explain that pixel perfect just isn't feasible when we're going across platforms browsers and devices sizes / types.

If they would like to create 20+ different mockups and supply them to me I'll gladly do it for an exorbitant sum money, but otherwise they need to realize that the relative fluid nature of the web and it's many form factors is going to preclude them from getting that pixel perfect design.

Then all of that flies out the window because we have that one asshole manager who promises the world and ensures it will be delivered yesterday :)

Bootstrap deals with a lot of cross browser issues.

Yes and no, it depends, If you use the entire suite of bootstrap, yes. We did not, we used it for the grid system (getting those nice big perfectly sized columns). Everything else was hand written CSS and HTML.

Thanks for the mention of the Gumbo parser. I didn't know about that project.

From what I found, it seems like this is the most mature NodeJS module for using Gumbo:

https://github.com/karlwestin/node-gumbo-parser

The term "WHATWG" seems to be conspicuously absent from this article. I wonder where they factor into this announcement.

I think they already moved to living standard.

Indeed, the W3C's work on HTML5 is irrelevant. It exists only for the purpose of giving the W3C-qua-organization the appearance of being involved in the further development of HTML.

They have different purposes. In practical terms, the "HTML5 standard" is really defined by whatever the most popular browsers implement - we saw this in vivid detail when IE6 was the most popular browser and Microsoft made a mockery of the standard. The WHATWG standard exists to track the evolving consensus, so that the major browsers don't diverge too much and we don't go back to the web c. 2005. The W3C spec is so that other interested parties, ones who need to have a finalized doc to shoot for, have something to shoot for that everybody has agreed upon.

I think that's disingenuous — even as someone who has been around the WHATWG for longer than the W3C has been working on HTML5. One clear reason that publication as a REC is important because it implies a royalty-free patent grant between all members of the WG.

It's interesting that WHATWG is trying to get the patent commitments by being a W3C Community Group:

https://wiki.whatwg.org/wiki/FAQ#What.27s_the_patent_story_f...

I haven't been following the situation super-closely, but I understand that the threat of W3C not ratifying the HTML5 spec as it is (or was) has curtailed the behaviour of certain individuals on a number of occasions during the HTML5 process. If so then the W3C's involvement with HTML5 has not been at all inconsequential, even if you view the formal announcement today as unimportant.

The living standard was never abandoned in the first place, and W3C's HTML5 is basically a fork of the WHATWG living standard.

Which means no standard at all.

I'm grateful to W3C for continuing their standardization work.

This announcement makes me miss Mark Pilgrim. I wish he was still publishing his blog.

This CNet article seems to have a lot more detail than the Techcrunch one:

http://www.cnet.com/news/html5-is-done-but-two-groups-still-...

Cool, but It doesn't really matter what W3C says. In the end it is all about what the Oligarchy of popular browser implementers decide to implement.

> the Oligarchy of popular browser implementers

In the past, only Mozilla cared about what the W3C said, and they built Firefox on the idea that interoperability by following the standards is the way to go. Not that long after Apple initiated Safari, and led Google to their own browser initiative.

All this because Mozilla, the insignificant actor of the all IE time, decided to follow W3C.

You're not totally wrong telling that W3C doesn't mater that much, but browsers are what they are today because of W3C for a good part, and it still have a very important place in the browser game.

This is pretty much the opposite of how things went down.

If browsers followed the W3C, we'd be living in XML utopia (XHTML2, XForms, XLink, XEvents, etc.). In 2004 a group of implementers (specifically Mozilla, Opera, and Apple) proposed to the W3C to focus on web applications by evolving HTML and the DOM, but were flat-out turned down, and had to go off and form their own standards organization---the WHATWG. Today, that is where much of the foundational work of the web platform is still done: https://spec.whatwg.org/

And we could have goten something similar to XAML, instead of the HTML, CSS magic and JavaScript workarounds to replicate desktop behavious and UIs.

Do the names XHTML2, XForms, XLink, XEvents invoke an image of something like XAML to you?

We would have ended in some huge JAVA EE circa 2004 mess, with XML to spare and perhaps RDF and a couple ad-hoc languages thrown in for good measure.

Yes, because in the XHTML world, tags could loose any semantic meaning.

In HTML 5, one is abandoned to the CSS tricks and JavaScript hacks to make visual UI components of HTML tags.

Every time I get a consultant gig outside the web world, I rejoice.

Yet I've spend a big part of my career involved in web development.

Final standards document

http://www.w3.org/TR/2014/REC-html5-20141028/

The most important thing about HTML5 is <video>? What a weird statement.

Maybe they mean for end users? Most people aren't going to care if developers have an easier job with browser compatibility.

Making Flash obsolete is pretty important

Video doesn't kill the flash star.

I'm hoping Chrome will drop their built-in flash runtime, only thing it's used for is ads.

I imagine you don't play browser games.

I imagine not that many people would care if they turned into HTML5 Canvas games.

Nothing kills a laptop battery or spins the fans like BS flash browser games.

> I imagine not that many people would care if they turned into HTML5 Canvas games.

Presumably, the developers still making Flash games would, since HTML5 Canvas has wider reach than Flash, yet they still use Flash.

Actually WebGL achieves a higher fan rotation than Flash!

New browser games are rapidly moving away from flash to html5, unity, etc.

Maybe you should let the guys that write postmortems in GDC, Gamasutra and Making Games Magazine how HTML5 still cannot beat Flash know about it.

That gap is constantly closing. The sky is falling on Flash. Sure, if you legitimately have a project that won't work in HTML5, maybe Flash is a good choice. However, most of the time I see these statements used by Flash developers that don't want to learn javascript or admit their time is limited as Flash devs.

My thoughts exactly. Solving tag soup would be the most important thing in my opinion.

I'm hoping for a scene graph standard for HTML6 and a spec that allows multiple documents per window (which themselves could be nodes on a scene graph) instead of the one document per window.

HTML5 is a living standard, no? There isn't going to be an "HTML6".

The spec published by WHATWG is a living standard, and is just called "HTML". The expectation is that every so often the W3C will pick a revision of the WHATWG's HTML spec and stamp it with a version number.

> The expectation is that every so often the W3C will pick a revision of the WHATWG's HTML spec and stamp it with a version number.

W3C HTML5 is not just a snapshot of a particular revision of the WHATWG Living Standard. In a reasonable world, W3C HTML5 (etc.) would be a subset of the WHATWG Living Standard on the date the former was published, but I'm not sure that even that is strictly the case.

Note the SVN revision the REC is based on is almost a year old.

Well, this announcement seems to indicate that from W3C's point of view, it's not living anymore. They've finalized the standard, and are starting work on HTML 5.1. WHATWG apparently no longer numbers their standard. [1]

1) https://blog.whatwg.org/html-is-the-new-html5

Iframes sort-of do this already.

Does anyone know how is Doctype versioning going to work with W3Cs snapshoting of the living standard? Or are browsers just going to ignore W3C and stick to implementing WHATWGs spec?

I think even the W3C rejected DOCTYPE versioning, it is still just <!DOCTYPE html>.

No browser ever paid any attention to the version of the HTML specified. The only use for DOCTYPE—and the reason it remains in HTML5—is "doctype switching", i.e. different rendering modes are triggered in the browsers. You can use "html", "html5", "html6.2" or "foobarbaz" as your doctype, the effect will be the same—they will all trigger standards compliant mode.

>'You can use "html", "html5", "html6.2" or "foobarbaz" as your doctype, the effect will be the same—they will all trigger standards compliant mode.' //

You're wrong if your asserting that any doctype produces the same results globally but it probably doesn't matter unless you're targeting legacy UA.

See e.g. "Appendix: Handling of Some Doctypes in text/html" at https://hsivonen.fi/doctype/ or Eric Meyer's http://archive.oreilly.com/pub/a/network/2000/04/14/doctype/... (for MacIE5 ... like I said it probably won't matter!).

Speaking of IE/Mac, that's the reason why the HTML DOCTYPE now is `<!doctype html>`. If it hadn't been for IE/Mac, it'd be `<!doctype>`.

Maybe but if you use real DOCTYPE such as <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> then you will see huge difference in rendering.

I have vague memories of Frames not working under the HTML4 Strict doctype

> Or are browsers just going to ignore W3C and stick to implementing WHATWGs spec?

Well, do you think browser vendors will just stop implementing new features because the W3C decides that HTML 5 finished?

i guess it's finally time to upgrade that .vimrc to include syntax highlighting for the new tags... canvas, video, audio, nav, section, etc..

i know it was just a joke, but for vim users working with html i recommend the html5 plugin[0].

[0] https://github.com/othree/html5.vim

I was hoping they would add file api support for downloading to non sand boxed environment with mandatory user interaction prompts. The api would prompt for the file download location (via file dialog) but after that, how the file is filled up is up to the web client (and happens in the background). This would allow for parallel download workers via the existing get range option.

http://html5doctor.com/the-ride-to-5/ is an interesting overview of perspectives of various people who've been around HTML5 for years about its publication as a REC.

Kind of ironic that the embedded Vimeo video in the article is Flash.

Wonder when the IE standard support documents listing all the "deviations" from HTML5 will happen.

latest versions of IE are pretty good regarding standards.

I wonder when they will get as good as the rest of the browsers that are out. I still find more bugs in IE11 than any other current browser.

I see more Safari bugs/issues - it's surprising how poor Safari is in some areas.

Reply on news.ycombinator.com