Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Those are all the void elements as far as I am aware, not a single one of them can have content.
Why would a <script> tag be different to any other element that contains content?
The browsers that recognise your first example are correcting your mistake as it is not valid HTML and breaks conventions that self closing / void elements cannot have content.
I mean to "fix" the problem we could introduce a new element
<extscript src="myjs.js" />
that would be a void element, and I think that is a great idea.
I think the bit you are missing is how you can parse a document. If you have an element that is a void element you know not to look for a closing tag. If an element can contain content then you know there must be a closing tag.
I might be having a "brain fart" but I cannot think of a single element that can both contain content and be self closing!
Otherwise parsing a document would become infinitely more complex every time you get to an opening tag as you would have to look ahead to work out what was going on.
Anyway I hope that clears that bit up, but if you really hate wasted bytes and removing ugly slashes etc here is one that blew my mind.....
Want to save some bytes and be spec compliant?
If you want to save some bytes here is one thing you can change:
There is and never has been a requirement to put a / on a void element in HTML.
It is a XHTML requirement (when everyone thought that was going to take over the world) but in HTML5 it is not needed! In fact in HTML it has never been in the spec!
Yet I still do it, as do millions of others....how many wasted bytes is that?
I'm not about concerned about saving bytes, I know it's optional, I like it because it gives me the cue that there's nothing more to this tag.
What I want to save is my eyes from all those unused </script>s that just lounge around taking up more new-lines, should the developer put a newline between <script ...> and </script, like some examples online do.
There's no practical reason why browsers couldn't parse <script src="file.js"/> as being self-closing. In fact, it's what they do for foreign elements like <svg/>.
As it happens, at least one browser (Safari, I believe) did do this for a while. But it turned out that it wasn't web-compatible. That is, too many developers had created pages where they erroneously used <script ... /> when they'd meant <script ... > as a start tag, following it with script and a close tag. Because browsers had fixed up the markup, the JavaScript that was previously inside the script element was, with Safari's parsing modification, now regular text displayed to the user on the page.
You're right that a new element could be minted, but minting new elements have to clear a much higher hurdle than just "it'd be nice", because every new element - and especially one that ran external scripts - increases the attack surface for security and privacy vulnerabilities, as well as a general maintenance overhead.
Well, honestly, why should it have to face any hurdles, like with your last example of security, since it wouldn't be any more than a shortening of the current syntax, so whatever you can do with that, you could do with this.
And again, why not just support <script src=""/>?
Just have it be an accepted way of doing it, like you said, how it handles <svg>. Personally, I see nothing wrong with this approach, and I don't see why this hasn't really been corrected for the sake of HTML tag length.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can you name an element that can be a void element and a content element?
Those are all the void elements as far as I am aware, not a single one of them can have content.
Why would a
<script>tag be different to any other element that contains content?The browsers that recognise your first example are correcting your mistake as it is not valid HTML and breaks conventions that self closing / void elements cannot have content.
I mean to "fix" the problem we could introduce a new element
<extscript src="myjs.js" />that would be a void element, and I think that is a great idea.
I think the bit you are missing is how you can parse a document. If you have an element that is a void element you know not to look for a closing tag. If an element can contain content then you know there must be a closing tag.
I might be having a "brain fart" but I cannot think of a single element that can both contain content and be self closing!
Otherwise parsing a document would become infinitely more complex every time you get to an opening tag as you would have to look ahead to work out what was going on.
Anyway I hope that clears that bit up, but if you really hate wasted bytes and removing ugly slashes etc here is one that blew my mind.....
Want to save some bytes and be spec compliant?
If you want to save some bytes here is one thing you can change:
There is and never has been a requirement to put a
/on a void element in HTML.It is a XHTML requirement (when everyone thought that was going to take over the world) but in HTML5 it is not needed! In fact in HTML it has never been in the spec!
Yet I still do it, as do millions of others....how many wasted bytes is that?
Taken from dev.w3.org/html5/html-author/#note...
XHTML Example:
<img src="image.png" alt="example"/>HTML Example:
<img src="image.png" alt="example">So every single one of the examples I gave at the beginning can and should be written as follows:
Feels weird doesn't it? But ironically that is what we should be doing!
I'm not about concerned about saving bytes, I know it's optional, I like it because it gives me the cue that there's nothing more to this tag.
What I want to save is my eyes from all those unused
</script>s that just lounge around taking up more new-lines, should the developer put a newline between<script ...>and</script, like some examples online do.There's no practical reason why browsers couldn't parse
<script src="file.js"/>as being self-closing. In fact, it's what they do for foreign elements like<svg/>.As it happens, at least one browser (Safari, I believe) did do this for a while. But it turned out that it wasn't web-compatible. That is, too many developers had created pages where they erroneously used
<script ... />when they'd meant<script ... >as a start tag, following it with script and a close tag. Because browsers had fixed up the markup, the JavaScript that was previously inside the script element was, with Safari's parsing modification, now regular text displayed to the user on the page.You're right that a new element could be minted, but minting new elements have to clear a much higher hurdle than just "it'd be nice", because every new element - and especially one that ran external scripts - increases the attack surface for security and privacy vulnerabilities, as well as a general maintenance overhead.
Well, honestly, why should it have to face any hurdles, like with your last example of security, since it wouldn't be any more than a shortening of the current syntax, so whatever you can do with that, you could do with this.
And again, why not just support
<script src=""/>?Just have it be an accepted way of doing it, like you said, how it handles
<svg>. Personally, I see nothing wrong with this approach, and I don't see why this hasn't really been corrected for the sake of HTML tag length.