Get Ready for HTML 5 | Hacker News Reader

Get Ready for HTML 5

alistapart.com

41 pointswhalesalad19 comments

"If you are like most designers, you probably don’t write all your markup by hand."

...really?

Years ago, I called BS on that too, but the ALA convention of "by hand" means "we're not writing flat files full of markup anymore." And we aren't. We use templates now.

The implication in the article was that people were using pre-written code that didn't include 'HTML 5 features', so now they'll have to write the code 'by hand' instead. So at least in this case, the usage is different from what you're calling 'ALA convention'.

Er, I'm seeing that phrase the way I described it, and as it was described to me.

"If you are like most designers, you probably don’t write all your markup by hand. But until the tools you use catch up to the new elements in (X)HTML 5, you will be doing some markup by hand while you learn."

Mind you, that speaks to templates like WordPress layouts, Django plugins, Rails gems that generate their own markup, Drupal modules. The list goes on.

What did you have in mind?

You said:

> the ALA convention of "by hand" means "we're not writing flat files full of markup anymore." And we aren't. We use templates now.

This implies that "by hand" means writing templates by hand instead of writing flat files by hand. I'm merely pointing out that the article uses the term to mean something like "most designers aren't writing much html at all", instead using "tools", which "haven't caught up". That's quite different from writing templates.

To me, he's talking about wysiwyg tools like Dreamweaver.

Okay, that's fine. And yes, he might be. My take on it was the following narrative:

"hey, ALA reader #21223, there's no Drupal modules that use HTML5 features."

(hand on cheek) "oh crap, I overcommitted!"

"you certainly did. that'll teach you to read oreilly's blog. wait until that module gets written, or write your own."

(reinserting finger into nose) "phew, now I can return to complacency."

"I suggest that you write your markup in XHTML 5..."

Is this really as settled as the author makes it sound? I can't see any particular advantages to living in XMLland.

He even mentions the biggest reason not to do so, which is that any typos in XHTML (when served as XML) will result in the yellow-and-red screen of death in Firefox.

The failure case for XML on even a single typo being the total destruction of your web app is unacceptable. This is why at Yahoo, we're pretty firm about using plain HTML, from yahoo.com on down.

Being a purist about markup is great and all, but the robustness of browsers when given accidentally broken markup is one of the great strengths of the web. Serving as XML makes your apps less stable.

a single typo [is] the total destruction of your web app

Really? I mean, I know why my company's pages don't validate. I'm more than ready to execute a putsch to take care of that problem.

So why doesn't Yahoo, in its vastness of being, have the ability to clear pages through (automatable, standardized and fairly simplistic) validation? Is it a 5-bytes-on-the-wire savings problem like at Google? Or just PEBCAK as is par for the course?

PEBKAC, actually.

Though it can be (sort of) argued that regular HTML files that don't validate are just as destructive to user experience as XHTML ones. If your file doesn't validate, the browser has to discard it's "pure" parsing mode and start again in quirks mode, which can really slow it down.

I don't have the figures to hand, but there have been some neat studies done that show that changing a website so that it validates appreciably increased conversions.

Good point, but I'd bet that not displaying a page at all will decrease conversions even further.

Actually there are two different things—the parser and the rendering mode. The choice of the former depends solely on the MIME type—no matter that docypte you use if your page is served with text/html MIME it will be parsed by HTML parser. And keep in mind, that every slash in "/>" is treated as invalid attribute by this parser, so serving your XHTML page as text/html may be not the best idea. BTW, do "view source" of such page in Firefox 3 and you will see all slashes in red.

And if you did happen to server XHTML with proper MIME there could well be the case that your page would take longer to load on Gecko <1.9 — it did not support incremental rendering of XHTML so your document had to be fully loaded before it could be rendered.

HTML engine choses rendering mode (standards, almost standards, quirks) depending on DOCTYPE (for XHTML parser it is always standards mode). HTML engine must be always ready to recover from markup errors (and HTML5 does a good job describing what to do), XHTML parser can just die on the first error it encounters.

That's not true.

The browser doesn't validate the content and neither knows nor cares if it would. It does something called doctype sniffing to choose whether it goes into one of a few different modes based entirely on the declaration (or lack of the same) at the top of the document.

"However, it is important to realize that the Quirks mode vs. Standards mode is predominantly about CSS layout and parsing—not HTML parsing. Some people misleadingly refer to the Standards mode as “strict parsing mode”, which is misunderstood to imply that browsers enforced HTML syntax rules and that a browser could be used to assess the correctness of markup. This is not the case. The browsers do tag soup fix-ups even when the Standards mode layout is in effect. (In 2000 before Netscape 6 was released, Mozilla actually had parser modes that enforced HTML syntax rules. These modes were incompatible with existing Web content and were abandoned.)"

Quoted from (and far more details) here: http://hsivonen.iki.fi/doctype/

Any web company should have a policy of making its pages validate to the extent that is possible. And we do.

In the real world -- when you have to do Stupid Web Tricks to make things work in IE6, or you have advertisers who can insert random awful FONT tags -- a fully validating page is an impossible dream, especially when (for the front page, for instance) that page is different for every single user in scores of countries and dozens of languages.

So we get as close as is practical, and rely on the wonderful resilience of the web to take care of the 3% of edge cases.

FONT tags in advertiser injection, I understand. We do some mangling to avoid that, but you're right. It doesn't kill everything.

I'm wondering what kind of stupid web tricks you're talking about that go against XHTML validation, though. Care to share a horror story?

any typos in XHTML (when served as XML) will result in the yellow-and-red screen of death in Firefox.

Or, say, using && in your javascript. Yes, that does it. I have the 30 minutes of wasted time a week ago to prove it.

Here's the "solution", just so you can see how elegant it is. You have to escape it like this:

  <script type="text/javascript">
  /* <![CDATA[ */
  if (var1 && var2) blah blah;
  /* ]]> */
  </script>

Or just use AND I suppose, forgot if it's got some weird precedence difference or something.

He doesn't mention the actual biggest reason not to do so, which is that Internet Explorer doesn't support XHTML at all.

You'll only experience the yellow screen of death if you've already went to the trouble of serving the content as tag soup to IE and detecting Firefox to send it with a different mime type.

In short that whole section made me think this guy was an uninformed crank, still desperately clinging to the dead end of XHTML and spreading disinformation in order to justify things to himself.

In HTML5 that you can use any syntax you prefer. Whether you live in XMLland is defined solely by MIME type you use to serve your pages—if it is text/html then it is HTML serialization, if it is application/xhtml+xml only then capable browsers will switch to XHTML parsers.

Of course this is the same story as with XHTML1.0 only in HTML5 case XHTML5 syntax does not pretend to be something it is not.

The added benefit of HTML5 not being the child of SGML is that stupid controversy regarding "/>" which means completely different thing in SGML applications and XML is finaly resolved.

Reply on news.ycombinator.com