Hacker News Reader

Comment by Sharlin | Hacker News Reader

That's a big part of what HTML 5 is about, to codify existing practice when it was realized that trying to push strict standards was fighting against windmills. Nobody would ever push their web pages to the browser as application/xhtml because the user getting a validation error instead of a working page due to any slight infraction would have been catastrophically poor UX. Thus, even "XHTML" pages were sent as text/html and parsed by browsers as tag soup - pretty much defeating the purpose of XHTML.

Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]:

"Be conservative in what you send, be liberal in what you accept"

[1] https://en.wikipedia.org/wiki/Robustness_principle

View on HN

But this style guide wants you to be liberal in what you send.

Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.

Would it allow some performance optimizations on browser if it could assume the content is valid xhtml and simply barf if it is not, instead of trying to make sense of it?

Not really. Ultimately, once you get beyond the HTML parser you're just working on a DOM and other data structures derived from it. And unless you made the DOM much stricter, you could always end up with an invalid (i.e., doesn't match the schema) tree through use of scripting, so you still need to handle it.

It probably would make the parser simpler, however, which may well be faster. And xhtml is closer to the dynamic dom in semantics than html, by virtue of not having self-closing issues or nestability issues (i.e., you express nesting a button in a button with the dom and xhtml, but not html).

It wouldn't really make the parser much simpler. Your state machine goes to having a branch for a character c leading to a fatal error instead of having a branch for a character c leading to something getting added to the DOM. Honestly, the biggest gain I'd expect perf wise is better cache locality for the parser.

(Also, I'll point out that HTML allows the parser to abort at any parse error it defines, the first time it hits that parse error. So you can implement a relatively strict HTML parser that rejects content and have it comply with the spec.)

HTML also defines extremely flexible error recovery that is de-facto required. There's no way a browser's getting away without it when the competition allows such documents, and there's so much legacy content around.

I wouldn't expect huge perf increases, but there are a few minor non-local effects such as self-closing tags that imply more branches than strictly necessary. It's not going to add up to much of anything, that's for sure. A simpler spec might, however, leave more complexity-budget for clever optimizations, but that's pretty speculative. The kind of thing I'm thinking about here is that when the language is fairly restrictive, you can consider using SIMD operations to match content cleverly; e.g. you might find the closing quote of an attribute four-chars at a time. Those kind of tricks require interplay decoding and parsing and are typically way to complicated in all but the simplest of cases.

In any case, this is drifting off topic: perf is not a primary reason to aim for simplicity, it's just a possible windfall.

People have definitely done work on using SIMD for HTML parsing, FWIW. There's plenty of places where you can easily do it, especially in what tends to be the most expensive tokeniser states.

Why didn't they decide to keep the strictness, but only in dev mode? Lets say after you checked some checkbox in browser settings or if you had dev tools opened.

"keep the strictness" from what, though? Presto-Opera reported parse errors in the dev tools, for example (parse errors have a clear, unambiguous definition even in the current HTML spec).

DTD validation? As far as I'm aware, it would only be keeping it at a spec level—no implementation aside from validators ever implemented it. There's nothing stopping a browser from noting any validation error, though (and note they wouldn't just happen at parse time—they could happen following any DOM modification).

Reply on news.ycombinator.com