Hacker News Reader

Comment by jefftk | Hacker News Reader

It's are "optional" in the sense that the spec says it's optional and defines what that means: "A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or 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."

View on HN

LOL. So I can memorize or check that list every time I'm using a p tag (and, of course, I'm relying on someone not doing something like changing the display property of a block element to inline), or... I can just use a closing p tag. I know which one is infinitely easier for me.

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 ``. 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 `` after the `</div>`.

Do browsers actually do that?

They can't produce imbalanced tags because it's impossible to represent in a DOM tree.

They will indeed auto close the (first) paragraph, and also auto open a new element because of the extra closing tag.

Try it out by typing this in your address bar and open the inspector:

    data:text/html;charset=utf-8,<!DOCTYPE html><p><div>hello</div></p>

The generated HTML (document.body.parentNode.innerHTML):

    <head></head><body><p></p><div>hello</div><p></p></body>

Browsers will go out of their way to produce a (valid) DOM from pretty much any string (as per the HTML5 spec). (Almost?) nothing is a syntax error. You won't get a HTML5-compliant browser to show a parse error to the user in HTML (of course, this is not the case in XHTML).

edit: sorry niconii, I edited my comment under your feet.

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

It is allowed by the spec afaik (the spec precisely tells browsers how to interpret this, so everything is perfectly specified in the spec boundaries - and so it's not "out of spec").

Of course, that screams "MISTAKE" that a validator should warn you about. Like a linter that would spot missing extra parentheses for an assignment in a if condition in C-like language. It is allowed to not put the parentheses, but it is recommended to put them.

And of course, that makes "Valid HTML" (almost?) redundant (There are probably "vocabulary" errors that are possible, like a missing src attribute for an img or a missing title tag in head - don't take my words on this though).

div in p is not invalid, it's outright impossible to obtain from HTML parsing.

You can obtain this by doing this in JavaScript:

    document.body.appendChild(document.createElement("p"));
    document.body.firstChild.appendChild(document.createElement("div")))

Or by parsing as XHTML:

    data:application/xhtml+xml;charset=utf-8,<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head><title>Hello</title></head><body><p><div></div></p></body></html>

You get:

    document.body.innerHTML

    <p xmlns="http://www.w3.org/1999/xhtml"><div/></p>

Which I realize is actually a bit scary, I go out of my way to write XHTML in the hope any error will be caught, but parsing as text/html actually produces a valid dom where parsing as XHTML won't necessarily.

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

I stand corrected! Thank you. I should have read the spec before posting.

The way tag inference is expressed in the HTML 5 spec is the problem here. What the HTML spec says is just a verbose description of SGML tag inference, by explicitly listing all elements that can't appear in a paragraph.

Citing from [1]:

Earlier [SGML] HTML DTDs included the following definition for flow capturing this in a rather straightforward way:

    <!ENTITY % flow "%block; | %inline;">

While HTML5 lacks it, a definition for "block content" rises again by subtracting those elements from the "flow content" category that aren't also in the "phrasing content" (inline) category.

Nesting of phrasing into flow elements is about the most basic property of the HTML grammar. In SGML, the flow/phrasing hierarchy is expressed by declaring the content model of flow elements as allowing %phrasing;, where %phrasing;, like in earlier HTML DTDs, is substituted into a string such as a|abbr|... containing all phrasing elements as a name group.

For example, the element declaration for the p element is as follows:

    <!ELEMENT p - O 
      (#PCDATA|%phrasing;)*
      -(%flow_only;)>

meaning that

- the content of p elements can be any sequence of text content (#PCDATA) and phrasing elements, and

- flow content isn't just forbidden in direct child content of p (via admitting %phrasing; elements only), but also isn't admitted anywhere in descendant content of p, as expressed by the -(%flow_only;) SGML exclusion exception, and

- the end-element, but not the start-element tag of p can be omitted, as declared in ps tag omission indicator - O

where the flow_only parameter entity contains block-level elements as described above, ie. flow elements that aren't also phrasing elements.

[1]: http://sgmljs.net/docs/html5.html

You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the continue, while things that can't (which is the long list there) close the . In practice you get used to it very quickly.

I can't believe the committee approved this spec without consulting me. I can see that I'm not the only one that feels this degree of agency in syntax is a bridge too far. Clearly this part of the spec was written by a Ruby developer.

The specification is just codifying what browsers already did in practice.

There was a time when people thought we might be able to change web development practice and browsers to something more consistent, but (a) what they chose was XHTML and (b) the benefit of switching was not there.

Reply on news.ycombinator.com