What does HTML5 mean for us?(diveintohtml5.org)
diveintohtml5.org
What does HTML5 mean for us?
http://diveintohtml5.org/semantics.html
37 comments
Agree - the illustrations (all public domain, apparently) and typography really help with that as well. Made me laugh out loud in a few places as well.
This is by far the best introduction to HTML5 that I've seen. I freely admit to being something of a sceptic about the spec — and I still seriously question parts of it — but this introduction highlights the most important aspect; it adds more semantics to a HTML document. I’m a big fan of that.
As someone making his money from failed fashions of technology history (i.e. data integration), I welcome the idea of inventing yet another pointy bracketed syntax for HTML 5 in the name of beauty.
We came dangerously close to removing huge amounts of nasty incompatibilities and integration issues by converging on XML as a syntactical standard for document formats. Now that HTML breaks away from this trend I look forward to vendors and in-house developers inventing all kinds of crazy new money making (for me) syntaxes!
Beauty peddlers I love you!
We came dangerously close to removing huge amounts of nasty incompatibilities and integration issues by converging on XML as a syntactical standard for document formats. Now that HTML breaks away from this trend I look forward to vendors and in-house developers inventing all kinds of crazy new money making (for me) syntaxes!
Beauty peddlers I love you!
What new syntax was invented here?
I can't tell if you're sarcastically lambasting HTML 5 or if you're mocking its detractors. Could you elaborate?
I can't tell if you're sarcastically lambasting HTML 5 or if you're mocking its detractors. Could you elaborate?
I'm lambasting the fact that HTML 5 is neither XML nor SGML but a new pointy bracketed surface syntax for the DOM:
http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html
I do like other features in HTML 5 so I'm not lambasting it in general. But it's the W3C that steers the standardization of both HTML and XML. If XML is considered too complex or unsuitable for marking up web pages why don't they reform XML instead of inventing yet another very similar syntax?
In my opinion the W3C has lost a lot of credibility with this move.
I do like other features in HTML 5 so I'm not lambasting it in general. But it's the W3C that steers the standardization of both HTML and XML. If XML is considered too complex or unsuitable for marking up web pages why don't they reform XML instead of inventing yet another very similar syntax?
In my opinion the W3C has lost a lot of credibility with this move.
I agree, it frustrates me too that the W3C has moved away from XML for the HTML specification. I feel like HTML5 takes 1 step forward but 2 steps back. There are some great semantic tags and I love the multimedia support, but the move away from XML just seems like we are going the wrong direction.
I don't think that the requirements of being a valid XML document are all that onerous for HTML.
I don't think that the requirements of being a valid XML document are all that onerous for HTML.
It's my understanding that the "HTML" part of HTML 5 is neither new nor invented; in fact, it's a specification of how browsers already parse HTML documents, with the aim of normalizing that behavior among willing vendors. Creating a realistic specification of how to handle most existing HTML on the web seems to me like a huge step towards better integration and compatibility.
Isn't this the exact opposite of creating a new syntax? You could level your same arguments against XML when it was introduced to browsers through XHTML.
Isn't this the exact opposite of creating a new syntax? You could level your same arguments against XML when it was introduced to browsers through XHTML.
Getting vendors to be more compatible is a laudable goal but I don't see how it could possibly be the opposite of creating a new syntax when that's clearly part of what they did.
XML was a grand vision to unify document formats and it sparked an entire trend of opening up all sorts of data. It wasn't just some small incompatible change to HTML syntax.
I don't see what it buys us to go back to an HTML specific syntax, but it could have very broad ramifications. XML may have been overused, but if the W3C cannot make it work for marking up web pages then XML is dead.
Removing XML from the data integration world and going back to building parsers for every shitty DSL idea that in-house developers come up with is going to cost the world economy dearly.
Some of that money is going to end up on my bank account, so I'm seriously ambivalent about lambasting this historical mistake.
XML was a grand vision to unify document formats and it sparked an entire trend of opening up all sorts of data. It wasn't just some small incompatible change to HTML syntax.
I don't see what it buys us to go back to an HTML specific syntax, but it could have very broad ramifications. XML may have been overused, but if the W3C cannot make it work for marking up web pages then XML is dead.
Removing XML from the data integration world and going back to building parsers for every shitty DSL idea that in-house developers come up with is going to cost the world economy dearly.
Some of that money is going to end up on my bank account, so I'm seriously ambivalent about lambasting this historical mistake.
I still don't understand why the doctype for html5 is:
<!DOCTYPE html>
<!DOCTYPE html5>There's two questions here:
1. Does it work (i.e. trigger standards mode) in all browsers
2. Does it specifically identify content as HTML5 (as opposed to 6) i.e. versioning
For 1, html5 puts versions of Firefox into quirks mode so it's no go. For 2, versioning HTML5, I'm going to take a handy shortcut and assume that if Microsoft supports something it's probably bad for the internet.
There's a comment from Hixie here that touches on both issues: http://annevankesteren.nl/2005/07/html5-doctype#comment-4391
1. Does it work (i.e. trigger standards mode) in all browsers
2. Does it specifically identify content as HTML5 (as opposed to 6) i.e. versioning
For 1, html5 puts versions of Firefox into quirks mode so it's no go. For 2, versioning HTML5, I'm going to take a handy shortcut and assume that if Microsoft supports something it's probably bad for the internet.
There's a comment from Hixie here that touches on both issues: http://annevankesteren.nl/2005/07/html5-doctype#comment-4391
The HTML5 doctype is the shortest doctype that triggers standards mode in all browsers.
It sounds like HTML5 is a backwards-compatible superset that includes HTML4 and XHTML1. Does that mean the rendering engine browsers use for standards mode is effectively an HTML5 rendering engine that also works for valid HTML4 and valid XHTML1, since they're subsets of HTML5? Or am I way off-base?
This a very good intro. Readable, fun and concise.
Something that caught my eye though: links now have a rel="noreferrer" option. This sounds like a pretty bad idea. It's not supported by any browsers yet, but if it worked it would blank out the referrer field on HTTP requests you make after clicking on a link.
There are only two use cases I can imagine:
1. You have some super-secret URL's that are not protected by any other authentication method, you want to avoid others sniffing them out from the referrer field. Verdict: your security is broken and cannot be saved by any standards body.
2. You're hosting a site with malicious XSS-loaded links and want to hide your tracks. OR you are executing CSRF attacks and want to hide your tracks. Verdict: this rel value is perfect for you.
Something that caught my eye though: links now have a rel="noreferrer" option. This sounds like a pretty bad idea. It's not supported by any browsers yet, but if it worked it would blank out the referrer field on HTTP requests you make after clicking on a link.
There are only two use cases I can imagine:
1. You have some super-secret URL's that are not protected by any other authentication method, you want to avoid others sniffing them out from the referrer field. Verdict: your security is broken and cannot be saved by any standards body.
2. You're hosting a site with malicious XSS-loaded links and want to hide your tracks. OR you are executing CSRF attacks and want to hide your tracks. Verdict: this rel value is perfect for you.
A lot of forums and blogs would prefer that some sites not know that they are talking about them. I've come across it several times and doesn't seem like such a bad thing.
From the vagueness of your statement, it sounds like these forums fall into the second category of being up to no good in the first place.
aka: "if you aren't doing anything wrong, what've you got to hide"
Not necessarily "wrong". For example, you could have an internal company wiki which would include links to competitor's site.
Unfortunately, public protocols like HTTP need to manage communication between parties that do not trust each other. This is not a legal matter, so there is no necessity to establish motives or plausibility. A secure protocol is charged with limiting the damage any malicious party using the protocol might do. This addition to the spec is contrary to that fact.
Allowing a site to scrub its outgoing connections assumes a certain level of trust, which on the web ought not exist by default.
Allowing a site to scrub its outgoing connections assumes a certain level of trust, which on the web ought not exist by default.
Very good introductory overview of HTML 5, including workarounds for IE.
I agree. Something I might throw in for the reader is an article like: http://immike.net/blog/2008/02/06/xhtml-2-vs-html-5/
(I have no idea on how credible that is; however, it seems to give some interesting information on the matter)
so he or she understands more about the different "html"s so to speak. (But then again, this is ycombinator....)
so he or she understands more about the different "html"s so to speak. (But then again, this is ycombinator....)
Forget XHTML 2: http://www.w3.org/News/2009#item119
I keep seeing people saying "I'll support it when IE10 does" or similar.
Is there a single good reason why anyone producing a website in HTML4 or XHTML couldn't move to HTML5 today?
If you avoid the new stuff (which you couldn't use with those formats anyway) then as far as I can tell you'd actually be using something better supported by IE6,7&8 than HTML4 and especially XHTML since a lot of HTML5 involved reverse-engineering and minutely specifying the real-word behaviors of those browsers so that other, more active, browser developers could more accurately copy and interoperate.
Maybe someone needs to have a validator target called "HTML5, the IE-supported subset".
Is there a single good reason why anyone producing a website in HTML4 or XHTML couldn't move to HTML5 today?
If you avoid the new stuff (which you couldn't use with those formats anyway) then as far as I can tell you'd actually be using something better supported by IE6,7&8 than HTML4 and especially XHTML since a lot of HTML5 involved reverse-engineering and minutely specifying the real-word behaviors of those browsers so that other, more active, browser developers could more accurately copy and interoperate.
Maybe someone needs to have a validator target called "HTML5, the IE-supported subset".
I think this subset of people you refer to doesn't actually exist in the real world.
I doubt the people who are saying "I'll support it when IE10 does" are referring to not closing their img tags. They're referring to all the actually interesting features of HTML5, the ones that actually have a potential of changing the web: canvas, video tag, etc etc. Incidentally, all the features that IE probably won't support for a very long time.
As stated before, most of these semantic changes were incorporated specifically because they already work, so chances are people are already using them. I doubt there's someone who is simultaneously adamant about using XHTML 1.0 style markup AND a big fan of IE backwards compatibility.
The truth of the matter is that the part of the spec outlined in this article reads more like a best practices sheet for "practical" HTML4 than a spec for HTML5. By that I mean, most of it already works, and it is not likely to significantly change the web.
I doubt the people who are saying "I'll support it when IE10 does" are referring to not closing their img tags. They're referring to all the actually interesting features of HTML5, the ones that actually have a potential of changing the web: canvas, video tag, etc etc. Incidentally, all the features that IE probably won't support for a very long time.
As stated before, most of these semantic changes were incorporated specifically because they already work, so chances are people are already using them. I doubt there's someone who is simultaneously adamant about using XHTML 1.0 style markup AND a big fan of IE backwards compatibility.
The truth of the matter is that the part of the spec outlined in this article reads more like a best practices sheet for "practical" HTML4 than a spec for HTML5. By that I mean, most of it already works, and it is not likely to significantly change the web.
I got about halfway through this before I decided that I just wanted to see the final result. Perusing the source of the final link, I saw a bunch of unclosed tags - is this something that he mentions is allowed in HTML5? I don't think I could bring myself to place unclosed <p> or <td> elements in my page.
As a side note I submitted this post while not logged in, was redirected to the login page, came back to my post and instead of showing "<p>" the input field had rendered a newline. Vulnerability of some sort?
As a side note I submitted this post while not logged in, was redirected to the login page, came back to my post and instead of showing "<p>" the input field had rendered a newline. Vulnerability of some sort?
Unclosed tags have been valid in all versions of HTML except for XHTML1 and XHTML2. It's the SGML ancestry showing through.
I've touched up the example source a bit to be closer (in style) to the original. I may want to talk about "which tags implicitly close others" but that's not the subject of this chapter, and having unclosed tags in the example source is distracting from the main point.
"which tags implicitly close others" - stuff like this makes me cry. What is the benefit of a format that allows such complicated rules for parsing the document? Flexibility like this on the input is just increasing complexity of the rendering engines and ambiguity of the resulting output.
Fantastic. Good to see all the xhtml verbose cruft going.
Is anyone else seeing differences between the HTML5 and HTML4 example pages, on the latest Firefox and Chrome? The article dates are in different places and the footer is displayed in a different place.
This should now be fixed. Sorry for the confusion.
Also looks like that for me in Safari. Very odd.
One nitpick on an otherwise fabulous article - Mark links to the HTML5 enabling script in order to add IE support but I don't see any reason not to use Modernizr instead, since you'll get CSS3 support as well.
http://www.modernizr.com/
http://www.modernizr.com/
"The net result is that Internet Explorer will execute this script, but other browsers will ignore the script altogether. This makes your page load faster in browsers that don’t need this hack."
Though he means "faster than IE", it sounds almost as if that script will speed up the page.
Though he means "faster than IE", it sounds almost as if that script will speed up the page.
If I were designing html5 I would have removed a bunch of redundant tags instead of adding new ones.
Some tags were removed from html 5:
http://www.w3.org/TR/html5-diff/#absent-elements
http://www.w3.org/TR/html5-diff/#absent-elements
Hey, nice to see another Ido on the site.
And, of course, the content is awesome. Thanks for posting this, SlyShy!