My company just made a nice design on the first door you see after entering the building.

Im so happy they started counting dev rooms from 0

Whenever I see centre (or colour), I cringe.

CP stands for Culinary Post btw, its the place where our designers are sitting and they always bring weird food.

@BambuSource same here, but the owner of the company is british

*cough* <br /> room.

@devios1 learn your html. HTML5 convention is not to use self closing tags.

@Codex404 That literally makes no sense. That would mean html5 is necessarily not compatible with xhtml/xml.

@devios1 thats true, because html is no xml and xml is no html...

@devios1 http://w3c.github.io/html/...

@Codex404 I could scarcely believe it so I looked into it myself. All I can say is I'm incredibly disappointed in this decision. It's simply impossible to reliably parse a document now without having prior knowledge of the meaning of each individual tag.

@devios1 its html :p

@devios1 but in some ways it makes sense. Its a void tag, nothing is permitted in it, using a self closing tag means it can contain something.

@Codex404 It's terrible and imprecise. I for one will definitely not adopt this part of the standard as a form of protest against lessening the formality of the language.

@devios1 ... You are not following standards because you want xml? Thats a different language and thus has different syntax. HTML hasnt been valid XML since at least HTML4, maybe even before that.

@Codex404 The problem is that the parsing and validating of the document now depends on the *meaning* of the element, which is absolutely absurd. You should be able to look at a document at tell if it's well-formed or not without having ANY knowledge of the meaning of specific elements.

@Codex404 HTML has always been a lenient and permissive language and forgives probably way more than it should, so I have no problem with it *working* with non-well-formed documents, but to actually *recommend* that as part of the standard?

That's unforgivable.

@devios1 the thing is that as soon as people as you dont follow standards those documents are not well formed.

@Codex404 I'm well aware xml and html are different languages. In fact xml came out of html as a formalization of the syntax that html invented.

Xhtml was a natural progression which represented a formalization of html that was still backwards-compatible with html, but as formal as xml.

Now that becomes impossible because html5 has chosen to go with a completely informal handling of the representation of elements that relies on prior knowledge of the meaning of those elements.

For example, if I forget to close a <div> tag, that's going to have serious consequences in the meaning (and indeed validity) of my entire document, and tools can catch that kind of thing, however, if I don't close a <br> tag, no big deal at all.

Why is it different?

The whole reason self-closing tags were introduced into xhtml was to solve this problem: it's ambiguous whether an element is supposed to be treated as an atom or a child scope.

It just feels like we're moving backwards.

@devios1 I do get your point and see your logic, but getting away of current standards because "it makes no sense" makes it harder to parse for people who make sure its correct.

@Codex404 The damage is done now, I'm not saying they should change it, just that I'm disappointed in the decision.

However if I and people like me refuse to adopt it, browsers will be forced to continue to support self-closing tags and therefore there is still hope of representing an html document in xml, as was the dream of xhtml.

xhtml was an ivory tower abomination by committee that was rightfully abandoned.

The dream lives on, @Fast-Nop. The dream lives on.

Nah I don't really care. Whatever. Fuck html anyway. I'm just saying it was the wrong decision.

@devios1 I think the problem was that the eggheads focused on non-issues while creating obstacles. True, HTML validation sucks. But who writes HTML validators anyway? For pure usage, you just feed it into the validator at W3C and be done.

Meanwhile, xhtml was not backwards compatible, and nobody was going to change existing website code just for the lulz. Browsers would have had to implement both for no gain.

Xhtml managed to favour the pretty irrelevant group of validator writers at the cost of webdesigners and browser vendors, and that was a major fuckup that only could happen in an ivory tower disconnected from the real world.

@Fast-Nop Xhtml was a good idea, but anything designed by committee is doomed to fail. I think it lost track of its own purpose.

I was only using it as an example of how they solved the ambiguity of elements with self-closing tags. I really dislike the idea of the legality of a syntax being dependent upon the *name* given to an element.

Properly balancing your document just makes sense to me. Validators are only one example. I for one just like my syntax to be logical and self-consistent.

@devios1 is correct.

Marrying syntax and meaning breaks the separation of concerns, and enforcing this marriage renders the syntax internally inconsistent.

These are bad things elsewhere, and they're bad things here, too.

@Root I agree, but not following standards is worse...

@Codex404 No. Standards intentionally causing issues within its product is worse.

Apply this standard to math:
"Brackets must never be closed if the containing set or expression includes symbols that represent infinity or infinite sets, or if the contents can reduce thereto. e.g. [1, 2, 3, ..., n"

Equations would now appear unfinished and/or erroneous unless you had prior knowledge of exactly what they represented. This would also break all existing parsers, and would invalidate formal papers, proofs, textbooks, etc.

Math -- and our representation thereof -- is internally consistent. Introducing inconsistencies would only ever add confusion. All for what? Someone thought it would look better?

No.
It is incredibly stupid, and so is this change to the standards.

@Root your example is completely wrong already. Because a br and img tag are void tags. Its just like omitting a return on a void function.

Just like your function it needs to be declared as void which it is in the element standard.

Your example contains values so it cannot be omitted.

@Codex404
"Its just like omitting a return on a void function"

No, it isn't. The return types of functions are defined within the same file, or a referenced file. HTML tag meanings are not, nor are they referenced in any way. HTML5 headers don't even include a version number anymore, so you can't look them up, either. It is impossible to obtain knowledge of the tags used in an HTML5 document from that document, at least without making dangerous assumptions like "the standard is defined here, and will never change again."

"[my] example contains values so it cannot be omitted"

Reread the new mathematical standard as set forth in my comment. The example listed therein represents an infinite set from [1...n, though you don't know that because `n` is arbitrary and not defined as infinity anywhere, thus demonstrating WHY THIS ABOMINATION IS STUPID.

Likewise, a new <qux> tag, whose purpose is defined in the new 20x6 html5.2 standards has no body, and tells the browser to add a gap in the holographic panel. Without foreknowledge of this tag, all current html parsers will try parsing the remainder of the document as if a child of <qux>, thus severely breaking the rendered page. If <qux/> was self-closing, those parsers would happily ignore the unfamiliar tag, as intended, and render everything else correctly. This is how html parsing is supposed to work, and any deviation from this bloody basic rule breaks all forward-compatibility.

Taking a step back:
You're arguing for blindly following rules without regard to what those rules are and what effects following them will have. This is absurd, and leads invariably to the excuse "I was just following orders" after someone has royally mucked something up. Think for yourself. You have a brain; use it. If rules are counterproductive or damaging, don't follow them. Certainly don't try justifying and defending them. If new rules instruct you to follow worst-practices, do the world a favor and ignore them.

@BambuSource Whenever I see "Aluminum", I cringe.

@Root so you are saying you cant use Pi anymore since its definition is not described when its used. Even worse for cos/sin/tan, they are like functions and not defined. In the same section before using it...

The definition is described in other places and thus it can be used.

It can also be seen as an omitting brackets for statements when its just one line.
if( i == 0 )
i++;

When it's defined you can use it, when its recommended you should use it.
I'm still of the opinion you dont want to use an XML parser for HTML and thus you need to write your own one according the standards. If you still want to use xml parsing get a list of void tags from the standards and replace it.

@Codex404 You just don't get it, do you? None of that is relevant. XML is not relevant. Stop getting stuck on that. Stop bringing up unrelated topics and making strawman arguments.

The entire point of this argument is that the change has zero benefit, yet causes problems. It makes parsing an HTML document more difficult. It also makes parsing future documents potentially impossible.

The change to the standard makes things worse. Not better. Just because it is a rule does not mean it's a good thing. It does not mean the change makes sense. It does not mean you should follow it blindly.

It is pointless and destructive and should not be part of the standard.

Bloody hell.

@Root ah I didnt notice the discussion changing persons. The person before you was pushing on the XML thing.

And I agree with you the standard makes things less easy to parse when you dont have knowledge, but when a standard has been standard since HTML4 then it should be common knowledge and before one tries parsing a language one should investigate the language.
And it took me litterally just a minute to grab all void tags from the standard and put it in a javascript array. So yes it makes it a bit more difficult but not much.

But lets stop the discussion and agree to disagree.

@Codex404 The person before her was arguing the same point, if you were paying attention.

@Root's example of the <qux> element perfectly illustrates how the decision results in problems that could have been avoided.

📌