3 ms·

Point of fairly idle curiosity about the presentation of the article: why do you put a trailing slash on your empty elements (img, link) in your code samples?

• EE84M3i 5y ago
  For me, I write the trailing slash because it's easier for me to reason about mentally. It also means I don't have to context switch if I'm writing JSX or XML instead of HTML.
• srgpqt 5y ago
  For me, adding the ending slash is just like adding semicolons at the end of javascript statements. They may be optional sometimes, but there is something to be said about consistency and clarity that comes with using them always. Less cognitive overload to boot.
  • kadoban 5y ago
    Aren't they optional 100% of the time though?
    • Waterluvian 5y ago
      Not 100%. There are a small handful of really wicked gotchas. I think there’s a lot of articles on them. I can’t find the one I like and don’t want to share one I haven’t read yet.
      • chrismorgan 5y ago
        Here’s an example in each direction. In this first example, ASI inserts an undesired semicolon: return {a: 0} This returns undefined, and doesn’t continue on to execute the block containing a statement 0 with label a. (Change it to {a: 0, b: 0} and you get a syntax error because of this reinterpretation of what was intended as an object literal.) In this second example, ASI doesn’t insert a desired semicolon: f() [].forEach.call(…) This becomes a syntax error, because the [] has become subscripting rather than an array literal. (Incidentally, [].forEach is smelly anyway; prefer Array.prototype.forEach, maybe assign that to a constant if you’re doing it much.)
        • runarberg 5y ago
          The second example could be replaced with something more common like: f() ['foo', 'bar'].forEach(...) Which is probably a type error, except if `f()` returns something like: function f() { return { bar: ['Not the array', 'you were expecting'], } } Then you would actually iterate over the returned `bar` array, not the expected `['foo', 'bar']` array. Another fairly likely example of a desired semicolon not inserted is when the following line starts with a template string literal: f() `This is tagged with whatever f() returns` This will most likely be a type error, except if `f()` returns a function, that function will then be called on the template string to do whatever. However I have a hard time imagining when you would want to start a statement with a template string literal without doing something smelly like: `some ${interpolated} string`.includes(someVar) ? sideEffectA() : sideEffectB()
• _ZeD_ 5y ago
  FWIW I personally find more readable a /> as "end of empty tag"
• radlad 5y ago
  I know it's not necessary, but I do it to distinguish to the reader whether they should expect a closing tag or not.
• jaffathecake 5y ago
  Author here! I used to have strong feelings about formatting stuff like this, but I since realised there are better things to spend effort on. For formatting, I just let https://prettier.io/ https://prettier.io/ do it's thing, and it added the />. Although I do configure it to use single quotes in JS, so I guess I still have some opinion there. In terms of HTML, how far does your "but it isn't necessary" opinion go? Lots of closing elements are unnecessary in HTML, for instance, check out the source of https://fetch.spec.whatwg.org/ https://fetch.spec.whatwg.org/
  • chrismorgan 5y ago
    Well, for my own personal stuff I omit just about all that I can—head/body start and end tags, html end tag (not start tag because it has at least a lang attribute), tbody start tag where possible, thead/tbody/tfoot/tr/th/td/li/dt/dd/p end tags almost all of the time, attribute value quotes where valid… mostly just because it’s fun doing so, and in some cases because it makes things decidedly cleaner (especially tables). I also don’t use autoformatters because I will often disagree with their opinions in specific cases. For stuff I’m working on with others, I’ll act more like a normal person, though I will still prefer to drop at least <head></head><body></body></html>, and I’ve never worked with anyone that wanted to put trailing slashes on void elements (and haven’t ever used Prettier on HTML, evidently). As for Prettier putting the trailing slash in: huh, that’s a really weird decision (and no flag for it!), given that they’re not emitting valid XML (not escaping >, at the least), so it’s just the personal preference thing, for something that was just added as an XHTML compatibility mechanism.
    • jaffathecake 5y ago
      Seems like your HTML formatting opinions are very similar to the owner of the fetch spec! Yeah, I don't always agree with Prettier, but ugh, I wasted hours in my early career arguing about formatting with teammates, but now I just let Prettier do it's thing, get over it, and spend the time on something else.
      • chrismorgan 5y ago
• AlbertoGP 5y ago
  > I can imagine some recommending it for XML compatibility (which is related to the original purpose of the ignore-the-trailing-slash behaviour, though slightly inverted in direction), but I don’t think I’ve ever encountered anyone saying so. Well, pleased to meet you! I do use it for XML compatibility: it allows me to use XML editor modes (usually nxml in Emacs) which, being simpler to implement as they don’t have to encode the rules of which tags close where, are more likely to be available and to work well. I’ve also done little customizations to nxml over the years, and this way I have them always there no matter whether I’m working with XML or HTML. And then occasionally I use other XML tools on it, such as xsltproc. You can still pipe the HTML through tidy to translate it (although xsltproc has --html, tidy has been more reliable), but having it compatible with XML does spare me small chores again and again.
  • chrismorgan 5y ago
    Yeah, that’s fair enough. In the past I was more likely to close tags like p/tr/td than I am now because the Vim indent file I was using for html didn’t handle some of those properly back then.