Okay, I've gotten a bit carried away with HTML spec minutia elsewhere in these comments, mainly because this stuff really isn't common knowledge among web developers and it's hard to resist talking about it.
However, I also want to add to the other point here; namely, "why do this in the first place?"
Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.
For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):
Personally, this is much easier for me to read and maintain. There's also much less chance of me accidentally mismatching opening and closing tags, since I've eliminated almost all of the closing tags besides </table>.
On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
How likely is it that a dev would be reading an HTML table with hardcoded data in the code editor in this day and age?
Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.
HTML tables are similarly cumbersome, with or without closing tags. If you have a table of static information to fill in, copy/pasting from Excel into a HTML table generator and pasting the output is signficantly faster.
What is your point? Even if it is a rare occurrence, from time to time you might want to output an html table using "print", and it will be slightly more comfortable that way. I sometimes find myself editing html by hand. Thanks to the optional and auto-closing tags it is just as easy as markdown, and you don't need an extra conversion step.
The verbose format has no advantage whatsoever, unless you are doing weird xml stuff.
However, I also want to add to the other point here; namely, "why do this in the first place?"
Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.
For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):
And now, take a look at it without the optional end tags: Personally, this is much easier for me to read and maintain. There's also much less chance of me accidentally mismatching opening and closing tags, since I've eliminated almost all of the closing tags besides </table>.On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)