HackerTrans
TopNewTrendsCommentsPastAskShowJobs

niconii

no profile record

comments

niconii
·3년 전·discuss
> 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.
niconii
·4년 전·discuss
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.
niconii
·4년 전·discuss
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.
niconii
·4년 전·discuss
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.
niconii
·4년 전·discuss
Although there are some other uses for <p>, it is perfectly valid to use <p> tags for textual paragraphs and that has been the main use for <p> for as long as HTML has existed. I'm not sure why you believe otherwise.

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.
niconii
·4년 전·discuss
What's not in the spec? Every example in the article is valid HTML, and the article itself, which is written in the same style, is valid as well:

https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fb...

> Document checking completed. No errors or warnings to show.

Or are you complaining that the rules are too complicated? It's very verbose and explicit because this is a specification, but the basic rule of thumb is that anything that would normally be a block element and thus doesn't make sense inside a paragraph will end that paragraph. In practice, this is not really an issue I run into.

Moreover, you need to know about this rule even if you don't omit </p>, because this is the list of elements that implicitly ends a paragraph. For example, <p><div></div></p> is invalid HTML because <div> ends the paragraph implicitly, making it equivalent to <p></p><div></div></p>.

If you don't like that, then your problem is not with this particular code style but HTML itself, which is reasonable. HTML's syntax is very complicated due to its history and doesn't always make sense. But you still have to know how it works regardless of how you personally like to write it.
niconii
·4년 전·discuss
One interesting detail is that a lack of deep nesting was in fact a deliberate design goal for HTML originally, to make WYSIWYG editing more feasible.

http://info.cern.ch/hypertext/WWW/MarkUp/HTMLConstraints.htm...
niconii
·4년 전·discuss
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."
niconii
·4년 전·discuss
I can't verify your numbers. As far as I can tell, loading a ~900,000 word document with no other differences than including or excluding </p> has about the same load time, though there's too much variance from load to load for me to really give definitive numbers.

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:

https://niconii.github.io/lorem-unclosed.html

https://niconii.github.io/lorem-closed.html
niconii
·4년 전·discuss
https://html.spec.whatwg.org/multipage/syntax.html#optional-...
niconii
·4년 전·discuss
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>.
niconii
·4년 전·discuss
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.)
niconii
·4년 전·discuss
This is not quite right. The HTML spec specifies not only what browsers/user agents are allowed to do, but also what document authors are allowed to do.

While the HTML parser does handle errors, to conform to the spec, document authors must not make these errors.

Here is an excerpt from the spec[1]:

> As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.

Furthermore, a user agent is not required to correct errors, and can simply halt at the first error[2]:

> The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.

[1] https://html.spec.whatwg.org/multipage/introduction.html#how...

[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
niconii
·4년 전·discuss
Just to add to this, HTML parsers will attempt to make sense of any random line noise you give it and turn it into a DOM. When I say something is "invalid" HTML, what I mean is that it's not allowed by the spec and will result in an error if you run it through a validator (which you should do!)

For example, try running the following document through the W3C's HTML validator[1]:

  <!DOCTYPE html>
  <html lang=en>
  <title>Test Document</title>

  <p>
    <div></div>
  </p>
The HTML spec contains a list of all possible parse errors[2].

[1] https://validator.w3.org/nu/#textarea

[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
niconii
·4년 전·discuss
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.
niconii
·4년 전·discuss
I mentioned "block elements" in my other comment, but to be clear, CSS has no effect on how HTML is parsed, so the display property isn't relevant here.

Furthermore, you need to know about this rule even if you do write `</p>`. If you write this:

    <p>
        <div>hello</div>
    </p>
it is invalid HTML. This is because the paragraph is auto-closed, and then your code is equivalent to this:

    <p>
        </p><div>hello</div>
    </p>
resulting in an error because of the extra `</p>` after the `</div>`.
niconii
·4년 전·discuss
Yes, that is a case where it's not legal to omit `</p>` if you don't want the image to be inside the paragraph. Take a look at the spec[1], which outlines exactly when it is valid to omit tags.

The `p` element in particular has pretty scary rules, but it basically boils down to "if it doesn't make sense for this to be inside a paragraph (usually because it's a block element of some kind), it ends the paragraph."

[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
niconii
·4년 전·discuss
Well, then they were wrong, because it's always been part of every HTML spec.

Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
niconii
·4년 전·discuss
Just to clarify, HTML5 didn't introduce this, it's been the case since at least 1993.

https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
niconii
·4년 전·discuss
I'm pretty sure they're talking about Japan, not the US.