3 ms·

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 putsc

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?

DanHulton 17y ago
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.
- samps 17y ago
  Good point, but I'd bet that not displaying a page at all will decrease conversions even further.
- rimantas 17y ago
  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.
- ZeroGravitas 17y ago
  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/ http://hsivonen.iki.fi/doctype/
seldo 17y ago
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.
- electronslave 17y ago
  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?

DanHulton 17y ago

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.

samps 17y ago
Good point, but I'd bet that not displaying a page at all will decrease conversions even further.
rimantas 17y ago
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.
ZeroGravitas 17y ago
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/ http://hsivonen.iki.fi/doctype/

seldo 17y ago

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.

electronslave 17y ago
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?