9 ms·

Maybe it will make more sense once it fully sinks in, but I think in general it is a mistake to make developers think about when and where certain things can be

by kgtm 10y ago

Maybe it will make more sense once it fully sinks in, but I think in general it is a mistake to make developers think about when and where certain things can be omitted. It's more straightforward to simply do one thing, consistently, following the "explicit is better than implicit" mantra. What happened to optimizing for mental overhead instead of file size? This simply should be a build step, part of your minification and concatenation dance, not having to consider all of these when trying to decide if I should close my <p> tag or not: 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.

userbinator 10y ago
but I think in general it is a mistake to make developers think about when and where certain things can be omitted. Yes, sometimes it is better to make developers think about when and where certain things are required.
nchelluri 10y ago
I agree, but maybe a transformer step could do it automatically. Write full HTML, generate less.
- h1d 10y ago
  After 20 years of composing HTML, the world can do better than write full HTML but use technology like jade and not worry about what goes to the browser...
  - CoryG89 10y ago
    Why not worry about what goes to the browser? In my eyes, what actually runs in the browser is the only thing that matters in the end. You could still write in something like Jade, transpiler, minify, then strip unneeded tags, all with automation.
    - h1d 10y ago
      I didn't mean not to care what goes to the brower, I meant if tools like jade does it right for us, the rest of us no longer have to care about those little details. Frankly I'm amazed the HTML way of verbose writing still stands after all these years in a fast paced industry.
      - tux1968 10y ago
        Hadn't heard of Jade myself so your post inspired me to go looking. On http://learnjade.com/ http://learnjade.com/ the front page example shows that Jade doesn't take advantage of this ability to omit the closing </p> tag. So while I agree with you that html is not the best form for authors to write in, Jade itself still has room for improvement.
        city41 10y ago
        Would that be jade's job? I'd argue jade's job is to make writing html easier. Another tool should take on html optimization.
        tux1968 10y ago
        That is an option of course but then requires further processing by another tool. And Jade is often used real time which means that the need for further processing will be a burden. Is there any reason for the tool to output less than optimized code in the first place? What value is there in producing html that needs to be optimized by another tool? By the way, Jade is in the process of being renamed to Pug because of a naming conflict with someone who holds the rights to the Jade name in another context. https://pugjs.org https://pugjs.org
        roblabla 10y ago
        The value is that optimizing would make jade/pug's code more complicated, whereas a generic tool that minimizes html according to these rules would work on whatever preprocessing tool you use (PHP, ejs, erb, handlebars, pug) that spits out HTML. Do one thing and do it well, pretty much. EDIT: editting since I can't reply to child post. The thing is, if jade does it well on its own, then all the other tools won't profit from it. I believe jade should focus on outputting easy to understand, well-indented HTML. When debugging HTML problems (missing attributes or whatnot) in development, I always disable any kind of minifiers. If jade implements a minified output, it would need to be optional, further increasing complexity. If minification is a build step, I can just disable that step. Easy peasy.
RubyPinch 10y ago
> A p element's end tag may be omitted if the p element is immediately followed by block-ish element, or if there is no more content in the parent element. > This doesn't apply if you are doing weird stuff in a non-block-ish element, or a media element, or a custom element. is the easier way to think about it usually
- h1d 10y ago
  It's really just better to keep a closing p tag, so you don't have to care about consequence when you edit that part later... Does not type </p> save anything? No.
  - hellcow 10y ago
    It actually saves at least 4 bytes per closing tag. On a larger webpage, that could easily add up to saving hundreds or thousands of bytes per request. That's a significant savings, especially for mobile.
    - h1d 10y ago
      gzip makes it insignificant. I just took a sample page out of here which has bunch of p tags open and closed, gzipped the original and the one with </p> stripped, difference was 39 bytes. https://en.wikipedia.org/wiki/C_(programming_language) https://en.wikipedia.org/wiki/C_(programming_language)
      - emn13 10y ago
        Ironically, if end tags were truly non-optional, html might actually compress better, because it would have less entropy (less choices). In practice, it would allow for a compression filter to represent the tree structure in a less redundant form with fewer corner cases to deal with (much like compressors do for binaries, for example).
    - rhizome 10y ago
      Thousands? Over 250 p tags on a page?
tedmiston 10y ago
> This simply should be a build step This is a great point, but when I think of build steps, I think of something like minifying which comes with a performance gain. I'm not sure I see what the obvious gain to omitting optional tags in the way Google suggests is. Edit: To clarify, I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags.
- sotojuan 10y ago
  Less HTML to load? Probably makes no difference in most cases, but it is less to load. Many React/Webpack flows do something like this (minify or use a barebones template HTML).
  - bpicolo 10y ago
    Seems like something you can add a build step for though. Less human overhead
    - sotojuan 10y ago
      Sorry I wasn't very clear, that's what I meant by "React/Webpack" flow! See: https://github.com/ampedandwired/html-webpack-plugin https://github.com/ampedandwired/html-webpack-plugin
- rtpg 10y ago
  file size? It's not much, but it would still strip some stuff. I'm still bitter that HTML/XML works based off of explicit closing tags (where you can mistakenly close the wrong tag) instead of something like braces.
  - TheRealPomax 10y ago
    Use a build tool (which you should be doing anyway if you hand-write any markup, because you need to validate it) and make it rewrite </> to the relevant closing tag, if necessary... problem solved? (and yes, you'd be free to even leave </> off in many, many places: https://www.w3.org/TR/html5/syntax.html#optional-tags https://www.w3.org/TR/html5/syntax.html#optional-tags). Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.
Arnavion 10y ago
This reasoning is why I write all the web pages for my personal projects using XHTML. I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc. Everything's consistent in XHTML.
- nayuki 10y ago
  Agreed. Years ago I started doing all my projects in XHTML because I found that debugging silent HTML errors was not fun. Silent errors include things like malformed tags and attributes, incorrect nesting structure (thus also messing up where CSS rules are applied), and unescaped left-angles and ampersands.
  - prodigal_erik 10y ago
    This is why I've always advocated DTD-validation of HTML (which is shockingly underused).
    - icedchai 10y ago
      I've never actually seen anyone validate their HTML. If you suggested this in most companies, they would look at you like you had two heads.
      - luhn 10y ago
        I'm pretty sure Moz has HTML validator built into its SEO tool, so it may be more common than you think solely because of that. We validate HTML at my company—If we don't we'll hear about it next time our boss runs an SEO check,
      - intrasight 10y ago
        A good text editor will validated against the DTD as you type. And after you publish, you can use https://validator.w3.org/ https://validator.w3.org/
      - jimminy 10y ago
AgentME 10y ago
You already have to consider all of those cases about the <p> tag: because they auto close when they hit one of those elements, that means that <p> tags can't contain any of them. If you don't know about this while using <p> tags, you can be in for a world of fun mysterious issues.
- luhn 10y ago
  But all those tags are things that no sane developer would put inside a p tag anyways, so you don't really have to think about them. The real mental overhead is incurred when reasoning about the tag following the p, which could be anything. "Hmmm, I have a nav tag coming after this p tag. Does that implicitly close it?" Although if you had a good autoindenter, you could catch any mistakes by how it was indented. "Oh, that nav tag is on the same indentation level as the p tag, I guess it does implicitly close it."
  - tinco 10y ago
    I have done web dev on and off for over 15 years and I've never even thought about what happens when you put a h1 in a p. In my opinion the browser should crash and the operating system should BSOD. I have always been severely annoyed by the amount of shit browsers put up with. I don't understand why XHTML strict didn't get the traction it deserved and why they didn't continue along that line with HTML5.
    - sopooneo 10y ago
      Because the world is made up of messy people. And the value of allowing messy content was perceived as outweighing the value of consistency and reliability. I happen to agree.
  - AgentME 10y ago
    I ran into this when working on some software that put user comments in <p> tags. I added some allowed markup that came out as <div> tags for a collapsible section. It didn't strike me as a particularly insane feature, but I about lost my mind trying to figure out why the <div> tags appeared to negate the <p> tag styling for all of the text after it.
meerita 10y ago
I write HAML. It's confortable, resumed and strict. It outputs nice-formated HTML.
thinkloop 10y ago
It's possible/likely that's what they mean. However the final markup is generated, make it minimal, shout-out to react, packagers, minifiers, etc

by kgtm 10y ago

userbinator 10y ago

but I think in general it is a mistake to make developers think about when and where certain things can be omitted. Yes, sometimes it is better to make developers think about when and where certain things are required.

nchelluri 10y ago

I agree, but maybe a transformer step could do it automatically. Write full HTML, generate less.

h1d 10y ago
After 20 years of composing HTML, the world can do better than write full HTML but use technology like jade and not worry about what goes to the browser...
- CoryG89 10y ago
  Why not worry about what goes to the browser? In my eyes, what actually runs in the browser is the only thing that matters in the end. You could still write in something like Jade, transpiler, minify, then strip unneeded tags, all with automation.
  - h1d 10y ago
    I didn't mean not to care what goes to the brower, I meant if tools like jade does it right for us, the rest of us no longer have to care about those little details. Frankly I'm amazed the HTML way of verbose writing still stands after all these years in a fast paced industry.
    - tux1968 10y ago
      Hadn't heard of Jade myself so your post inspired me to go looking. On http://learnjade.com/ http://learnjade.com/ the front page example shows that Jade doesn't take advantage of this ability to omit the closing </p> tag. So while I agree with you that html is not the best form for authors to write in, Jade itself still has room for improvement.
      - city41 10y ago
        Would that be jade's job? I'd argue jade's job is to make writing html easier. Another tool should take on html optimization.
        tux1968 10y ago
        That is an option of course but then requires further processing by another tool. And Jade is often used real time which means that the need for further processing will be a burden. Is there any reason for the tool to output less than optimized code in the first place? What value is there in producing html that needs to be optimized by another tool? By the way, Jade is in the process of being renamed to Pug because of a naming conflict with someone who holds the rights to the Jade name in another context. https://pugjs.org https://pugjs.org
        roblabla 10y ago
        The value is that optimizing would make jade/pug's code more complicated, whereas a generic tool that minimizes html according to these rules would work on whatever preprocessing tool you use (PHP, ejs, erb, handlebars, pug) that spits out HTML. Do one thing and do it well, pretty much. EDIT: editting since I can't reply to child post. The thing is, if jade does it well on its own, then all the other tools won't profit from it. I believe jade should focus on outputting easy to understand, well-indented HTML. When debugging HTML problems (missing attributes or whatnot) in development, I always disable any kind of minifiers. If jade implements a minified output, it would need to be optional, further increasing complexity. If minification is a build step, I can just disable that step. Easy peasy.

RubyPinch 10y ago

> A p element's end tag may be omitted if the p element is immediately followed by block-ish element, or if there is no more content in the parent element. > This doesn't apply if you are doing weird stuff in a non-block-ish element, or a media element, or a custom element. is the easier way to think about it usually

h1d 10y ago
It's really just better to keep a closing p tag, so you don't have to care about consequence when you edit that part later... Does not type </p> save anything? No.
- hellcow 10y ago
  It actually saves at least 4 bytes per closing tag. On a larger webpage, that could easily add up to saving hundreds or thousands of bytes per request. That's a significant savings, especially for mobile.
  - h1d 10y ago
    gzip makes it insignificant. I just took a sample page out of here which has bunch of p tags open and closed, gzipped the original and the one with </p> stripped, difference was 39 bytes. https://en.wikipedia.org/wiki/C_(programming_language) https://en.wikipedia.org/wiki/C_(programming_language)
    - emn13 10y ago
      Ironically, if end tags were truly non-optional, html might actually compress better, because it would have less entropy (less choices). In practice, it would allow for a compression filter to represent the tree structure in a less redundant form with fewer corner cases to deal with (much like compressors do for binaries, for example).
  - rhizome 10y ago
    Thousands? Over 250 p tags on a page?

tedmiston 10y ago

> This simply should be a build step This is a great point, but when I think of build steps, I think of something like minifying which comes with a performance gain. I'm not sure I see what the obvious gain to omitting optional tags in the way Google suggests is. Edit: To clarify, I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags.

sotojuan 10y ago
Less HTML to load? Probably makes no difference in most cases, but it is less to load. Many React/Webpack flows do something like this (minify or use a barebones template HTML).
- bpicolo 10y ago
  Seems like something you can add a build step for though. Less human overhead
  - sotojuan 10y ago
    Sorry I wasn't very clear, that's what I meant by "React/Webpack" flow! See: https://github.com/ampedandwired/html-webpack-plugin https://github.com/ampedandwired/html-webpack-plugin
rtpg 10y ago
file size? It's not much, but it would still strip some stuff. I'm still bitter that HTML/XML works based off of explicit closing tags (where you can mistakenly close the wrong tag) instead of something like braces.
- TheRealPomax 10y ago
  Use a build tool (which you should be doing anyway if you hand-write any markup, because you need to validate it) and make it rewrite </> to the relevant closing tag, if necessary... problem solved? (and yes, you'd be free to even leave </> off in many, many places: https://www.w3.org/TR/html5/syntax.html#optional-tags https://www.w3.org/TR/html5/syntax.html#optional-tags). Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.

Arnavion 10y ago

This reasoning is why I write all the web pages for my personal projects using XHTML. I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc. Everything's consistent in XHTML.

nayuki 10y ago
Agreed. Years ago I started doing all my projects in XHTML because I found that debugging silent HTML errors was not fun. Silent errors include things like malformed tags and attributes, incorrect nesting structure (thus also messing up where CSS rules are applied), and unescaped left-angles and ampersands.
- prodigal_erik 10y ago
  This is why I've always advocated DTD-validation of HTML (which is shockingly underused).
  - icedchai 10y ago
    I've never actually seen anyone validate their HTML. If you suggested this in most companies, they would look at you like you had two heads.
    - luhn 10y ago
      I'm pretty sure Moz has HTML validator built into its SEO tool, so it may be more common than you think solely because of that. We validate HTML at my company—If we don't we'll hear about it next time our boss runs an SEO check,
    - intrasight 10y ago
      A good text editor will validated against the DTD as you type. And after you publish, you can use https://validator.w3.org/ https://validator.w3.org/
    - jimminy 10y ago

AgentME 10y ago

You already have to consider all of those cases about the <p> tag: because they auto close when they hit one of those elements, that means that <p> tags can't contain any of them. If you don't know about this while using <p> tags, you can be in for a world of fun mysterious issues.

luhn 10y ago
But all those tags are things that no sane developer would put inside a p tag anyways, so you don't really have to think about them. The real mental overhead is incurred when reasoning about the tag following the p, which could be anything. "Hmmm, I have a nav tag coming after this p tag. Does that implicitly close it?" Although if you had a good autoindenter, you could catch any mistakes by how it was indented. "Oh, that nav tag is on the same indentation level as the p tag, I guess it does implicitly close it."
- tinco 10y ago
  I have done web dev on and off for over 15 years and I've never even thought about what happens when you put a h1 in a p. In my opinion the browser should crash and the operating system should BSOD. I have always been severely annoyed by the amount of shit browsers put up with. I don't understand why XHTML strict didn't get the traction it deserved and why they didn't continue along that line with HTML5.
  - sopooneo 10y ago
    Because the world is made up of messy people. And the value of allowing messy content was perceived as outweighing the value of consistency and reliability. I happen to agree.
- AgentME 10y ago
  I ran into this when working on some software that put user comments in <p> tags. I added some allowed markup that came out as <div> tags for a collapsible section. It didn't strike me as a particularly insane feature, but I about lost my mind trying to figure out why the <div> tags appeared to negate the <p> tag styling for all of the text after it.

meerita 10y ago

I write HAML. It's confortable, resumed and strict. It outputs nice-formated HTML.

thinkloop 10y ago

It's possible/likely that's what they mean. However the final markup is generated, make it minimal, shout-out to react, packagers, minifiers, etc