27

Related: What's the point of Content-Script-Type and Content-Style-Type.

I wanted to know what the main reasons are that developers don't use

  • <meta http-equiv="content-script-type" content="text/javascript" /> and
  • <meta http-equiv="content-style-type" content="text/css" />

in their web projects. (Me neither, btw.)

Saving one from having to declare the used type on every instance of <script> and <style>, it does not seem to have any drawbacks. Yet, in fact, I have never seen one of them in the wild. Are there any considerations one has to take when relying on these <meta> tags?

Community
  • 1
  • 1
Kijewski
  • 25,517
  • 12
  • 101
  • 143
  • 2
    Probably because they're very unheard of. Most people are just used to typing ` – BoltClock Jun 12 '11 at 04:15
  • 2
    There are **web-developers** and **web-copy-pasters**. A little like BoltClock mentioned, most people just don't know about web development but still make cool looking webpages. – Milche Patern Jul 11 '13 at 18:40

9 Answers9

29

According to W3C, http-equiv values "content-style-type" & "content-script-type" attributes are unknown for HTML5 meta markup! Moreover, W3C validator throws the following error when an HTML5 page has such markups:

Line X, Column Y: Bad value Content-Script-Type for attribute http-equiv on element meta.

<meta http-equiv="Content-Script-Type" content="text/javascript">

So essentially we are supposed to avoid them.

Community
  • 1
  • 1
vulcan raven
  • 32,612
  • 11
  • 57
  • 93
  • 3
    Yes, it gags on that because these have been removed in HTML5. Also worth of notice: in HTML4.01, document with event handlers and _without_ a `Content-Script-Type` meta tag are incorrect (http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2). In HTML5, `Content-Script-Type` is either ignored or incorrect (not sure of either), and event handlers must be written using ECMA-262. – alecov Jan 08 '15 at 12:16
15

All web browsers that I've heard of will default to assuming type="text/javascript" on all <script> tags, and type="text/css" on <style> tags. (The only meaningful alternative I've heard of is VBScript for <script> tags in MSIE, which is heavily deprecated. There's no alternative to CSS.) In recognition of this, the HTML5 spec defines both attributes as being newly optional.

As such, there's no point in the Content-Script-Type and Content-Style-Type meta tags -- as far as I'm aware, they're ignored by most, if not all, browsers.

4

It's a shame that these settings have become deprecated with HTML5. Because, as nobody else seems to be mentioning, you can put default character set settings in there as well! Thus:

<meta http-equiv="Content-Script-Type" content="text/javascript; charset=UTF-8;"> <meta http-equiv="Content-Style-Type" content="text/css; charset=UTF-8;">

Daniel Rhodes
  • 141
  • 1
  • 7
  • Since `` only applies to the current document, please explain in what scenario an inline script would have a charset different from its containing document and that document would still be valid. – jcayzac Mar 29 '21 at 04:46
3
<meta http-equiv="Content-Style-Type" content="text/css; charset=UTF-8;">

The CSS meta is important for inline styles where we can't declare the type, so:

<span style="background:pink">
Albert
  • 31
  • 1
3

Speaking as a developer who just learned about these tags from your question, I'd say that it's the curse of the legacy browsers (I'm looking at you, IE6). Because when I learn about new tags, I usually continue not using them. I always assume browsers might not support any feature that I've never heard of, until I prove otherwise (which takes time), and since you have to program to the least common denominator (even if you "progressively enhance" later), that means, in this case, using the safer, more verbose method.

Having said that, I may actually give these a try. There's little risk, unless you're using content types other than text/javascript and text/css, since those have been the assumed defaults, like, forever. Indeed, as @duskwuff points out, there's probably no point in using either.

harpo
  • 41,820
  • 13
  • 96
  • 131
0

To add to the discussion.....

  1. Validators for HTML5 will reject these metatag formats as they are deprecated, as some here mentioned. If you care about strict HTML5 validation then you will have to remove them. Because the browser defaults are close to what older browsers used, you will likely be ok without them. I still use them for older browser support.

  2. HTML5 browsers also use "application/javascript" (not "text/javascript") as the correct script type, which older browsers might not support. Again, I would use the older metatag with "text/javascript" just to be safe.

  3. "http-equiv" is a replacement for what the server sends to the browser. My understanding is the metatags will be overwritten by what the server says. But use them if you are worried about missing server info, though the modern browser defaults would likely be enough. If a server did send "Content-Script-Type" and "Content-Style-Type" then you would not need them.

  4. What if you use these metatags because your "inline" CSS and JavaScript is in a web page that was encoded differently from the HTML5 default of UTF-8? My understanding is JavaScript is always stored as UTF-16, but parsed from UTF-8 encoded pages which is the default for HTML5. Many older HTML files are likely saved as ASCII or UTF-8, as well, but could be something else. Most JavaScript parsers, old and new, navigate all those scenarios and sniffs the right encoding, using your metatags as one of many hints to find out what type and encoding the code uses. Many do this regardless of how you encode your files or pages, or what metatag settings are used. So if you do encode HTML pages or files differently, it might not matter what the metatag says. But it doesn't hurt. Unless you include higher level UNICODE/languages in your CSS or scripts, you don't need to worry about changing the encoding or using metatags to control that.

Stokely
  • 12,444
  • 2
  • 35
  • 23
-1

Being HTTP-EQUIV - this has little to do with being deprecated in HTML5 (because here indeed the defaults are JS and CSS - which also makes the type-attribute unnecessary) - there is still the HTTP protocol: https://www.ietf.org/rfc/rfc4229.txt#2.1.30

so you can from the serverside very well send HTTP headers e.g. from PHP

<?php
header('Content-Type: text/html; charset=UTF-8');
header('Content-Script-Type: text/javascript');
header('Content-Style-Type: text/css');

or node

res.set('Content-Type', 'text/html; charset=UTF-8');
res.set('Content-Script-Type', 'text/javascript');
res.set('Content-Style-Type', 'text/css');
-3

They are depreciated. Now, people use <script type='text/javascript> and <style type='text/css'>.

Jason
  • 109
  • 1
  • 2
  • 10
  • 2
    If they are *deprecated*, you should give a reference to a W3C document (for example) saying so, or a reason why it is fair to call them 'deprecated'. – Andreas Rejbrand Jul 19 '13 at 22:31
-5
<script type="text/javascript">

is depricated, so use

<script type="application/javascript">

instead like mentioned here in april 2006. Start here to find the last content.

Nunser
  • 4,512
  • 8
  • 25
  • 37
  • 2
    If I'm not entirely wrong, nobody of the W3C or WHATWG cares about RFC 4329 (but you may prove me wrong!). Furthermore, to use `script type="application/javascript"` is wrong. You are mixing up unrelated standards. – Kijewski Jul 24 '13 at 04:04