6 ms·

Frontend developer here -- Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not expl

Frontend developer here -- Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not explicitly closing dom nodes would lead to confusion. You would also need to concern yourself with the "certain conditions" that must be met for it to work. Consistency and clarity over brevity!

majormjr 6y ago
Especially with HTML as it's going to get minimized and hacked up to reduce the filesize. Including the closing tags makes the transpilers job easier and less error prone.
- susam 6y ago
  A transpiler that gets confused when optional tags are missing (a feature explicitly allowed by the spec) is a broken transpiler and it needs to be fixed. This is like the automatic semicolon insertion of JavaScript debate[1][2] all over again. These things are spelled out in the standards and tools that do not adhere to the standards are broken. [1] https://web.archive.org/web/20201206065632/http://inimino.org/~inimino/blog/javascript_semicolons https://web.archive.org/web/20201206065632/http://inimino.or... [2] https://blog.izs.me/2010/12/an-open-letter-to-javascript-leaders-regarding https://blog.izs.me/2010/12/an-open-letter-to-javascript-lea...
  - still_grokking 6y ago
    Yeah, fine. The tool is broken. Right. But YOU have still an issue. The Point is: There a lot of broken tools out there, and you can't know which of them will be used in the future. Just avoid a lot of headaches for your future self and your colleges by not testing out the spec-compliance of all those tools you'll probably use at some point.
    - deleted 6y ago
      [deleted]
    - susam 6y ago
      > But YOU have still an issue. I disagree. > There a lot of broken tools out there A tool that incorrectly handles optional tags may handle other parts of the spec incorrectly too. Such a tool may provide incorrect results for even perfectly well-written HTML. There is no know what it takes to make all the broken parsers out there happy. I know you made a point about ETL tools[1] where XML parsers are used to parse HTML but there is no way to cater to such absurd use cases anyway. Using an XML parser to parse HTML5 is not going to work correctly anyway even if you do retain the optional tags because it would fail on other HTML5 tags that do not have closing tags such as <meta>, <link>, <img>, etc., empty attributes like <input disabled>, <input required>, etc. Web developers from all around the world are not going to start writing self-closing <img /> tags just because these broken ETL tools have decided to use an XML parser to parse HTML5. There are plenty of good HTML5 parsers out there for almost every mainstream programming language. Just use them. [1] https://news.ycombinator.com/item?id=25708209 https://news.ycombinator.com/item?id=25708209
      - still_grokking 6y ago
        Most of the "plenty of good HTML5 parsers out there" are broken. No wonder as the spec is nuts. (It took years before there was even a correctly working validator). Also I was explicitly talking about XML compatible HTML. It's called so because it's XML compatible. Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)
        susam 6y ago
        > Most of the "plenty of good HTML5 parsers out there" are broken. Can you name a few popular and widely used HTML5 parsers that are broken and tell us what the bugs are in those parsers? I would be surprised if you can find or name even two such parsers that are popular but cannot handle optional tags correctly as required by the spec. > Also I was explicitly talking about XML compatible HTML. There is no such thing as XML compatible HTML (unless you mean XHTML which we are not discussing here). Maybe you mean XML-serialized HTML5. I can only guess since the terminology you are using is vague and unclear. In any case, HTML5 by itself is incompatible with XML. I mentioned this in my previous comment. Not all tags in HTML5 are self-closing, thus incompatible with XML. XML-serialized HTML5 is however compatible with XML, by definition, and in that case, one would use an XML parser, not an HTML5 parser. More importantly, you can safely omit the optional tags and still convert your HTML5 document into XML-serialized HTML5 document without any issues whatsoever. This was explained to you by anjbe here at https://news.ycombinator.com/item?id=25706163 https://news.ycombinator.com/item?id=25706163. He is absolutely right. > Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-) You see all the tags there because it shows the entire DOM. The browser automatically creates the elements when optional tags are not explicitly present in the HTML. This is all spelled out in the spec very clearly. Any HTML5 parser worth its name follows the spec. I am not sure what your point is here. See https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-... for details, especially: "Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup." I hope that explains why you always see the elements for the optional tags in a web browser's developer tools.
- toast0 6y ago
  The minimizer should output HTML without unneccesary tags, and it should probably expect to run on its own output, so I don't see why adding unneccesary tags would help it work.
susam 6y ago
I am not a frontend developer. I agree with you. I write my blog posts with handwritten HTML because that is how I began writing blog posts many years ago when Markdown was not as popular as it is now. Indeed I never omit any optional tags while writing my blog posts or blog layout. I am not necessarily recommending that one should omit the optional tags. However, it is worth noting that the option to do so while conforming to the HTML5 spec is there. The "certain conditions" are not really much to worry about. I think they are drafted quite carefully and are quite sensible. If one is writing simple HTML documents, say, for blog posts, text-based articles, etc. one can safely omit the optional tags without running into issues due to the "certain conditions".
- anjbe 6y ago
  > Indeed I never omit any optional tags while writing my blog posts or blog layout. Do you type <tbody> every time you write a table? That is an optional implicit tag that can be left out just like <html>, <head>, and <body>.
  - susam 6y ago
    I don't type <thead> and <tbody>. I believe that's an exception to the practice of never omitting optional tags. Maybe there are a few more exceptions like that but none that I can remember right now. Thanks for posting this comment. It made me realize that my previous claim was inaccurate.
chrismorgan 6y ago
I write plenty of HTML by hand, for myself. I prefer to omit things like </p>, </li>, </td> and </tr>, because it takes less effort (and I hate text editor plugins that automatically add closing delimiters of any form, because they always do the wrong thing a meaningful fraction of the time in a way that I have to think about, more than if I just type the delimiters myself, though an accurate “insert at the cursor whatever is needed to close the last thing” shortcut might be handy), and reduces visual noise. I also normally omit quotes on attribute values if correct to do so. I mostly do these things when working on things of my own, when I know no one else needs to worry about them. When working on things others will touch, I don’t drop quite as many closing tags, and will normally leave attribute values quoted.
- alpaca128 6y ago
  > I hate text editor plugins that automatically add closing delimiters Glad I'm not the only one. The less an editor does automatically to "help" me the better. I agree, a shortcut to close the last opening syntax element would be nice, but for this to work properly the editor needs to be aware of how all the syntax elements interact, e.g. to differentiate between '<' used in a logical comparison and the same symbol as start of an XML tag. Or to correctly close an XML tag no matter if it has attributes. I have a shortcut in Vim for three different kinds of brackets but it's a bit janky. Still better than the automatic stuff the typical IDE and modern editor does without asking, though.
breck 6y ago
The man who collects rocks in his pockets eventually drowns.
edflsafoiewq 6y ago
> You would also need to concern yourself with the "certain conditions" that must be met for it to work. You have to concern yourself with them anyway. If you do something that automatically closes an element, it's automatically closed at that point whether you put a close tag somewhere later on (that will be ignored) or not. This is like semicolon insertion in JS: the fact you're using semicolons does not mean you can ignore the rules for how they're inserted.

majormjr 6y ago

Especially with HTML as it's going to get minimized and hacked up to reduce the filesize. Including the closing tags makes the transpilers job easier and less error prone.

susam 6y ago
A transpiler that gets confused when optional tags are missing (a feature explicitly allowed by the spec) is a broken transpiler and it needs to be fixed. This is like the automatic semicolon insertion of JavaScript debate[1][2] all over again. These things are spelled out in the standards and tools that do not adhere to the standards are broken. [1] https://web.archive.org/web/20201206065632/http://inimino.org/~inimino/blog/javascript_semicolons https://web.archive.org/web/20201206065632/http://inimino.or... [2] https://blog.izs.me/2010/12/an-open-letter-to-javascript-leaders-regarding https://blog.izs.me/2010/12/an-open-letter-to-javascript-lea...
- still_grokking 6y ago
  Yeah, fine. The tool is broken. Right. But YOU have still an issue. The Point is: There a lot of broken tools out there, and you can't know which of them will be used in the future. Just avoid a lot of headaches for your future self and your colleges by not testing out the spec-compliance of all those tools you'll probably use at some point.
  - deleted 6y ago
    [deleted]
  - susam 6y ago
    > But YOU have still an issue. I disagree. > There a lot of broken tools out there A tool that incorrectly handles optional tags may handle other parts of the spec incorrectly too. Such a tool may provide incorrect results for even perfectly well-written HTML. There is no know what it takes to make all the broken parsers out there happy. I know you made a point about ETL tools[1] where XML parsers are used to parse HTML but there is no way to cater to such absurd use cases anyway. Using an XML parser to parse HTML5 is not going to work correctly anyway even if you do retain the optional tags because it would fail on other HTML5 tags that do not have closing tags such as <meta>, <link>, <img>, etc., empty attributes like <input disabled>, <input required>, etc. Web developers from all around the world are not going to start writing self-closing <img /> tags just because these broken ETL tools have decided to use an XML parser to parse HTML5. There are plenty of good HTML5 parsers out there for almost every mainstream programming language. Just use them. [1] https://news.ycombinator.com/item?id=25708209 https://news.ycombinator.com/item?id=25708209
    - still_grokking 6y ago
      Most of the "plenty of good HTML5 parsers out there" are broken. No wonder as the spec is nuts. (It took years before there was even a correctly working validator). Also I was explicitly talking about XML compatible HTML. It's called so because it's XML compatible. Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)
      - susam 6y ago
        > Most of the "plenty of good HTML5 parsers out there" are broken. Can you name a few popular and widely used HTML5 parsers that are broken and tell us what the bugs are in those parsers? I would be surprised if you can find or name even two such parsers that are popular but cannot handle optional tags correctly as required by the spec. > Also I was explicitly talking about XML compatible HTML. There is no such thing as XML compatible HTML (unless you mean XHTML which we are not discussing here). Maybe you mean XML-serialized HTML5. I can only guess since the terminology you are using is vague and unclear. In any case, HTML5 by itself is incompatible with XML. I mentioned this in my previous comment. Not all tags in HTML5 are self-closing, thus incompatible with XML. XML-serialized HTML5 is however compatible with XML, by definition, and in that case, one would use an XML parser, not an HTML5 parser. More importantly, you can safely omit the optional tags and still convert your HTML5 document into XML-serialized HTML5 document without any issues whatsoever. This was explained to you by anjbe here at https://news.ycombinator.com/item?id=25706163 https://news.ycombinator.com/item?id=25706163. He is absolutely right. > Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-) You see all the tags there because it shows the entire DOM. The browser automatically creates the elements when optional tags are not explicitly present in the HTML. This is all spelled out in the spec very clearly. Any HTML5 parser worth its name follows the spec. I am not sure what your point is here. See https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-... for details, especially: "Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup." I hope that explains why you always see the elements for the optional tags in a web browser's developer tools.
toast0 6y ago
The minimizer should output HTML without unneccesary tags, and it should probably expect to run on its own output, so I don't see why adding unneccesary tags would help it work.

susam 6y ago

I am not a frontend developer. I agree with you. I write my blog posts with handwritten HTML because that is how I began writing blog posts many years ago when Markdown was not as popular as it is now. Indeed I never omit any optional tags while writing my blog posts or blog layout. I am not necessarily recommending that one should omit the optional tags. However, it is worth noting that the option to do so while conforming to the HTML5 spec is there. The "certain conditions" are not really much to worry about. I think they are drafted quite carefully and are quite sensible. If one is writing simple HTML documents, say, for blog posts, text-based articles, etc. one can safely omit the optional tags without running into issues due to the "certain conditions".

anjbe 6y ago
> Indeed I never omit any optional tags while writing my blog posts or blog layout. Do you type <tbody> every time you write a table? That is an optional implicit tag that can be left out just like <html>, <head>, and <body>.
- susam 6y ago
  I don't type <thead> and <tbody>. I believe that's an exception to the practice of never omitting optional tags. Maybe there are a few more exceptions like that but none that I can remember right now. Thanks for posting this comment. It made me realize that my previous claim was inaccurate.

chrismorgan 6y ago

I write plenty of HTML by hand, for myself. I prefer to omit things like </p>, </li>, </td> and </tr>, because it takes less effort (and I hate text editor plugins that automatically add closing delimiters of any form, because they always do the wrong thing a meaningful fraction of the time in a way that I have to think about, more than if I just type the delimiters myself, though an accurate “insert at the cursor whatever is needed to close the last thing” shortcut might be handy), and reduces visual noise. I also normally omit quotes on attribute values if correct to do so. I mostly do these things when working on things of my own, when I know no one else needs to worry about them. When working on things others will touch, I don’t drop quite as many closing tags, and will normally leave attribute values quoted.

alpaca128 6y ago
> I hate text editor plugins that automatically add closing delimiters Glad I'm not the only one. The less an editor does automatically to "help" me the better. I agree, a shortcut to close the last opening syntax element would be nice, but for this to work properly the editor needs to be aware of how all the syntax elements interact, e.g. to differentiate between '<' used in a logical comparison and the same symbol as start of an XML tag. Or to correctly close an XML tag no matter if it has attributes. I have a shortcut in Vim for three different kinds of brackets but it's a bit janky. Still better than the automatic stuff the typical IDE and modern editor does without asking, though.

breck 6y ago

The man who collects rocks in his pockets eventually drowns.

edflsafoiewq 6y ago

> You would also need to concern yourself with the "certain conditions" that must be met for it to work. You have to concern yourself with them anyway. If you do something that automatically closes an element, it's automatically closed at that point whether you put a close tag somewhere later on (that will be ignored) or not. This is like semicolon insertion in JS: the fact you're using semicolons does not mean you can ignore the rules for how they're inserted.