• azertyfun@sh.itjust.works
      link
      fedilink
      arrow-up
      19
      arrow-down
      1
      ·
      4 months ago

      > Clicks on <br>
      > Example is <br />


      The actual thing that matters is that the / is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing /. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.

      • traches@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        12
        ·
        edit-2
        4 months ago

        It’s not extrapolation on my part, the HTML spec is pretty direct about it:

        1. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/), which on foreign elements marks the start tag as self-closing. On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.

        https://html.spec.whatwg.org/multipage/syntax.html#start-tags

        I don’t think it’s an extrapolation to say that code which is “unnecessary and has no effect of any kind” should be omitted.

        And yeah, I linked the MDN docs because they’re easier to read but if they disagree then obviously the spec is the correct one.

        • azertyfun@sh.itjust.works
          link
          fedilink
          arrow-up
          7
          arrow-down
          1
          ·
          edit-2
          4 months ago

          To be annoyingly nitpicky, how is “unnecessary” defined in this context? Whitespace is usually “unnecessary” but I quite like it for readability.

          I broadly agree with you though, the W3C spec changes things.

      • lseif@sopuli.xyz
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        4 months ago

        An explanation of this problem can be found on the official W3C HTML validator wiki.

        HTML parsers only allow this to stop pages breaking when developers make mistakes; see this Computerphile video. ‘Able to be parsed correctly’ is not the soul criterion for it a syntax being preferred, otherwise we would all leave our <p> elements unclosed.

        Yes, it is not “incorrect” to write <br/>, but it is widely considered bad practice. For one, it makes it inconsistent with XML. Linters will often even “correct” this for you.

        I personally find the official style (<br>) to be more readable, but this is a matter of personal opinion. Oh, and I used to have the same stance as you, but I also used to think that Python’s whitespace-based syntax was superior…

        At the end of the day, regardless of anyone’s opinion, we should come to SOME consensus…and considering that W3C already endorses <br>, we should use this style.

        • Ethan@programming.dev
          link
          fedilink
          English
          arrow-up
          3
          arrow-down
          1
          ·
          4 months ago

          If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.

          • lseif@sopuli.xyz
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            “readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.

            if you want to use <br/> in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.

            • Ethan@programming.dev
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              4 months ago

              if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.

              That goes without saying; I’m not a barbarian.

              “readability” is subjective. much like how there is no objective definition of “clean code”.

              Did you not see the part where I said it’s less readable “in my opinion”?

              i am insisting that people use a common standard regardless of your opinion on it.

              I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.

              The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.

      • dukk@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        Trailing slash lets you do this though:

        For example, in the case of <div/>Some text, browsers interpret this as <div>Some text</div>, treating the slash as ignored and considering the div element to encapsulate the text that follows.

        • KairuByte@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          5
          ·
          4 months ago

          This is terrible.

          You should never rely on a browser interpreting a non standard use in a specific way. It can change at any moment, and wouldn’t be reliably reversed because it’s inherently non standard.

    • lad@programming.dev
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      4 months ago

      TIL. Funny thing, though, is that they give an example of how to use <br> and have it with trailing slashes. And then explain that trailing or preceding slash will be ignored, anyway ¯\_(ツ)_/¯