Hacker News Reader

Hacker News

Comment by assimpleaspossi | Hacker News Reader

Parent Full thread

assimpleaspossi

Note: the <input> tag does not use and does not need a closing slash and never has in any HTML specification.

https://html.spec.whatwg.org/dev/input.html#the-input-elemen...

View on HN

It's sometimes done to make the same markup compatible with XHTML, without harming its interpretation in HTML.

You are either running XHTML or you are not. No need to carry any compatibility overhead. I doubt he is serving XHTML.

I personally prefer <input /> if only to stop other developers to not try doing <input>content </input>.

There are other tags you can omit the closing tag but yet the opening tag shouldn’t be self-closed.

  <ol>
    <li>one
    <li>two
  </ol>

I think even the final closing ol can be omitted as there are rules to auto close elements when encountering tags that don’t make sense in context.

I know that, but many developers don't. I can't wait to see the confusion on why my tag didn't auto-close like a <li> tag.

Ambiguity can be a dangerous thing, and not closing HTML tags can be a cause of that in my experience.

The term for such "other developers" is "hobbyists".

There are other terms but I won't list them here.

Sometimes "other developers" is also "coworkers".

I've found less ambiguity to be a better thing than not, where possible. Self-closing a tag that can't contain anything is one such example of removing ambiguity for "hobbyists".

One would need to know the tag is self-closing in order to put the closing slash in. Right? So if one knows it's self-closing already, why do they need to add the extra weight?

Makes no sense.

If one wants to add content to a self-closing element, one has far more problems than we're talking about here.

> If one wants to add content to a self-closing element, one has far more problems than we're talking about here.

Yes.

It can be done by libraries, for example, which want their output to be valid in both HTML and XHTML.

Note that's it's not a syntax error in HTML - because HTML doesn't have syntax errors. The HTML5 spec tried to codify all the weird Postel's law quirks of existing HTML4 parsers, and in this case, tells you how to ignore the extra / if you're a parser. Nothing is a syntax error.

I didn't say it's a syntax error. I said it is not specified in the standard. You can put the slash there but it has no meaning, it does nothing, and browsers ignore it. If anything, it can cause problems: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...

So it's best to not do it altogether. If one thinks they need to be compliant with both HTML and XHTML, I'd bet they have far more problems with the rest of their markup that would fail at such an effort.

Reply on news.ycombinator.com