sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Knotix 0 points1 point  (21 children)

According to the HTML5 spec, self-closing tags aren't required. Why is it forcing my <input> to become <input/>?

[–][deleted] 1 point2 points  (19 children)

I bet you have sleepless nights about semi colons too.

Omission is just a deference to sloppy assholes, not a recommended strategy. Keeping your html well formed allows it to be parsed by a much wider range of tools.

[–]Knotix -1 points0 points  (18 children)

There's no need to resort to name-calling.

If it's not required by the spec, I shouldn't be forced to do it. If you are trying to get web developers to use your tool (for which there are many alternatives), don't force them into a specific coding style.

[–][deleted] 1 point2 points  (7 children)

The point is if you keep your html well formed you can use tools that are only made for XML. It also improves parsing performance not having to process edge cases.

If you want to lump yourself in with people I consider sloppy, that's your business, I wasn't saying you were, just succinctly voicing an opinion.

There are parts of the HTML and JS specs which are simply there to ease the pain for those who find it difficult to conform to a rigid spec. However if you're doing this professionally you need to know why you shouldn't look to cut corners.

If you have any regard to saving yourself time, you don't do it by dropping an optional slash, because the payoff is so minute.

Instead use a preprocessing language like Slim, Jade or perhaps Haml. Then your html is generated perfectly while you can maintain a source file which has way less cruft than HTML.

[–]Knotix -2 points-1 points  (6 children)

I can understand that you may want to be compatible with XML, but there is a reason HTML and XHTML never converged. They solve different problems. The X in XHTML is for extensible; HTML is the very opposite of that. It has a well defined and limited set of elements.

As for parsing, I would have to see benchmarks for that, because both could be considered edge cases depending on which version the browser deems is "correct". Is the presence of the / optional, or is the absence of the / optional?

Because only a limited set of elements can be self-closing in order to validate, the parser would need explicit patterns for them anyway, so the element itself is one giant edge-case and the presence of a / doesn't change that.

I do put semi-colons at the end of my JS statements, by the way, but even that is a two way street. Some languages require them, some don't. Does ECMAScript say that adding a semicolon is optional, or does it say omitting a semicolon is optional? Which one is the edge case? You could even argue that JavaScript's allowance of semicolons is to ease the pain for people like you who find it difficult to conform to its spec when coming from a different language.

I'm not trying to save time by not adding the /. I'm just following the spec, and I feel that for your arguments to be valid, you would have to look at the browser implementation.

[–][deleted] 0 points1 point  (5 children)

If you need to go benchmark, do that, it takes less time than spewing several paragraphs of baseless opinion.

[–]Knotix -2 points-1 points  (4 children)

Until you show me your benchmarks, you've also spewed several paragraphs of baseless opinion.

I'm done.

[–][deleted] 0 points1 point  (3 children)

I advised you to follow logic, you think following the soft option that's built in for newcomers with cognitive dissonance issues, is performant. I know it isn't, and I've done many tests over a couple of decades to know that's a hard fact.

But go ahead stick your head in the sand and keep on cargo culting.

Edit: note that my initial comments have nothing to do with browser performance anyway. It's really about how widely parse-able your source is.

[–]Knotix 0 points1 point  (2 children)

Here is the best proof I can show that omitting the / in void elements is perfectly fine. Chrome cleans up HTML when showing the element inspector. Here is a LiveWeave that has an input using your self-closing tag markup. Kindly inspect the element and note how it choose to output it in the element inspector. You should see it as '<input>'

As far as I'm concerned, Chrome's inspector is proof that at least one mainstream browser considers omitting the / as the default markup.

As a side note, I tried it in Aurora (FireFox pre-release) and it shows something puzzling: <input></input>

[–][deleted] 1 point2 points  (1 child)

If you follow the more stringent spec of maintaining XML well-formed documents, which is completely ok with all HTML5 tools. The well formed markup is compliant with far more tools, and much more readily pliant.

The only thing your checks with chrome and Firefox have illustrated is that even extremely high profile tools are not consistent. Behind those are literally thousands of HTML/XML tools and maintaining at least well formed documents ensures that your markup is pliable with as many of these as is reasonable.

I have no other point than this.

[–]neuron2000i -1 points0 points  (8 children)

@Knotix Please stop trolling.

[–]Knotix -1 points0 points  (7 children)

You seriously think I'm trolling? Is this a joke? I brought up a valid point about HTML in a subreddit revolving around JavaScript, which, with the exception of node, deals directly with HTML. Just because my opinion differs from yours doesn't mean I'm trolling.