125

Possible Duplicate:
Is type=“text/css” necessary in a <link> tag?

Do we need type="text/css" for <link> tag in HTML5?

Community
  • 1
  • 1
Jitendra Vyas
  • 148,487
  • 229
  • 573
  • 852
  • 1
    Also relevant: http://stackoverflow.com/questions/3668910/the-type-attribute-of-script-and-style-elements-in-html – Šime Vidas Oct 10 '11 at 16:49

4 Answers4

113

The HTML5 spec says that the type attribute is purely advisory and explains in detail how browsers should act if it's omitted (too much to quote here). It doesn't explicitly say that an omitted type attribute is either valid or invalid, but you can safely omit it knowing that browsers will still react as you expect.

Volker E.
  • 5,911
  • 11
  • 47
  • 64
Nathan MacInnes
  • 11,033
  • 4
  • 35
  • 50
  • 31
    The default type for resources given by the stylesheet keyword is text/css. http://www.w3.org/TR/html5/links.html#link-type-stylesheet – igor Nov 27 '13 at 17:59
  • 8
    For scripts default, which is used if the type attribute is absent, is "text/javascript". http://www.w3.org/TR/html5/scripting-1.html#attr-script-type – igor Nov 27 '13 at 18:02
81

Don’t need to specify a type value of “text/css”

Every time you link to a CSS file:

<link rel="stylesheet" type="text/css" href="file.css">

You can simply write:

<link rel="stylesheet" href="file.css">
Mukul Kant
  • 7,074
  • 5
  • 38
  • 53
Sanooj
  • 2,637
  • 15
  • 20
  • 7
    and what will happen if I also don't add `rel="stylesheet"`? – Jitendra Vyas Oct 10 '11 at 16:51
  • 13
    `rel` attribute indicates that the relationship of this link is a style sheet. – Sanooj Oct 10 '11 at 16:54
  • 1
    But I can see that my file is a stylesheet because of the "css" extension. So I do not need the rel attribute. – Timo Oct 28 '14 at 06:57
  • 8
    @Timo: look at the URL of this question. Does the URL end in .html? The URL cannot be used to deduce what file type the resource is. Therefore the rel="stylesheet" attribute is very important. – joonas.fi Feb 20 '15 at 12:33
  • 3
    I know when using the Chrome browser, it won't render your stylesheet without the rel attribute. – Sgnl Jul 20 '15 at 22:15
  • @Sanooj, thank you. This entire thread re: rel= was precisely what I was looking for. I too, like Timo, wondered whether rel= was redundant or not, since the stylesheet ends with .css extension. – Padawan Jan 08 '16 at 04:10
12

For LINK elements the content-type is determined in the HTTP-response so the type attribute is superfluous. This is OK for all browsers.

Šime Vidas
  • 182,163
  • 62
  • 281
  • 385
  • OK. One more thing if I use HTML 4.01 doctype and don't add `type="text/css"` then will browser detect the css or not. I'm asking is this attribute turned on or off the capability of browser to allow to render CSS? – Jitendra Vyas Oct 10 '11 at 16:49
  • No, it will not affect the browser's capability to download and use the CSS. – BoltClock Oct 10 '11 at 16:50
  • @JitendraVyas The only purpose of the DOCTYPE is to trigger standards mode. Both the HTML 4.01 and the HTML5 doctype do that. Switching between those two doctypes does not make any difference. – Šime Vidas Oct 10 '11 at 16:53
  • What about `file://` links that don't get a Content-type? – Beni Cherniavsky-Paskin Aug 26 '13 at 06:42
  • @BeniCherniavsky-Paskin Why would you have a `file:` link in the `` element? Use a local server for your development. – Šime Vidas Aug 30 '13 at 20:41
  • @ŠimeVidas I meant a relative link, which would happen to be local when loaded from local files. You're right that using a local server is better practice, for multiple reasons. But it could be a drawback to omitting `type="text/css"`. Luckily it seems to not be a problem — [example in spec](http://dev.w3.org/html5/spec-preview/the-link-element.html#concept-link-type-sniffing) explains that without a Content-Type metadata, the default type for stylesheet links — text/css — would kick in. (And it works for me in Chrome & Firefox.) – Beni Cherniavsky-Paskin Sep 02 '13 at 23:25
2

You don't really need it today, because the current standard makes it optional -- and every useful browser currently assumes that a style sheet is CSS, even in versions of HTML that considered the attribute "required".

With HTML being a "living standard" now, though -- and thus subject to change -- you can only guarantee so much. And there's no new DTD that you can point to and say the page was written for that version of HTML, and no reliable way even to say "HTML as of such-and-such a date". For forward-compatibility reasons, in my opinion, you should specify the type.

cHao
  • 84,970
  • 20
  • 145
  • 172
  • forward compatibility or backward compatibility? – Jitendra Vyas Oct 10 '11 at 16:43
  • 2
    Forward, currently there isn't really much of an alternative to CSS but that may change in the future. – David Houde Oct 10 '11 at 16:45
  • 2
    @Jitendra: Forward-compatibility is the important one. Like i said, browsers already assume the style sheet will be CSS -- and that includes older browsers. They might not be able to do so in the future, though; if some other style sheet language gets popular, browsers can't make the CSS assumption anymore, and would need to know the type. – cHao Oct 10 '11 at 16:51
  • @Downvoter: Care to explain why? – cHao Oct 10 '11 at 16:55
  • 5
    @cHao The HTML5 standard states that it can be omitted. Browsers will assume that it is CSS (even if tomorrow a new styling language is invented). If a new HTML standard is created, and there is a new styling language, then this property might become compulsory again (and for backwards compatibility, browsers will still assume CSS if it is omitted). – kapa Oct 10 '11 at 17:24
  • @bazmegakapa: That's the problem with a "living standard", though -- supposedly "HTML5" is the last version ever, and it will evolve as browsers do. If some other technology eclipses CSS, and particularly if all modern stuff is using that new technology, then the requirement (and even the default) could very well switch right out from under you. – cHao Oct 10 '11 at 18:14
  • 1
    @cHao No browser maker would make that decision. They don't want to break older pages, that's for sure. – kapa Oct 11 '11 at 06:55
  • @bazmegakapa: No browser maker would make that decision *now*, because there's no chance of CSS being dethroned in the next couple of years. There's nothing to say that they won't make that decision when/if CSS is past its prime. Unless you want to offer a written and cash-backed guarantee about what HTML will be like 50 years from now, you'll pardon me if i don't trust those assumptions. – cHao Oct 11 '11 at 07:55
  • @cHao Again: browser makers are NOT interested in breaking older pages. – kapa Oct 11 '11 at 10:17
  • @bazmegakapa: Are you Mozilla? MS? Google? Unless you are, you can't speak for what they'll do in 50+ years -- and even if you were, you couldn't speak for the others. Whether they're interested in doing it is only tangential; either they do it, or they support every bug and misfeature of every old version of HTML ever made for all time -- making "obsolete" and "deprecated" mean nothing at all. – cHao Oct 11 '11 at 18:44
  • @cHao Sorry, but you can't be serious with those 50+ years. We don't have to agree, so I suggest finishing this now. – kapa Oct 11 '11 at 18:57
  • 1
    @bazmegakapa: I'm not serious about exactly 50+ years -- the point of it is to be a way-out-in-the-future number -- but i am serious about neither one of us being able to predict the future. The farther away that future is, the less predictable it is. It could be that CSS remains the dominant style sheet language forever...in which case the default will always make sense, and it'll never need to be changed or removed. I prefer (and suggest) typing the 16 extra characters (`type="text/css"` and a space) so that i don't have to rely on that being the case for all time. – cHao Oct 11 '11 at 19:27
  • this seems pointless. future proofing is one thing, but this is in the HTML5 spec, so browsers will support it even if a new feature comes out (for backwards compatibility). – Jon Raasch Aug 23 '12 at 01:23
  • @Jon: You don't get the point of a "living standard", do you? It's basically "how things are defined at the moment". *It changes as browsers and authors do.* While there's nothing saying CSS will go away...there's also nothing saying something else won't take its place as the default, if the other thing is so widely supported and popular that everyone's using it and no one's bothering with CSS anymore. And with HTML not being versioned, you don't get to say "oh, i meant that older version that had different defaults". – cHao Aug 23 '12 at 02:34
  • Any future style sheet design will use a `type="text/newcss"`. It is up to the new kid on the block to play well with the prior standard. – Bryce Sep 10 '13 at 19:23
  • Also, apart from the type="text/css" there are three other ways for a browser to determine the type: 1) Mime type on header of linked file. 2) Extension on file in the URL. 3) Implied because it's always been CSS up till now. About standards breaking in the far future... Who cares? Write your code for today. maybe look ahead a year or so if you feel you know what's coming, but don't write type="text/css" because it may be needed in 50+ years. That's just silly. We cross that bridge when we get there and fixing it will be just minutes. So use the "less is more" rule and leave out the type. – Stijn de Witt Sep 11 '13 at 13:34
  • 1
    @StijndeWitt: (2) is frowned upon in most cases, and (1) typically relies indirectly on (2). (Servers don't look for magic numbers in every file they serve, and often don't record the MIME type.) (3) only works if CSS is the One True Stylesheet Language for HTML for all time. We shouldn't need to "fix" content that followed the rules that were in effect when it was created. (And in some cases, like archives, that's not even an option.) Although that means `type="text/css"` *should* be the default for all time, it also makes the default really awkward if CSS gets replaced. – cHao Sep 11 '13 at 14:57