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.
I love brevity, and I like your point about ‘milestones’ for practical readability. I also like code to have good documentation, but then I’d want to minify the code.
Minification could include performing this abbreviation, which would surely be a boon to those who are efficiency conscious (and not least for a rather large global extant code-base, right?), but I do wonder whether consistency would be retained in all use cases should the HTML contain mismatching closing tags.
The argument would be legit if folks are using the primitive hand-written HTML. This time has passed more than a decade ago. The obfuscation and optimization of HTML is a normal for deployed app.
As for source-level it is more critical to keep the HTML structure straight with explicit tags closing. The purpose of HTML is not to carry the colored text but the structure for web application. Missing the tag closing is messing as with HTML parser as with whole toolchain folks are making around HTML.
Again, HTML is not a text container anymore and for straight web application structure the explicit tags closure is a must.
The proposal of closing by </> is just another variation of </tag> and @mkay581 objection is drawing the intent of HTML use to “pleasure of HTML reading” as opposite to serve the purpose which is not a reading satisfaction but the DX and functionality.
BTW, the “simple reading” would lead the HTML to Markup/Markdown(MD) or YML syntax. Why you would not jump to propose those formats as base ones for the browser? There is no need to degrade HTML capabilities.
IMO </> does improve the DX, does not degrade the capabilities of parser, increase the reliability of HTML as code and structure. I.e. that is quite personal preference vs actual impact.
