The idea is, as stated in the title, that one would be allowed to omit the name of the tag in the closing tag.
So instead of writing:
<foo><bar>Bla</bar></foo>
One could write
<foo><bar>Bla</></>
Originally, in old html, it was possible to write intertwined tags ( like <foo>B<bar>l</foo>a</bar> ), but it’s no longer allowed ( if it was ever allowed: it was certainly possible to do so with results, but maybe it’s because the browser was trying their best to make sense of the input).
XML has slowly been replaced by JSON, and I think that the fact that JSON doesn’t have this closing mechanism played a role in it.
( “}” doesn’t have a name in it ).
HTML5 isn’t (X) HTML, it can take some distance with the XML.
For the advantages: less mistakes, smaller source and simpler parsing for the browser ( which already keep track of what should be the next closing tag anyway).
Also makes simpler the modification of a page ( you can change the tag by changing it in one place, you don’t have to report the modification on the closing tag ).
Of course it would still be valid to put names in closing tags. In fact, doing so regularly would become a way to check everything is properly closed above.
For example, one may want to put explicitly the closing tag of a table, so if one of the tags above is not closed the browser will be able to detect it and report the error.
And fix it too : close everything until you encounter the closing of the table.
I think it falls into the bucket “Reducing the redundancy of the information”.
This seems like it would make HTML less readable, especially if there are a lot of elements nested multiple levels deep. Spotting syntax errors (e.g. missing closing tags) or knowing where one element starts and ends would be harder as well.
I see the proposal of this being optional. But making syntax optional just gives us more ways of doing the same thing and just gives us frontend devs something else to argue about using.
I don’t think JSON is not readable, and it has fundamentally what I am proposing.
In fact, it’s a question that exists in many (most ?) programming languages. In some language, a block ends with just “end” (or “}”), while in others it will end with “end record” for a record and “end function_name” for a function etc.
There is nothing new here.
It also seems that a lot of popular languages adopted the “end” style ( or the “}” style ), and that it doesn’t create readability issues.
It’s still a perfectly valid position to say that for html it’s different and that it would create readability issues in that case. I understand.
Honestly I don’t have studies pointing in one or in the other direction.
I think ( if anybody cares about what I think ) that neither the position always-name-in-closing or the position never-name-in-closing are good: we definitely want some, to act as milestones, but it’s like comments: inline comments are only getting in the way when a code is modified or created.
But I also think that it would be possible to create a library server-side that would intercept the output formatted with the optional-name-in-closing and would output the standard form. With that it would be possible to test, to even benefit from the advantages I mentioned etc, without making even a notch in the standard.
I beg to disagree. A sequence of } lines in JavaScript is completely unreadable to me, and I have to rely on my code editor to tell me which brace belongs to which block. The indentation helps only sometimes.
Like I said it would be optional. So you would be able to break this sequence of “</>” with a name.
This would prevent the issue of unbalanced closing marks you have with “}”, allowing the source code to have milestones “here is the end of this important block”.
You get flexibility ( easier to change an opening tag) , you reduce the redundancy of the information and you preserve the option to put milestones where you want.
A practice in JS is to add a comment after a very long block stating “end of [foo]”. It helps for readability, but it doesn’t help to put it at the end of each block ( you no longer can detect easily what is the of a long block vs the end of a small block ).
It also has no mechanism to ensure the comment remains accurate about what is closed, unlike in what I am proposing.
