Hacker News Reader

Comment by JodieBenitez | Hacker News Reader

Yes... but why do this ? I don't regret the XHTML days and its feature stagnation, but this is just useless.

I learned HTML when XHTML 1.0 was current. I've long preferred strict HTML written using XML. It helps spotting mistakes, and there are no parsing surprise.

Now that HTML5 parsing is well specified, I've come to think that either you want to be strict and have the browser tell you something is wrong, and you use XHTML for this, or all these optional tags are just useless.

I want to optimize readability, and then file size. I believe closing all tags you opened and quoting all attributes helps readability, and also that all these <head>, <body>, <html> tags just get in the way and make your eyes go through useless boilerplate and makes your fingers type useless things too if you don't use templates.

You still need to specify the charset so characters are interpreted correctly, so for me, if you are not going to use application/html+xml anyway this works well:

    <!DOCTYPE html>
    <meta charset="utf-8" />
    <title> My title </title>

    <p> Lorem ipsum... </p>

Both quicker to read and write, while not raising maintenance costs.

Though just yesterday I edited my resume written in XHTML and the browser actually spotted a dumb mistake, so I still like the strictness of the XML parsing mode.

One counterpoint to dropping the optional tags is for pedagogy: if I had to teach HTML to someone, I would make them use all the tags, or the result of having html and body in the DOM and CSS working on them will be very confusing. Only when they understand the DOM, what nodes are in an HTML page, I'd make them drop the tags if they want. Which is an important step so they can understand that nodes that are present in the DOM are not necessarily in the source code.

You need to include the <html> tag for the lang attribute, which is important for accessibility.

Good point!

I believe it can be put on any element, but if you are adding a tag just for this, it might as well be <html>.

It is a formal specification of what browsers used to do with a broken HTML. Because it is now fully specified, everyone can safely write a broken HTML (half joking!), but also there is no longer a surprising behavior due to diverging behaviors from different browsers.

Good... now let's make a formal specification for this:

    <ahahah>mmm... <ohoho>nope.</ahaha></ohoho>

Fully joking :-P

I believe whatwg did in fact specify for this kind of overlapping tag.

edit: apparently it has the cute name of "the adoption agency algorithm":

https://html.spec.whatwg.org/multipage/parsing.html#adoption...

> Note: This algorithm's name, the "adoption agency algorithm", comes from the way it causes elements to change parents, and is in contrast with other possible algorithms for dealing with misnested content.

At least the people who named it understood the silliness of the issue, heh.

It is not as silly as it sounds. Many programming language implementations allow a partial parser that looks similar to this in order to give better diagnostics even when the AST is incomplete. (I did the same in the past, for example.)

It's very useful.

I use optional -- therefore abbreviated -- HTML syntax as an alternative to MarkDown for writing.

You're saying you're using an abbreviated HTML as an alternative to a markup language that is a lightweigth alternative to the markup language known as HTML ?

We need to go deeper. •`_´•

Yes, exactly. There are three advantages:

1. No translation of markdown to HTML is required to turn it into a web-page, the medium I primarily work in. It's not required -- I can read nicely formatted raw HTML just fine.

2. Lower cognitive load. Damn if I can remember if a link in markdown is ()[] or []() or the link goes first or the link goes last. But a link in HTML is consistent with the rest of the language.

3. HTML is richer than Markdown. I make heavy use of <abbr> and <cite> and <time>, not to mention metadata tags. My position is if you need to include HTML in Markdown to express yourself, you might as well write in HTML instead of construct some hybrid bastard document.

> My position is if you need to include HTML in Markdown to express yourself, you might as well write in HTML instead of construct some hybrid bastard document.

I agree. I just don't think it's very useful to omit close tags. Any decent editor will maintain them for you.

This way you can send spam sms messages with little html markup and google analytics.

It was a codification of existing browser practice. Specifying something different wouldn’t have changed browser behavior, it would only have led to browsers ignoring the spec.

Why not. If there is no ambiguity you save characeters (few bytes, but for each page) and thus pages will load faster even on slow connections. Also if you write HTML by hand (something not a lot of people does these days, but for example for my site I do) it's less characters to type and it's simpler.

The problem is that every parser and emitter needs to be aware of these weird and changing rules. It wouldn't be that bad if the only things that read HTML were browsers but as it is every language has HTML parsers that are broken different ways leading to bugs and security vulnerabilities.

For example emitters need to know what void elements are because <br></br> is actually equivalent to`<br><br>`. But `<script src=foo.js/>` is only an opening tag so the rest of your document will be executed as JavaScript. So you can't just write an emitter for arbitrary elements, you need to emit different things for `br` and `script`. Plus `script` has special escaping rules that are often forgotten about. Plus you better keep that list up to date!

With XHTML it is very easy to write a parser that will construct a tree forever and can reserialize it with no issues. I have no issues with consistent changes such as empty attributes and unquoted attribute values, but I think that these element insertion, auto-closing, void elements and non-replaceable character data are a mistake because you need to maintain an up-to-date dataset of these custom rules or you get an incorrect result.

HTML is still feature-stagnated; features are mostly added to JavaScript and DOM APIs.

Yeah, let's say I'm late to the party then. But still, the improvements compared to HTML4 are huge.

CSS gets relatively frequent new features too. I think this status quo is fair enough - HTML is just there, and I never really think about needing more out of it. CSS and JS though I do find myself waiting for browsers to support upcoming experimental features often enough.

Reply on news.ycombinator.com