3 ms·
I know that HTML5 deliberately throws out the SGML heritage (to say nothing of XHTML) and makes all of this valid, but this just feels like another micro-optimi
by niftich 10y ago
I know that HTML5 deliberately throws out the SGML heritage (to say nothing of XHTML) and makes all of this valid, but this just feels like another micro-optimization that Google promotes because at their scale, every little bit helps.
Besides, isn't this "visual redundancy" (not to be confused with semantic redundancy) is what compression is supposed to solve, and has been solving since, effectively forever? So that we can code to reduce our (and the 'view source'-reader's) cognitive load, and let gzip or brotli or whatever new scheme work its compressive magic before it squirts our payload across a newfangled binary HTTP/2 protocol?
- rimantas 10y agoIt is not new in HTML 5. You could omit a lot and have perfectly valid HTML 4.01 Strict too.
- bjt 10y agoThe styleguide mentions "scannability purposes". It doesn't say whether it's machines or humans doing the scanning, but I can definitely see the benefit to the latter. Code is read many more times than it's written. Removing unnecessary noise makes it easier to read.
- hannob 10y agoCompression for HTML has some nasty security consequences (attachs with funny names like CRIME, BREACH, TIME, HEIST) and nobody has any good idea how to solve them. We may see more practical attacks on that in the future and may be forced to remove compression in many cases.
- dunham 10y agoBut the SGML heritage is what makes this valid, and it is common in other SGML doctypes. (e.g. if you download OFX data from your bank, the closing tags will be omitted from certain elements.) Both the optional closing tags for P and the optional opening tags for stuff like HTML, BODY, TBODY, etc. are present in the HTML 4.0 DTD too. (A TR element cannot go in a TABLE element, there is an implicit TBODY.) And SGML, HTML, and optional tags go back to before XML existed.