6 ms·

Note that closing </p> tags are optional†, so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this: <!

• cwackerfuss 6y ago
  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
  • 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.
• kubanczyk 6y ago
  > the opening <html> tag is optional too but I retained it in the above example to specify the lang > <html lang="en"> Yeah, no. The text is in Latin (la), not in English (en).
  • susam 6y ago
    ~Any references to support your claim?~ [Edit: I notice now that the content is indeed written in Latin. It contains the "Lorem Ipsum" placeholder text. Nice catch! :-)]
    • Natfan 6y ago
      To be fair, you did write your post in Latin: > Lorem ipsum dolor sit amet, consectetur adipiscing elit. > Duis id maximus tortor. Sed nisi ante, fermentum vel nunc > et, tincidunt sagittis magna. In ultrices commodo lacus, id > tristique ipsum euismod laoreet.
      • teekert 6y ago
        Hmm I always thought lorem ipsum was a text with letter usage histograms similar to English, without distracting the reader with meaning. I could have sworn I read that somewhere...
        • spijdar 6y ago
          Lorem ipsum is words/phrases copied from one of Cicero's writings, "De finibus bonorum et malorum". It's not a straight copy, kind of like if you copied every other word in places, but it's definitely Latin. It does likely have relatively similar usage patterns to English in terms of letter distribution, if only because they're both indo-european languages and English has deep vocabulary ties to Latin through Norman influences.
        • zwog 6y ago
          You are almost right: The distribution of letters and length of words is similar to that of the Latin language. But it is not Latin and the text does not make sense. It's gibberish.
• tannhaeuser 6y ago
  That's right, but it's probably more interesting that HTML 5 simply hard-coded these rules based on the tag inference features of SGML and the particular per-element tag omission indicators of HTML 4 and earlier SGML DTDs for HTML (see links on how head and body elements in your example document are inferred by SGML in detail). [1]: https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9RgUcEmbXmI6RolisQaIRw9dm&index=10&t=1831s https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R... [2]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html (the "Talk" link for slides)
• chrismorgan 6y ago
  And since we’re talking about optional things: <link rel="stylesheet" href="/style.css" /> <meta name="viewport" content="initial-scale = 1.0,maximum-scale = 1.0" /> Trailing slashes on HTML tags are useless. They’re allowed on void elements, for XML compatibility, but are by definition simply ignored. I recommend against including them, because they’re simple visual noise, and misleading because they don’t actually close tags—you can only use them on on elements that are defined as having no children. (Note that I say HTML tags; on foreign elements—meaning inline SVG and MathML—trailing slashes do make tags self-closing, XML-style.) Also since I’m writing, that viewport declaration is wonky. It should have device-width, and it should not have maximum-scale which is user-unfriendly. All up: <link rel="stylesheet" href="/style.css"> <meta name="viewport" content="device-width,initial-scale=1"> And for completeness, https://html.spec.whatwg.org/multipage/syntax.html#elements-2 https://html.spec.whatwg.org/multipage/syntax.html#elements-... defines void and foreign elements.
  • cxr 6y ago
    They're optional in the same way that braces around single-statement "if" clauses are optional in most curly brace languages—and indentation, for that matter—i.e. they still serve a purpose for many humans who are going to be tasked with upkeep and will choose to include them for personal reasons. Not every decision is rooted in trying to satisfy the machine. But speaking of machines, on that note... If you ever have to write any tooling for HTML processing, you'll realize that they can be useful for machines, too. If your team doesn't make use of any of these "features" that trigger corner cases in the spec, then you can adopt an XML-like parsing strategy (where these aren't optional) and your parser can be simpler than if you were to implement the entirety of the HTML5 parsing algorithm. You don't need any notion of void elements, and your parser doesn't need hardcoded lists of which elements are among them. You can write a "dumb" parser that can derive the node structure without needing any intimate knowledge of HTML. It's like the difference between parsing S-expressions and parsing an ALGOL-like language.
    • chrismorgan 6y ago
      I do think there’s an important difference from the optionality of curly braces on if statements in many languages: syntax highlighting will normally make it very obvious what is attribute name and what is attribute value, so that any error will be obvious, more obvious than the probable incorrectness of something like `if (a) b; c;` on one line. Your point on HTML processing is a nice idea, but quite useless in practice for HTML. XHTML failed: people didn’t want to go to the effort of getting it all rigorously correct; they rather wanted the browser to guess what they meant, because it got their intent right most of the time, and now they could forget about various details like tbody elements and trailing slashes. I regularly look at page sources, and I regularly encounter people putting these trailing slashes on various void element; but I can’t remember when I last found a page that actually applied that consistently—invariably they have at least one void element without a trailing slash. My conclusion is that the whole thing is misguided. I would be curious to see the result of attempting to parse all the HTML in something like Common Crawl with an XML parser. I suspect that barely any pages would succeed. The fact of the matter is that the HTML parsing algorithm is well-defined and very nuanced, so if you’re processing HTML you should use a real HTML parser, and to do anything else is folly—unless you are assiduous about maintaining XML correctness, which you can do, but it’ll be even more of a footgun for others than omitting quotes on attribute values. But if you’re writing something new, then by all means, strongly consider the comparatively simple and principled XML philosophy over the organic and complicated philosophies of the HTML serialisation.
• fsiefken 6y ago
  It would be valid, but wouldn't Google penalize it for being poor html?
  • rbanffy 6y ago
    If it doesn't, it should. It makes the life of parsers a lot harder.
  • anjbe 6y ago
    Under what definition is leaving off optional closing tags “poor html”? It is perfectly valid, part of the spec, very widely used, and completely unambiguous.
• galaxyLogic 6y ago
  This is great point. Doesn't it mean that "markdown" is kind of redundant ?
• still_grokking 6y ago
  Please never ever break XML compatibility! Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling. Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.
  • gmfawcett 6y ago
    Only one branch of the HTML family tree was ever XML compatible. I was a heavy user of XHTML in the day, so I'm sympathetic... But it's misleading to characterize non-XML variants of HTML as questionable shortcuts.
    • chrismorgan 6y ago
      Strictly speaking, HTML is still XML-compatible—the XML serialisation is still a thing, though pretty rare these days. But yeah, the HTML serialisation is not XML-compatible, though you can easily write documents that will be parsed identically by the XML and HTML parsers.
  • hombre_fatal 6y ago
    You don’t seem to realize that your post only applies to xhtml doctypes and your concern is extremely outdated to boot. Use an html parser to parse html. You also are extremely off on your estimation of how common xhtml is on the web since you thought this would be a useful PSA and you seem unaware of what <!doctype html> means here, as it specifically is not xml. I’m not tying to be mean, but you came in with guns blazing with weird advice and it seems very mislead.
    • chrismorgan 6y ago
      Note that the XML serialisation of HTML is still a thing—if you open a .xhtml file or navigate to something served with the content-type application/xhxml+xml, the XML parser will be used instead of the HTML parser.
  • 6y ago
• simonebrunozzi 6y ago
  > † These tags Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
  • flobosg 6y ago
    The dagger (the typographic name of that symbol) is usually employed as a footnote indicator if an asterisk is already present.