DEV Community


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

baenencalin profile image Calin Baenen ・1 min read

I know some browsers will recognize

<script src="file.js"/>
Enter fullscreen mode Exit fullscreen mode


<script src="file.js"></script>
Enter fullscreen mode Exit fullscreen mode

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.

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

Discussion (7)

inhuofficial profile image

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 />
Enter fullscreen mode Exit fullscreen mode

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 many wasted bytes is that?

Taken from 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:

Enter fullscreen mode Exit fullscreen mode

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

baenencalin profile image
Calin Baenen Author

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.

alohci profile image
Nicholas Stimpson • 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.

baenencalin profile image
Calin Baenen Author

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.

comandeer profile image
Tomasz Jakut

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.

nicozerpa profile image
Nico Zerpa (he/him) • 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.

taufik_nurrohman profile image
Taufik Nurrohman

Out of topic but still relevant:

Why isn’t it <style src="">

Forem Open with the Forem app