Hacker News Reader

Comment by bhaak | Hacker News Reader

It does not only make the machine overlord happy, it also helps the humans when they do make a mistake.

Humans throw some HTML-like stuff at the browser and the browser tries hard to make sense out of it. If the browser misinterprets, you have a hard time finding out what went wrong.

Whereas with XML and XHTML you get told immediately what's wrong and you don't have to hope that every browser implementation works the same way.

It's also a bit strange to argue about "easier to write manually" in this day and age of Markdown, HAML, etc.

View on HN

> If the browser misinterprets, you have a hard time finding out what went wrong.

This is what HTML validators are for.

Browsers should do their best to interpret the page authors intention and actually display a page. The developer doesn't always have 100% control over the page markup (think about user generated content, ads etc...)

Why can't the browser be the validator itself? You load the page and the browser tells you what's wrong with the code.

This would work as long as the browser was in a dev mode. Usability would suffer if normal users had to deal with errors in the pages that they visit.

That's a good point, but I wasn't necessarily thinking it should error out to render nothing at all.

What I would like is if somehow the browser could insert an error class name into the offending element so that in my CSS I could give it a set of rules to make it stand out after render.

Sorry, that's silly. Web pages break all the time.

If they would break because of invalid HTML, they would also already break during your tests.

If you use some HTML injection services like ads or analytics that make valid HTML invalid, then it's great that it breaks because it will show you immediately on your tests that these services suck.

What if you have no choice but to rely on those services? The person coding the site isn't always the decision maker.

Yes but you have an error in your reasoning.

If browsers would error out on invalid content then those services would either provide valid content or they would go bust.

And XML/XHTML is much easier to parse and for producing valid content than HTML because it is much more consistent and has less history package than HTML.

It is just that today, we still have tag-soup and error-tolerant parsers in the browsers and of course lots and lots HTML producer are producing shitty HTML and you can't just switch on a strict parsing.

But if history would have taken a slightly different turn, we would be talking about XHTML5 and not HTML5.

Users shouldn't have to care about this. If the browser can render the page it should.

This does raise the point that perhaps browsers should have a development mode that does raise errors though.

What I'm saying is that it is "not a mistake" to omit the closing tag in some cases. There are things that are hard when it comes to parsing HTML, but when to close open tags is not one of them. Rules for closing tags are trivial to implement and well documented. (Add: also, omitting unnecessary tags such as <html> and <body>)

Humans throw some HTML-like stuff at the browser and the browser tries hard to make sense out of it. If the browser misinterprets, you have a hard time finding out what went wrong.

I haven't seen any modern browser misinterpret HTML's (simple) closing rules. As for being harder to debug, I haven't seen any real evidence of that either.

Whereas with XML and XHTML you get told immediately what's wrong and you don't have to hope that every browser implementation works the same way.

Again, do you have any evidence of such incompatibility with current or recent browsers?

It's also a bit strange to argue about "easier to write manually" in this day and age of Markdown, HAML, etc.

Way more HTML is written by hand than Markdown and HAML. The issue isn't just saving keystrokes. The point is that whenever possible, technology should accommodate simple mistakes people make.

> It's also a bit strange to argue about "easier to write manually" in this day and age of Markdown, HAML, etc.

But, by that logic, isn't it also strange to argue about making HTML's syntax more consistent if we should be using Markdown/HAML/etc to generate it anyway?

BTW, i do agree with you in that having a more consistent syntax is better than having a syntax that aims to save a few keystrokes at the expense of adding special rules. As a user, i find it more difficult to have to remember which cases are special than to read or write a more consistent syntax. I just don't see how your comment on Markdown/HAML helps the case for a simpler HTML syntax ;)

There is nowadays less need for writing HTML by hand. HTML is more often generated from other formats and things like Markdown, HAML, and other lightweight markup languages helped in that.

But in the end the output is HTML and having a consistent syntax makes it easier to generate, read, and debug it.

Its syntax doesn't need to be dumbed down for casual users because casual users have other options. In that sense I think my comment is in support for a better HTML syntax. :)

Reply on news.ycombinator.com