4 ms·

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 immedia

by jefftk 5y ago

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

irrational 5y ago
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.
- jefftk 5y ago
  You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the <p> continue, while things that can't (which is the long list there) close the <p>. In practice you get used to it very quickly.
- niconii 5y ago
  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>`.
  - legalcorrection 5y ago
    Do browsers actually do that?
    - jraph 5y ago
      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 <p> element because of the extra closing </p> 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.
      - niconii 5y ago
        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 https://validator.w3.org/nu/#textarea [2] https://html.spec.whatwg.org/multipage/parsing.html#parse-errors https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
        jraph 5y ago
        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.
- tannhaeuser 5y ago
  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 http://sgmljs.net/docs/html5.html
trey-jones 5y ago
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.
- jefftk 5y ago
  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.

by jefftk 5y ago

irrational 5y ago

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.

jefftk 5y ago
You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the <p> continue, while things that can't (which is the long list there) close the <p>. In practice you get used to it very quickly.
niconii 5y ago
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>`.
- legalcorrection 5y ago
  Do browsers actually do that?
  - jraph 5y ago
    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 <p> element because of the extra closing </p> 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.
    - niconii 5y ago
      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 https://validator.w3.org/nu/#textarea [2] https://html.spec.whatwg.org/multipage/parsing.html#parse-errors https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
      - jraph 5y ago
        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.
tannhaeuser 5y ago
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 http://sgmljs.net/docs/html5.html

trey-jones 5y ago

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.

jefftk 5y ago
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.