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.
> 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.
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.
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.
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.
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?
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.
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.
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.)"
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.
...really?