Whilst 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.<p>Unscientific stats from a recent project where I noticed it:<p>+ Document is about 50,000 words in size. About 150 words to a paragraph element, on average.<p>+ Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render.<p>+ Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render.<p>+ Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render.<p>+ Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render.<p>+ The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words.<p>+ 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.)<p>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.<p>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.
Although, as the article correctly points out, omitting the HTML tag is technically fine, there is one rather important argument for its inclusion: it can and should have a LANG attribute:<p><pre><code> <html lang=en-GB>
</code></pre>
It's not verbose after all, and IIUC may be omitted if and only if the document is served with corresponding information in `Content-Language:` HTTP header, but nasty (or rather annoying) things may happen if that fails [1], so when it comes to "right HTML", following this advice sounds reasonable.<p>[1] <a href="https://adrianroselli.com/2015/01/on-use-of-lang-attribute.html" rel="nofollow">https://adrianroselli.com/2015/01/on-use-of-lang-attribute.h...</a>
No thanks. With the full markup you can see where things end, not just where they start.<p>I think this is similar to semicolons in Javascript: with semicolons at the end of each statement there is no ambiguity, but if you do not have semicolons, you have to know about edge cases, like if a line starts with a square bracket or paren.
This 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.
Regarding writing "one-sentence-per-line", I've noticed that style before in LaTeX. While I don't use that style, one advantage that I like is the ability to include comments on the sentence level in LaTeX.<p>So instead of this:<p><pre><code> First sentence. Second sentence. % Comment on first sentence.
</code></pre>
I can write:<p><pre><code> First sentence. % Comment on first sentence.
Second sentence.
</code></pre>
(Of course, one could define a new TeX macro that doesn't display anything to add comments anywhere in-line. That's not as readable, though.)<p>I've also read that one-sentence-per-line works better with diff programs, but I haven't had any problems with the program meld, so this isn't convincing to me. The advantage the linked article mentions in terms of rearranging sentences also is worth considering, though I haven't found the normal way to be that bad so I'm not convinced by that either.<p>Some other links on this coding/writing style:<p><a href="https://rhodesmill.org/brandon/2012/one-sentence-per-line/" rel="nofollow">https://rhodesmill.org/brandon/2012/one-sentence-per-line/</a><p><a href="https://news.ycombinator.com/item?id=4642395" rel="nofollow">https://news.ycombinator.com/item?id=4642395</a><p><a href="http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-editing-thinking-with-line-breaks/" rel="nofollow">http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...</a>
> A few years ago, I found out I'd been tying my shoes wrong for my entire life. I thought laces came undone easily and didn't usually look very good. At least that's how mine were, and I never paid much attention to anyone else's. It took a couple of weeks to re-train my hands but now I have bows in my laces that look good and rarely come undone.<p>I’m equally interested in this as the HTML. Any clue what the author is referring to?
I 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 :)
Thanks to Aaron for posting this. Such a great reminder.<p>Anyone interested in this subject, check out a series of three very tiny books called “UPGRADE YOUR HTML” by Jens Oliver Meiert.<p>They give great step-by-step examples for eliminating optional tags and attributes, reducing HTML to its cleanest simplest valid form. The author is a super-expert in this specific subject, working with Google and W3C on this. His bio here: <a href="https://meiert.com/en/biography/" rel="nofollow">https://meiert.com/en/biography/</a><p>From LeanPub:
<a href="https://leanpub.com/b/upgrade-your-html-123" rel="nofollow">https://leanpub.com/b/upgrade-your-html-123</a><p>From Amazon:
<a href="https://www.amazon.com/gp/product/B08NP4GXY2/" rel="nofollow">https://www.amazon.com/gp/product/B08NP4GXY2/</a>
At this point you are better off making a DSL that compiles to html.<p>- it will be possible to be consistent with closing tags or not<p>- you can do other arbitrary things to improve your working experience with it<p>Ever tried Slang styled templates?
I like this idea. As someone who argued vehemently for XHTML a couple decades ago (even wrote a fair amount of XSLT in those XML-crazed days), who's been wandering between different levels of "how strict should I be?" since that time, this article marks the step of my journey where I feel like I can really embrace the goodness that SGML has to offer for the first time. So thank you. This article has changed me.
I like the aesthetic though I'm not sure how sustainable it is beyond basic content documents. On a side note though, I clicked around and big props to Aaron on the lofi.limo project, this is very cool.
HTML can't be fixed with a small trick like that.<p>Just use templating engine like Pug and get away with most of the annoyances.<p>It's concise about what part of the text is covered by a certain tag due to forced indentation, not to mention you'll never need to close any tag and you never write "class=" but are all turned into CSS selector notation among many other tricks.<p><a href="https://github.com/pugjs/pug#syntax" rel="nofollow">https://github.com/pugjs/pug#syntax</a><p>Unless the HTML I'm composing will be touched by people like designers who would get scared of new syntax, in which case I'll use Twig or Nunjucks, I'll never write plain HTML for myself.<p>There's also a very solid implementation in PHP as well.<p><a href="https://github.com/pug-php/pug" rel="nofollow">https://github.com/pug-php/pug</a><p>You can either let server side (node.js or PHP) compile that on demand or let your editors compile them as you edit if you're working on a static file.<p>I really think the language humans write should deviate from the language the runtimes understand to get all the convenience while never breaking how runtimes/crawlers interpret your output. Same goes for Stylus against CSS.
> However, any content which cannot go in a p element (most other block-display elements, for example) implies the end of its content, so we can usually leave off the end tag.<p>Note however that this means that the whitespace between paragraphs will be part of the paragraph which can be annoying if someone tries to copy the text on your website and gets an additional space after each paragraph which wouldn't have happened if you explicitly closed the </p> directly after the text.<p>Also, you should keep the opening <html> and specify the language of your document even for english since e.g. automatic hyphenation does not work if you don't specify a language.<p>Otherwise really like this condensed HTML style and have recently converted my personal website to it.
If you must write html by hand this seems nice. But I would never actually write html by hand anymore. For most web apps you write more tags than text. I love slim because it was designed with that in mind. There is no overhead to writing tags, and just a little for writing text. Which is the right way to go for web apps.
omitting <html> 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.
Why does it matter? A good HTML editor ought to be able to take in HTML, display it and edit it according to the user's preferences, and save it in a size-minimizing way. Why should we have to choose only one way?
Author: write HTML right
Me: this green on black background is terrible to read, I'll use reader mode
Chrome: this author did not write their HTML correctly, so there is no reader mode available<p>How ironic.
Is there a tool to convert an existing HTML document into this style? E.g. strip out optional closing tags, without doing full minimisation/whitespace stripping.
I've been using <a href="https://github.com/terser/html-minifier-terser" rel="nofollow">https://github.com/terser/html-minifier-terser</a> to get this kind of HTML for my personal site for a while. It passes W3C so I'm happy.<p>After reading the connected blog post <a href="http://perfectionkills.com/experimenting-with-html-minifier/" rel="nofollow">http://perfectionkills.com/experimenting-with-html-minifier/</a>
Slightly off topic but I'd like to point out that paragraphs in HTML are grouping not textual elements. They are like divs or headers, not like span or b.<p>They are mistakenly and traditionally associated with literature-type paragraphs but that is not correct. You generally use them in forms to split different groups or inputs, that has nothing with paragraphs of a written form and even less with textual paragraphs.<p>I think there is really a lot of confusion about them in this whole thread.
> It used to be the case that URL parsers would remove newlines and tabs, so we could split long URLs across lines and even format their query parameters nicely with tabs. Unfortunately, this was taken advantage of for data exfiltration via HTML injection and we no longer have this nice thing as URL parsers have been made more strict to prevent this kind of attack.<p>Does anyone have a source/reference for this?
Figure 2. showing the "common style" is something I've never used or seen before.<p>What is the "right" way? Perhaps it is to use style from both of these extreme examples and write code that is easy to read and edit for the person that is working with it.<p>Or perhaps the right way is to never imply the way you are doing things is the only correct way and then try to pass it on as facts?
I too found out I'd been doing my shoelaces wrong. YouTube set me straight.<p>For HTML, these are good recommendations.<p>Sometimes, like for technical writing where there are<p><pre><code> various
</code></pre>
<i>distinct</i> and important formatting choices, it's just hard work to get it the way you want it even with a WYSIWYG editor.
Closing li tags is the right thing to do! I always close the kitchen drawer too after putting the scissors back. But I rarely write HTML as content anyway, it's mostly templates for the CMS, where it's best to close the tags.
While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?
In 2022 how often do you actually write text by hand in your HTML files? I find that beside the few buttons here and there (and that's if you don't have i18n), text is always going to be served by a server.<p>In 2022 we also all use text editors or IDEs that can collapse entire blocks of tags, to improve readability.<p>I'm not sure I can see a clear benefit here outside of very few edge cases, and I am sure it comes with its lot of disadvantages.