For example closing <br /> with HTML, or using HTML comment marks with Javascript in SCRIPT tags.
People just copy what other people have done, without trying to understand each part of it, so you have stuff that is just blindly copied from person to person to person until someone finally stops and says "What does this actually do?"
I just got in the habit when XHTML was looking like the Next Thing, I was actually using it in a lot of stuff, XHTML died, and I never stopped doing it that way because I always felt it was more consistent than having some tags be self-closing and some not. Funny enough, I had been doing things using Thymeleaf templating the last couple years, and it does the HTML template as XML, so you have to close all your tags. I think that has to be some kind of procrastination achievement.
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.
Reminds me of the theory for why some words in English have such odd spellings, that at times, scribes would make errors in their copying and since many scribes were illiterate, those errors would propagate and become part of English.
Monks had a lot of influence on spelling. In French, they abbreviated the "ls" at the end of some words to "x", thus "animals" becoming "animax" (later "animaux", as others added a "u" to make the spelling fit the pronunciation better).
'Connexion' is the one I have come across most frequently, and most of that was when an old colleague leant me a book he got as a child about engineering feats from the late 1800s and early 1900s (up to about 1940). They still used the 'x' instead of 'ct' when writing it, though it was British.
My personal favorite example of this is <meta name="MSSmartTagsPreventParsing" content="true">. This meta tag was related to a Windows XP feature that was proposed, but never released due to user backlash. It's never done anything in any released browser.
A feature which, incidentally, was adopted in limited form by Apple 6 years later in iPhone Safari, which to this day detects strings of digits that look like phone numbers and makes them into links to call the number (without any [obvious?] distinction from normal links, even), without any backlash whatsoever. The email app does that plus dates and addresses. Admittedly it's not quite the same and circumstances differ, but looking back, that IE backlash really looks like an overreaction.
(I also remember reading, many years ago, a very angry post about how you couldn't fully remove Internet Explorer from Windows, because various OS components used it as a library to render their UIs, and how evil and anticompetitive it was for Microsoft to intermingle their products that way. Oh, how times change...)
Difference is that there's competition in the smartphone space and I can grab an Android / Jolla / Ubuntu phone where I can change my default browser. Apple did not have several years of monopoly behind it by burning away competition and never managed to become a monopoly.
There's a reason governments do not like monopolies and the markets cannot fix themselves by getting rid of them since the monopolies are not playing by the market's rules anymore.
And crucially, Apple is only using data detectors to create linkages with iOS internal services that aren't otherwise readily accessible to web sites: creating calendar items, dialing the phone, etc. They're not using it, as Microsoft did, to promote their own web sites and services.
(Yes, I know you can technically access the phone with a tel: link. But very few web sites do this!)
The current situation in programming is that, wherever you work and whatever you do, there is probably piles of boilerplate that you're told to follow. So much of it is just dealing with weird little quirks and shortcomings of a particular platform - I'm thinking here of the Dispose pattern in .NET, various cross-browser compatibility incantations in HTML, the good old Perl preamble, include guards. . . it creates an environment where it's not just natural to copy what you see others do, it's perfectly rational behavior. You could go the engaged skeptical route and figure out exactly what it all means and why you have to do it, but the answer is so frequently "because historical obnoxiousness you can't escape" that it's hard to blame anyone for thinking it's not worth the bother.
Contrast with actual cargo cults, which involved trying to mimic what others see in ways that not only miss the entire point, but fail to achieve the intended effect either. Oftentimes what gets dismissed as cargo cult programming is very different - the operating principle is, "Don't bother with the point because it's probably stupid; just copy others because it will (usually) achieve the intended effect without too much hassle."
Which is important. I have seen an awful lot in practice that you can't rely on GC to happen at all, or happen promptly if it does. Plus things like file handle leaks have even worse consequences in Windows than elsewhere. IDisposable is great to standardize manual cleanup across objects.
> include guards
Whose behavior is bleedingly obvious the first time you see it.
I am thinking if you believe these things are "cargo cult" (despite disagreeing with the term) you must be thinking of fairly mediocre programmers, who look at code and don't get curious about the explanations for things.
It's made worse by the fact that such information is getting increasingly difficult to find when someone actually does want to figure out the "why". Maybe it's just me, but I've found Google's search results to be much worse now than they used to be in terms of detail and specificity, for the same queries.
I feel like this is a side effect of so many people writing random blog posts and other things in an attempt to help others, but in the large it makes it less clear because there's such a long tail of documents that are useful (for some things), that people like, but that cannot answer underlying questions or point to where underlying questions can be answered.
I've found the best solution is to try to find someone with whom you can have a discussion about what you don't understand and where you can find learning resources. Also, being able to find and read specifications can be very helpful.
The worst part is that lots of historical but valuable information is "falling through the gaps" as a result of being overwhelmed by the new and superficial.
If archive.org had a real search engine, I'd probably use it more than Google.
As far as I know, in all browsers that know the script element, it's a non-issue. And even though Lynx won't evaluate JS, it should certainly understand the meaning of the script element.
The comments were necessary in the very beginning when the script element was new and thus might have been treated like any other part of invalid HTML – doing a best effort in rendering.
It is a really common thing for people to erroneously close void elements[0] that aren't supposed to have closing tags, or to give them contents when they can't have any. For example:
<p> some paragraph </p>
<br></br>
<p> a second paragraph </p>
or:
<p> some first paragraph </p>
<br><p> a second paragraph </p></br>
<p> a third thing </p>
Neither of those are valid, and the last one is interpreted as:
<p> some first paragraph </p>
<br>
<p> a second paragraph </p>
<br>
<p> a third thing </p>
New users find behavior like this confusing all the time.
The "/>" is syntax for a self-closing tag in xhtml (e.g. you were supposed to use <img src="" /> etc).
You see "<br />" a lot in php forums because these will often filter user input through the function nl2br whose purpose is to add HTML linebreaks wherever a person has a newline in their post. PHP's nl2br function by default inserts "<br />" unless you tell it specifically not to use xhtml-compatible linebreaks.
Wow that's odd. Also, PHP has a built in function for filtering filtering plain-text user input to create HTML? That's... not something I would have expected.
It's super useful. If you have a textarea for users to type paragraphs into you can use nl2br to output it more or less the same, but in HTML. (Be sure and escape the text before nl2br not after.)
He wasn't talking about closing void elements, he meant self-closing void tags, like <img/>, <br/>, and <hr/>. These were introduced by XHTML to fit with the idea that every tag needs to be closed. HTML5 does away with the requirement, but the HTML5 grammar does explicitly support self-closing tags (http://www.w3.org/TR/html5/syntax.html#self-closing-start-ta...). At this point, self-closing tags are more of a visual preference, as they have a negligable effect on parsing.
At this point, self-closing tags are more of a visual preference, as they have a negligable effect on parsing.
In fact they can be said to have no effect on parsing HTML itself, as the only time when self-closing makes any difference is when the tag's name isn't one that HTML defines - what the spec calls "foreign elements" (e.g. inline SVG or MathML). Those will close when their tag is self-closing, but the closing behaviour of HTML tags is hardcoded in the parser.
Actually .. it wouldn't : http://jsfiddle.net/kv2tzb5n/ (at least in chrome). Would you say this is a good moment to pass judgment on your programming abilities ?
> Would you say this is a good moment to pass judgment on your programming abilities ?
Sure. Interestingly </hr> is ignored, but <br></br> is parsed as a block of some kind. I did not know this, so yes, you can judge me for it.
I know you are poking me for what I said about self closing tags, but I stand by it. I've seen a lot of html, and it's one very easy way to find the bad programmers - they all self close <br>. I'm sure there are exceptions, but I have not come across any.
It's a sign of a tutorial programmer (not exactly), maybe, more or a copy/paste programmer, who finds "blocks" of code that work, and just apply it everywhere.
They tend to lack the deep fundamentals of how html works.
> I've seen a lot of html, and it's one very easy way to find the bad programmers - they all self close <br>.
There are a lot of people, including me, who does it out of habit, aesthetic worries, or to make the markup easier to parse for (some) humans. It's a bit like using Egyptian Brackets in JavaScript.
I use self-closing tags for aesthetic reasons, even though I know they aren't HTML. I like the consistency. I suppose I should get with the times, though, if I am to be taken seriously.
Try doing a parser and you will see why self-closing void tags are generally a good idea.
Anyway, I don't understand this discussion at all. I was expecting something a bit better from the HN community. Since when did we start making strong judgments based on purely esthetical things?
An applicant to a position we offered once submitted a code without <head/> nor <body/> tags, and his justification was totally right: the standard doesn't actually require it[1]. So does that make you a bad programmer for using them? Not using them? I believe nobody really care, and I would have to be a really bad person to judge my colleagues based on that.
I've been working with web technologies for years and I happened to like a lot of things about XHTML. I know how the shit works, I just feel its more consistent to close all of your tags. You obviously wouldn't self-close a <div> or a <section> because those tags are supposed to have content!
As an aside, I would argue that <script> should be nullable when it has a src attribute.
It's not parsed as a block of some kind. The standalone <br> is parsed as it should be, without surprises. The closing tag, however, is parsed as another <br> tag. This is usual HTML behaviour, though, and since HTML 5 thoroughly specified.
The ever-tolerant HTML browser will automatically fix it up. The irony is in that this XHTML syntax has bled back into some code styles in HTML, however inaccurate in that language, but since the introduction of JSX and React, the self-closing tag is required again (all tags must close, or self-close, to be able to parse the file at all)
"That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)"
The real problem is that in "business" instead of the bazaar, you often don't have the time to design something the "right" way because of "business requirements," so you end up in the same mess.
Wow. Blast from the past. I remember being so thrilled when gcc finally added support for precompiled headers. The compile times for the program went from hours to minutes on the same hardware.
For example closing <br /> with HTML, or using HTML comment marks with Javascript in SCRIPT tags.
People just copy what other people have done, without trying to understand each part of it, so you have stuff that is just blindly copied from person to person to person until someone finally stops and says "What does this actually do?"