niconii

> If hypothetically 10% of the population said A but you slice up B into specific enough buckets then A wins even if the overwhelming majority dislike A.

Yes, if you're only allowed to vote for a single option. If you're allowed to vote yes/no for each option, or rank them from best to worst, then this problem doesn't happen.

Okay, let's go over this then.

First, let's talk about the basic case where there's no whitespace between the two paragraphs.

    <p>Paragraph 1</p><p>Paragraph 2</p>

In this case, the first </p> can be omitted according to the rule "A p element's end tag may be omitted if the p element is immediately followed by an [...] p [...] element [...]", resulting in this code:

    <p>Paragraph 1<p>Paragraph 2</p>

If we assume that the body ends immediately after this (either because there's a </body> or because we've reached the end of the file, since </body> and </html> are optional tags) then we can remove the second </p> as well because of the rule "A p element's end tag may be omitted if [...] there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element":

    <p>Paragraph 1<p>Paragraph 2

Now, let's get into the case where there is whitespace between the two paragraphs:

    <p>Paragraph 1</p>
    
    <p>Paragraph 2</p>

In this case, you can't remove the first </p>, because the rule is that it must be "immediately followed" by another p element. However, what if we start with this code?

    <p>Paragraph 1
    
    </p><p>Paragraph 2</p>

In this case, we can remove the first </p>, resulting in:

    <p>Paragraph 1
    
    <p>Paragraph 2</p>

and again, we can remove the last </p>, resulting in:

    <p>Paragraph 1
    
    <p>Paragraph 2

Now, this is different from what we started with. The whitespace is now inside the first paragraph instead of after it. But since HTML does not render this extra whitespace by default, it's of no real consequence.

And that leads us to this point: the HTML spec is specifying the exact circumstances where you can omit tags without changing the DOM. However, if we are okay with changing the DOM a bit, by moving that whitespace into the first paragraph, then we can simply pretend that we wrote

    <p>Paragraph 1
    
    </p><p>Paragraph 2</p>

from the beginning, and apply the rules to that instead.

In this comment section? Are you talking about stuff like the example I used earlier?

    <p><div></div></p>

Yes, obviously this is bad and nonsensical HTML. Under no circumstances does it make sense to have a div inside a p. In fact, the above doesn't even work, being parsed as

    <p></p><div></div></p>

But the intention of this example is not to show good HTML. The point is that many people have only a very basic understanding of HTML syntax, under the impression that

    <foo><bar></bar></foo>

works for any elements, because there's a <foo> and a </foo> so clearly anything inside it must be inside the foo element, right? But this is not the case for all elements. HTML's syntax is more complicated than that. My example was only intended to correct this misconception, not to demonstrate semantically-correct HTML, and that goes for other similar examples made by other people in the comments too.

I don't understand what you mean. Please elaborate.

That quote says that </p> is not needed in many cases. When you say "none of those clauses apply to <p>", this is true, you can't omit <p>, only </p>... but the blog article doesn't advocate for omitting <p> at any point.

Were the five unclosed runs before the five closed runs? I could see that making a difference vs. interleaving them, if the hardware needs to "warm up" first.

For me, on Firefox on Linux (I know it's the one with the smallest difference, but I don't have the others on hand, sorry), using the "load" time at the bottom of the Network tab, with cache disabled and refreshing with Ctrl+F5, interleaving the tests:

- Unclosed: 1.38s, 1.49s, 1.45s, 1.52s, 1.48s

- Closed: 1.47s, 1.37s, 1.48s, 1.49s, 1.35s

The one with </p> omitted takes about 0.032s longer on average going by these numbers, but that's about 2 frames of extra latency for a page almost twice the length of The Lord of the Rings.

Regarding the page itself, I tried to keep everything else as identical between the two versions as possible, including the DOM, hence why I wrote the </p> immediately before each <p>. As for backtracking, I'm not sure what you mean. The rule for the parser is simply "If the start tag is one from this list, and there's an open <p> element on the stack, close the <p> element before handling the start tag."

You have to know about what breaks out of <p> tags regardless of whether or not you leave off the end tag, though.

<p><div></div></p> is invalid HTML because <div> ends the paragraph, resulting in an unpaired </p>.

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):

  <table>
    <tr><th>sample rate</th> <th>data rate</th>    <th>max length</th></tr>
    <tr><td>32000 Hz</td>    <td>18000 byte/s</td> <td> ~3.641 s</td></tr>
    <tr><td>16000 Hz</td>    <td> 9000 byte/s</td> <td> ~7.282 s</td></tr>
    <tr><td> 8000 Hz</td>    <td> 4500 byte/s</td> <td>~14.564 s</td></tr>
  </table>

And now, take a look at it without the optional end tags:

  <table>
    <tr><th>sample rate <th>data rate    <th>max length
    <tr><td>32000 Hz    <td>18000 byte/s <td> ~3.641 s
    <tr><td>16000 Hz    <td> 9000 byte/s <td> ~7.282 s
    <tr><td> 8000 Hz    <td> 4500 byte/s <td>~14.564 s
  </table>

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.)

Oh, for sure, actually parsing HTML was awful before HTML5. The spec sometimes diverged from how browsers actually interpreted HTML, and error correction basically boiled down to browsers trying to reverse-engineer each other to figure out how they handled broken HTML. HTML5 was a godsend for actually standardizing all of that.