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.
Are you sure you converted it properly? I'd expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it's not valid to do so), but I don't see why leaving out </p> should be so slow.
Try these two pages:
+ Unclosed: 4.00s, 3.91s, 3.59s, 4.45s, 3.93s
+ Closed: 3.90s, 2.74s, 3.9s, 2.05s, 3.39s
Though I'd note that the newline you have immediately following the paragraph, even when closing, would probably reduce the backtracking effect. And having no explicit body or head element would probably cause some different rendering patterns as well.
<p>Content<p>Content[EOF fig1]
<p>Content</p><p>Content</p>[EOF fig2]
<p>Content</p>
<p>Content</p>[EOF fig3]
<p>Content
<p>Content[EOF fig4a]
<p>
Content
<p>
Content
[EOF fig4b]
<p>Content
</p>
<p>Content
</p>[EOF fig5]
(Sorry for wildly biased guesswork, worthless without measurements.)
All paragraphs had a blank line between them, both with and without the p end tag. The p opening tag was always at the top-left, with no gap between it and the content.
So, for example:
<p>Cheats open the doorway for casual play. They make it easier for disabled players to enjoy the same things as their peers, and allow people to skip parts of a game that <em>they bought</em> that they find too difficult.</p>
<p>Unfortunately, cheats are going away, because of extensive online play, and a more corporate approach to developing games that despises anything hidden.</p>
<p>Cheats open the doorway for casual play. They make it easier for disabled players to enjoy the same things as their peers, and allow people to skip parts of a game that <em>they bought</em> that they find too difficult.
<p>Unfortunately, cheats are going away, because of extensive online play, and a more corporate approach to developing games that despises anything hidden.
However, if you wanted to look at this in a more scientific way - it should be entirely possible to generate test cases fairly easily, given the simplicity of the text data I saw my results with.
But then if you run it through Prettier it'll add all the closing tags for you :)
Are what more strict? You're missing a subject there.
At a guess, you're referencing the differences between Chrome/Firefox rendering times? And are surprised that Chrome is always slower?
In the same completely unscientific stat taking, I found that Chrome was significantly faster at parsing the HTML head element of a document than Firefox, and that difference was enough for Chrome to pull ahead of Firefox in overall rendering times for smaller pages. (Chrome was about 30% of Firefox's time spent in the head.)
However, Firefox was faster at parsing the body, and as I had a larger-than-usual body (50k words is not your average webpage), Firefox was overall faster.
Every time the author introduced a shorthand, they had to clarify that it works only in specific situations. The result of those qualifiers is that you will have to have some code written in the more verbose style anyway. Context switching between those styles and having to decide whether the shorthand works in any given case just isn't worth it on a large project that you'll be making changes to over time.
<html lang=en-GB>
[1] https://adrianroselli.com/2015/01/on-use-of-lang-attribute.h...
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.
<p>
Paragraph with a list won't work as you could think
<ul> <li> Test </li> </ul>
Something else
</p>
<p>
Paragraph with a list won't work as you could think
</p>
<ul> <li> Test </li> </ul>
Something else
<p></p>
return
{
x: 1
};
I'd much prefer these features to be opt-in (yea, give me XHTML back for generated content). But when I can't can't disable them, why not embrace them ;)
JS semicolon insertion is worse, because it depends on the following line. In Python, an unescaped newline outside of brackets always ends the statement, but in JavaScript, parentheses, brackets, binary operators, and template literals on the following line change that. The Python rule also makes a dangling operator outside of brackets a syntax error, which is a potential source of unintentional introduction of ASI when making changes to code in JavaScript.
You can still use XHTML; just send "Content-Type: application/xhtml+xml". You can express the same things as an HTML document, but with a saner parser mode.
Periodically I have to send code to people who then make some of their own changes inline. God forbid trying to explain "yeah, they don't need to be closed, but that does because it's nested and..." Disaster (/hours of extra support) waiting to happen.
<p>Hello <p>World</p>!</p>
And when you do know HTML, you might as well omit optional tags.
If you think that HTML syntax is crazy, I won’t blame you, and you might consider XHTML instead, but you should be prepared for different woes.
I remain unconvinced it was a wise idea.
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.
<p><div></div></p> is invalid HTML because <div> ends the paragraph, resulting in an unpaired </p>.
Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.
The DOM is a tree, with nested elements. Losing that information doesn't get you anything but tag soup (which is, oddly, what the author suggests this style is supposed to avoid)
So instead of this:
First sentence. Second sentence. % Comment on first sentence.
First sentence. % Comment on first sentence.
Second sentence.
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.
Some other links on this coding/writing style:
https://rhodesmill.org/brandon/2012/one-sentence-per-line/
https://news.ycombinator.com/item?id=4642395
http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...
I’m equally interested in this as the HTML. Any clue what the author is referring to?
https://www.fieggen.com/shoelace/
Specifically:
https://www.fieggen.com/shoelace/grannyknot.htm
An HN favorite:
If your first cross is left over right you need to make your second cross right over left, or vice versa. I found an image showing the difference for the un-slipped version, but it's the same with a bow: http://www.tikalon.com/blog/2020/square_granny_knots.png
Granny knots untie themselves and the bow will end up perpendicular to the knot instead of parallel.
> The right way to tie your shoes is with a square knot. It's easy to confuse this with the granny knot, which is the wrong way. The square knot is a simple and sound knot with many uses. The granny knot is an unsound knot whose only known uses are to make your shoelaces look crooked and to trip you.
You look goofy trying to relearn to tie your shoes, but it really is fast and sturdy.
Anyone interested in this subject, check out a series of three very tiny books called “UPGRADE YOUR HTML” by Jens Oliver Meiert.
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: https://meiert.com/en/biography/
From LeanPub: https://leanpub.com/b/upgrade-your-html-123
From Amazon: https://www.amazon.com/gp/product/B08NP4GXY2/
Reminder of what? To me this reads like satire, even if it wasn't intended as such.
(Also: a huge thank you for creating SingleFile. One of my favourite extensions of all time.)
Pretty neat extension!
- it will be possible to be consistent with closing tags or not
- you can do other arbitrary things to improve your working experience with it
Ever tried Slang styled templates?
If you’ve got stuff that would look good as a table, use a table.
I wouldn't mind if we had a bunch more basic content documents on the web.
Just use templating engine like Pug and get away with most of the annoyances.
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.
https://github.com/pugjs/pug#syntax
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.
There's also a very solid implementation in PHP as well.
https://github.com/pug-php/pug
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.
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.
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.
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.
Otherwise really like this condensed HTML style and have recently converted my personal website to it.
It causes way more trouble than those benefits are worth
Omitting the closing tags where possible is less about saving keystrokes than minnimising interruptions to my writing flow.
But I wouldn't advocate it for published documents, just my local scribblings.
How ironic.
... anyway, it bothers me sometimes that I'm not aware of any spec for "reader mode compatibility", did anyone see anything like that?
I do not know what criteria are needed for the reader mode in Chrome. (The HTML code looks OK to me?)
After reading the connected blog post http://perfectionkills.com/experimenting-with-html-minifier/
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.
I think there is really a lot of confusion about them in this whole thread.
Take a look at the source code for http://info.cern.ch/hypertext/WWW/MarkUp/Future.html for instance, which was written by the creator of HTML, Tim Berners-Lee.
You can also look at the source code for any page of the current HTML spec (e.g. https://html.spec.whatwg.org/multipage/introduction.html) where, again, <p> is used for each paragraph in the text.
Paragraphs relate to grouping content[1], not textual one. There's no logic in paragraphs.
I quote here the official spec, which makes various examples of how paragraphs are not related to logical paragraphs:
> The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list.
And I'll quote also the definition on MDN:
> The <p> HTML element represents a paragraph. Paragraphs are usually represented in visual media as blocks of text separated from adjacent blocks by blank lines and/or first-line indentation, but HTML paragraphs can be any structural grouping of related content, such as images or form fields.
Failing to realize that paragraphs are grouping rather than logical content leads to frequent misuses of paragraphs and this comment section is literally filled by bad paragraphs examples which suggests the community is largely ignorant on html.
[1]https://html.spec.whatwg.org/multipage/grouping-content.html...
What do they mean here?
Does anyone have a source/reference for this?
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.
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?
For HTML, these are good recommendations.
Sometimes, like for technical writing where there are
various
1) not everybody knows and
2) you're relying on memorization for people to read your code, which means you're smashing the ladder rungs behind you
Software on a team is a performance art. People are either watching you and copying your behavior, or watching you and getting confused.
And if you've ever felt overbooked on a project while other people are idle? It's stuff like that that put you into that situation. And since you're the one who did the 'stuff like that', it's at least partly your fault you're in this situation. Stop being a ball hog, and you'll get fewer bruises.
Browsers are not really fast on my Android, and I wish they were fast.
In 2022 we also all use text editors or IDEs that can collapse entire blocks of tags, to improve readability.
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.
Do you consider any table that doesn’t explicitly declare <tbody> “unclean”? That’s an implicit element in every <table>, according to the spec.
(sorry)