omitting works fine in browsers but breaks a lot of other developer tooling in my experience. It's nice to save 6B I guess, but compared to the behemoth webapp it's wrapping it's not much of an optimization.
Write HTML Right
51–60 of 212 posts
Re: Write HTML Right
#52I appreciate that this blog post itself is written in the exact same style! I really miss being able to read the view-source: version of websites easily, but this blog post does it well :)
Certainly beats the "you don't need so much JavaScript!" blog posts that load 10 external scripts.
Re: Write HTML Right
#53Earlier quoted context omitted.
…for non-tabular data such as “your pretty design elements that frame and organize the text because it is 1995 and CSS doesn’t exist yet and this is the only tool at your disposal for aligning stuff across the page”. Or because it is 2000 and putting stuff where you want it is a hell of CSS2 floats and box models and eventually you just say “fuck it” and assign table-like behavior to a bunch of divs because Tables Fo…
It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible bor…
There was never a well-substantiated argument for the alleged harm of layout tables. Demonizing them mostly just stemmed from the cult of wanting to completely confine layout to CSS vs. expressing semantics with HTML. In the end that “CSS zen” was never really achieved, because the dependencies between HTML structure and styling are just too many and too strong.
Re: Write HTML Right
#54Whilst the spec certainly allows you to ignore closing of a whole range of elements, it's not necessarily the wisest of choices to make. The parser does actually get slower when you fail to close your tags in my experience.
Unscientific stats from a recent project where I noticed it:
+ Document is about 50,000 words in size. About 150 words to a paragraph element, on average.
+ Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render.
+ Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render.
+ Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render.
+ Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render.
+ The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words.
+ Curiously, Quirks Mode also increased the load times by about 250ms on Firefox and 150ms on Chrome. (Tried it just because I was surprised at the massive overhead of removing/adding the tag endings.)
The most common place this was going to be opened was Chrome on Android, and a whopping half-second slower to first render is going to be noticeable to the end user. For some prettier mark up.
Whilst you can debate whether that increased latency actually affects the user, a decreased latency will always make people smile more. So including the end tags is a no-brainer. Feel free to write it without them - but you _might_ consider whether your target is appropriate for you to generate them before you serve up the content.
Re: Write HTML Right
#55XML is beautiful and clean, and I prefer to write full closing tags.
Re: Write HTML Right
#56> gator What do they mean here?
Less-than or greater-than signs (code points 0x3C and 0x3E in ASCII). A friend put me on to calling them that because they (sort of?) look like alligators with their mouths open.
My math teachers used an alligator analogy to remind us which is the correct symbol for using the greater - and less - than sign, the 'mouth' of the gator is always eating the greater number.
Re: Write HTML Right
#57Earlier quoted context omitted.
Less-than or greater-than signs (code points 0x3C and 0x3E in ASCII). A friend put me on to calling them that because they (sort of?) look like alligators with their mouths open.
My math teachers used an alligator analogy to remind us which is the correct symbol for using the greater - and less - than sign, the 'mouth' of the gator is always eating the greater number.
Re: Write HTML Right
#58Earlier quoted context omitted.
It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible bor…
The "Tables are Harmful" club largely came from the crew who thinks HTML carries lots of semantics and that if you don't use the Blessed Tags that carry those semantics you're doing Bad Design. The rational evidence in favor of this claim has always been weak. The "div" tag basically finished it off. The people who use HTML "semantically" have always been dwarfed by the people just making it look good on the screen,…
> the idea persists to this day despite its near complete failure to pay off significantly in nearly twenty years
I am not clear on exactly what "the idea" refers to, perhaps you could clarify. Also, how has the idea "completely failed"? And what would complete success look like?
Re: Write HTML Right
#59I've been using https://github.com/terser/html-minifier-terser to get this kind of HTML for my personal site for a while. It passes W3C so I'm happy.
After reading the connected blog post http://perfectionkills.com/experimenting-with-html-minifier/
Re: Write HTML Right
#60This works for blog posts, where the body of the document is one long block of paragraphs, but I suspect this style would quickly become untenable for complex apps. Indentation _is_ information, which is lost here.
it doesn't work for even slightly complex documents either. there's been a little meme-fad lately around minimalistic html like this, but to claim it's the "right" way to write html is pompous at best.
not closing tags for instance is really asking for future headaches. sure, it works for a simple text list, but not when it gets even a little complicated (add links, images, buttons, etc.). even worse are p tags, where you have to memorize a whole matrix of what it can contain and what breaks out implicitly. with every insertion/deletion, you need to check the list. it's needless mental drag.