That closing slash was never really required. Sure your xhtml won't validate, but it probably wasn't going to anyway. xhtml was recommended in my formative years and I never really broke that habit. I still think input, img, br 'look better' this way. If I am not mistaken, it's not even that it's wrong. I suppose it's a waste of bytes though.
And even if you have XHTML doctype but do not server your document with XHTML MIME type browsers will treat it as HTML.
So all "liking" to use XHTML syntax in HTML were just lucky that no mainstream browser bothered to implement this part of SGML handling correctly.
Nope, it's not. In HTML5 it's just optional. From the W3C standard:
>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) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
And to clarify, HTML5 just codified what the browsers have always been doing. The HTML4 standards did not allow <br /> but all browsers accepted it just fine.
The worst bit is that when you do use the XHTML MIME type, most browsers would give a big error message about parsing errors. And then there was the bug in IE7 or IE8 where both the doctype and xml deceleration had to be on the first line to have an effect.
Much closer to writing C without type-checking, and even that might be too strong. Back when that was the cool thing to do, I put a lot of effort into always generating valid XHTML out of a sense of pride, and I'm not sure it ever had any practical benefits. The things that the validator checked for and the things that browsers actually had issues with didn't have a lot of overlap.
Writing valid XHTML was good practice for writing valid XSLT. Browsers would definitely choke on invalid XSL. I remember spending a fair amount of time looking at that pale yellow Firefox error screen that would point out invalid XML documents during my XSL days.
It's been a while, so I'm not completely sure this is true, but I think any XHTML within an XSL document also had to be valid XML (that would also validate against the XHTML schema), so you couldn't get away with as much as you could with rendering a plain XHTML page.
Same here, and it helped me exactly once: it taught me about proper html escaping of variables before setting them in the source (& broke in a <a href="...">).
It wasn't that we weren't validating, but instead there was always something that prevented us from getting to 100% that we were unable to fix. That is what I mean by 'probably will not validate anyway'.
When I see programmers add useless things that do nothing I wonder about their level of knowledge. Do they know it does nothing and are adding it for looks? Or are they poor programmers who can only program by copy paste?
Some things are obviously looks (useful looks, but still not required) - indents in C, or semi-colon in Javascript.
Other things are not. You say that the slash is just for the look, but since that's a rare position, I would advise not doing that - it makes you look bad to other programmers. Especially because unlike my other examples the slash has no useful purpose at all.
Nitpick, but that is required. The heuristic that places it for you is meant as an aide if you accidentally forget to add it. And it's not always right.
Linters will also flag your code when you don't include semicolons.
As for <br> vs. <br/>. I personally prefer <br/> because of consistency. Just like I'd write <img .. />, <link .. /> and so on.
The HTML5 spec has two things: an XML serialization specification, and a detailed non-XML parsing specification that makes the parser safely accept the evil slash on void elements like BR and IMG. Bonus: it also accepts the alternate spelling of the name of the IMG element.
A style guide, of course, could ban using IMAGE as the name of the IMG element or any other infelicity, whether it is legal or merely tolerated.
the alternate spelling of the name of the IMG element
I remember that jumped out at me when I read the HTML5 parsing spec, and I had no success whatsoever finding more information about it (try Googling "<image>"); do you have any links on how it came into existence? Or even better, a site that actually does this?
Fhars has the numbers involved, and you can search the mailing list on this. What I remember is, Ian Hixie was spec editor and was then working at Google. He would do bigtable queries over "all the HTML pages in the world" in some sense, and find out things like that so many million pages had IMAGE tags. So he would float to the list that it should be handled as a matter of robustness. And most of the time those queries would be inspired by someone's suggestion, although I think he had gone ahead and tabulated a frequency table. This way you could judge whether potential new element names would clash with mistakes authors were already making.
<dt>A start tag whose tag name is "image"</dt>
<dd>
<!-- As of 2005-12, studies showed that around 0.2% of pages used the <image> element. -->
<p><a href="#parse-error">Parse error</a>. Change the token's tag name to "img" and reprocess it. (Don't
ask.)</p>
</dd>
...in your opinion. In my opinion, you're wrong. Closed tags and valueless attributes have no place in HTML. Your example for the script tag actually follows the XHTML standard which states that elements whose content model is not EMPTY do not use the minimized form. However, if enough people really have a big enough problem with this, I think we should change the standard to allow self closing script tags. (And apparently they already work in Chrome and some other browsers.)
Given that there are clearly a number of people whose opinion differs from yours and the fact that HTML is an open standard...I think the current compromise as stated in the HTML5 standard (optional self closing tags) should be acceptable to any reasonable person.
(edit: Also, don't ever use React from Facebook if you don't like self closing tags because (since they had to write a parser) they require all tags to be closed or self closed. Consistent, unambiguous formatting is just that much easier to parse.)
Or, are they programmers who have been burned by the arcane few instances where the absence of those relics can still bite you ? (as yet a third, very small distinct class)
Really? Is that what you judge a programmer by? I might be annoyed if I see something like what you're talking about, but I'll just point it out and forget about it.
If all I have is the HTML source code to go by, then yes, that's one of the things.
If I see useless self-closing tags then that starts them at a lower caliber of programmer, and the rest of the code better be really good to raise them back up.
This is because I assume that if they are closing the tags they never bothered to learn html properly, and are just copying online tutorials. Sure, not are all like that, but in absence of other information, I have to use what's in front of me.
> PS: I too am from the XHTML era :)
It's time to stop. People who learned Javascript 20 years ago also had to eventually learn to stop wrapping the scripts in HTML comments. Things change.
The fact that you think semicolons in js are "for looks only" says a lot, and this is from someone who simply doesn't write js, but knows enough to know that it can bite you. And if you think white space in C is unnecessary then, well, you've never worked on a non-trivial C code base.
You know what, to me, is a telltale sign that someone isn't as good as they think they are? They make snap judgements about a person based upon perceived code quality. That tells me that you're in that dangerous "advanced beginner who thinks s/he knows everything" stage.
I didn't say any of those things. You simply misread what I said.
I said they (semi-colons, white space) were not required, but had a useful purpose (i.e. you should use them). Unlike self closing tags which are not required, but additionally serve no purpose whatsoever (i.e. why are you using them?)
I'm not judging a person, I'm judging their ability to program. If you use a feature that does nothing at all it tells me you don't understand the item at hand, you are just copying from other places. Or that you have not updated your knowledge from when those things had a purpose.
Either one of those is not a sign of a good programmer.
>> Either one of those is not a sign of a good programmer.
Yes I've encountered your type before. I take great delight in watching you fail. What you're saying is completely arbitrary, yet you hold the opinion dearly. That's the thing when you're a dick, people don't help you, and they love to see you fail. Life IS easier if you're kind to others.
I self-close out of XML habit. I think you're detecting nothing more than which programmers have written more XML than HTML. If anything I'd think the kind of programmer who likes to close every tag would be better at e.g. always freeing resources correctly.
