Calin Baenen

Posted on Apr 10, 2021

Why hasn't the 'script' tag gotten a void version, yet? (E.g. 'extscript')

#html #webdev #javascript #watercooler

I know some browsers will recognize

<script src="file.js"/>

<script src="file.js"></script>

as that's basically what a void element is.
But, not all browsers do (one being the one I use, FireFox).

Why is this? Either you should be able to smush a script into the second in to the second example's body, OR it should always be a viable option to use the first example, because without either the script tag(s) look ugly, and it's wasting some space.

It may not be a huge deal, but I see it as mildly annoying, especially if there are lots of tags grabbing a script from somewhere.

FOR CLARIFICATION OF FUTURE READERS:
This boils down to, why is there no void tag for loading external elements, like what InHuOfficial said, with <extscript src="file.js"/>.

Top comments (8)

GrahamTheDev • Apr 10 '21

Can you name an element that can be a void element and a content element?

<area />
<base />
<br />
<col />
<embed />
<hr />
<img />
<input />
<link />
<meta />
<param />
<source />
<track />
<wbr />

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...

6.1.2.2 Void Elements
In XHTML examples, due to the XML Well-Formedness requirements, void elements are always marked up using the trailing slash.

XHTML Example:

<img src="image.png" alt="example"/>

In HTML, however, the trailing slash is optional and, unless explicitly stated otherwise, is always omitted.

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:

<area>
<base>
<br>
<col>
<embed>
<hr>
<img>
<input>
<link>
<meta>
<param>
<source>
<track>
<wbr>

Feels weird doesn't it? But ironically that is what we should be doing!

Nicholas Stimpson • Apr 16 '21 • Edited

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.

Calin Baenen • Apr 16 '21

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.

Calin Baenen • Apr 10 '21

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.

Tomasz Jakut • Apr 11 '21

There are two similar concepts: self-closing elements and void elements. In HTML there are only void elements (so elements without the end tag). If some element is not void, it needs an end tag. The script is not void and that's why it needs an end tag.

The situation is different in XML, which allows any element to be self-closing (so having one tag that will be treated as a start and end tag at the same time). If you want to use self-closing elements, you can always serve your site with application/xhtml+xml MIME type. However it would have all the consequences of serving XML (e.g. draconian error handling). The other solution could be to use some templating engine that uses XML as an input, but generates HTML.

Abhinav Kulshreshtha • Sep 18 '21 • Edited

<link href="js/script.js" rel="text/javascript" as="script" \>

This is kind of valid on all major browser. But here is a caveat, Script tags loads the scripts and executes it. Link tag links an external resource which 'may or maynot' contains thing you might be looking for. And as by the spec, rel and as attributes only acts as a guidance on what this linked resource might be.

Above is oversimplification. In a bit more technical term, There are 5 types of tags in HTML5, and only void and foreign type of tags are allowed to self close. Job of script tag is to contain script. Only reason you can share resource between different script tags on same page because of global prototype design of javascript. i.e everything is part Window.x.x.x.x.x namespace. As far as I am aware, it is impossible to create a separate scope outside the hierarchy of Window object in a browser. Node is not browser.

More on this.

P.S. Chrome based browsers does accept self-closing script because of the highly forgiving nature of web browsers, but it is not a w3c standard. This is just chrome cleaning your mess. Similarly to how firefox automatically adds <tbody> in the tables because we were too busy to do so.

Nico Zerpa (he/him) • Apr 11 '21 • Edited

Ironically, the problem is not exactly the lack of standardisation, but too much of it!

In regular HTML, there are two kind of elements: void and non-void. A void element does not require a closing tag: <hr>, <img>, <meta>, and others. Non-void elements do need a closing tag, but you can put content inside them: <title>, <div>, <a>.

But... in the early 2000s, the W3C (one of the organisations that define web standards), created another HTML standard. known as XHTML. It was basically HTML with XML syntax.

XML does not support void elements, every single tag needs to be closed, but they do have self-closing tags. In XML, you create a self-closing tag by putting a / at the end of the tag: <br/>, <img/>, etc.

XHTML fell out of favour long ago and self-closing tags don't exist in regular HTML and. Actually, Firefox is technically correct by not supporting them (And it seems Chrome doesn't either.)

If some browsers still support self-closing tags in regular HTML, that's just because there were lots of web devs using them, so the browser's dev team decided to support them anyway. But don't be surprised if they decide to drop support in the future.

The <script> element is not void because you can write content on it, e.g: an inline script. Also, HTML doesn't have tags that sometimes are void and sometimes not. A void element is always void. Therefore, when an element sometimes require content should be a non-void element.

The only alternative should be to create a new tag for loading external scripts, but I don't expect that to happen soon.