" Web server managers may find it convenient to configure a server so that a style sheet will be applied to a group of pages. The HTTP Link header has the same effect as a LINK element with the same attributes and values. " HTML 4.01, section 14.6 Linking to style sheets with HTTP headers http://www.w3.org/TR/html4/present/styles.html#h-14.6 Steps to reproduce ------------------ Load provided URL Actual results in Safari 3.1.2 build 525.21 ------------------------------------------- The webpage has a red background. Expected results ---------------- The webpage should have a green background. Notes - Link http-equiv <meta http-equiv=Link content="<support/limepage.css>; rel=stylesheet"> http://simon.html5.org/test/ie7b2-bugs/030.html also fails - meta-testcase for various methods of linking and/or importing CSS stylesheets http://www.hixie.ch/tests/adhoc/css/cascade/import/002.html fails, in particular for (a) to (f) when the HTTP response headers { Link: <002d.css>; rel="stylesheet" Link: <002f.css>; rel="stylesheet" } are listed: View HTTP Response Header for that meta-testcase: http://web-sniffer.net/?url=http%3A%2F%2Fwww.hixie.ch%2Ftests%2Fadhoc%2Fcss%2Fcascade%2Fimport%2F002.html&submit=Submit&http=1.1&gzip=yes&type=GET&uak=0
Safari 4.0 build 526.11 also fails all 3 tests. Firefox 3.0, Opera 9.51 both pass all 3 tests. I searched for a duplicate and did not find one.
Confirmed bug. Webkit is the only common engine despite MS IE which doesn't have HTTP Link header implemented: http://ietfreport.isoc.org/idref/draft-nottingham-http-link-header/ Gecko and Opera's Presto have it implemented long time ago.
Here’s the matching Chromium bug ticket which should be updated when this is resolved: http://code.google.com/p/chromium/issues/detail?id=19237
This looks like a harmful feature to me - and given that IE doesn't implement it, we probably don't have to either. Anything that takes additional server configuration and makes a pages dysfunctional when opened from file:/// adds confusion. And there doesn't seem to be any benefit. Note this language from HTML4: "This section only applies to user agents conforming to versions of HTTP that define a Link header field. Note that HTTP 1.1 as defined by [RFC2616] does not include a Link header field (refer to section 19.6.3)." HTML5 doesn't mention the link header field, as far as I can tell.
(In reply to comment #4) > HTML5 doesn't mention the link header field, as far as I can tell. HTML5 mentions the Link header field here: http://www.w3.org/TR/html5/semantics.html Quote: > Some versions of HTTP defined a Link: header, to be processed like a series of link elements. If supported, for the purposes of ordering links defined by HTTP headers must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. (URIs in these headers are to be processed and resolved according to the rules given in HTTP; the rules of this specification don't apply.)
http://tools.ietf.org/html/draft-nottingham-http-link-header defines it. (Almost RFC.)
(In reply to comment #6) > http://tools.ietf.org/html/draft-nottingham-http-link-header defines it. (Almost RFC.) Now RFC 5988: http://tools.ietf.org/html/rfc5988
Still looks like a harmful feature. Hopefully, IE wont implement, and we won't need to, either.
I have a patch I'm working on for this. I haven't through through ap's style-sheet objections very carefully, but my intention is to first just have Link: rel=prefetch work in HTTP headers.
(In reply to comment #8) > Still looks like a harmful feature. Hopefully, IE wont implement, and we won't need to, either. Could you clarify why this would be harmful? In comment #4 you say there doesn’t seem to be any benefit, but the benefits are huge. Adding support for the Link header (not only supporting rel=stylesheet but also all other valid link relations) would be very useful. Imagine being able to add a stylesheet to a bunch of unstyled static HTML documents without modifying them all. Full Link header support would also make it possible to have feed-autodiscovery on non-HTML pages (like images, audio, video, plain text files, etc).
Both server operators and people looking at Web content from client side will have more special cases to check, maintain and worry about. Intermediate software like proxies will have more opportunities to handle the content wrong. The end result will be an even less reliable Web. Having multiple ways to do the same thing has a considerable cost, and isn't always better than having one way. Most importantly, the experience with other document specific information being passed in HTTP headers (like charset or Vary) has been so miserable that adding more out of band information gets extremely unwelcome. Note that this doesn't fully apply to feed-autodiscovery or prefetch, and those shouldn't be discussed here. This bug is very specifically about rel=stylesheet.
Mathias, My soon-to-be-shown-patch factors out a lot of the LinkLoader logic into the loader directory, and then it's just a matter of connecting the HTML element or the header parser in. Alexey's right though; perhaps another bug for the Link header period is in order, I'll create that.
See bug 51940 for some implementation of Link headers.
Test cases: http://greenbytes.de/tech/tc/httplink/
http://mathiasbynens.be/notes/css-without-html
Seems like only Firefox Nightly is passing tests mentioned in Comment 14. Safari 17 and Chrome Canary 119 are same. CCing - @Anne, @Simon and @Alexey - for their input and whether we should have it on 'RADAR'.
This is tracked by https://github.com/whatwg/html/issues/8741 and I agree with Chromium that I don't think we should add this to the web (for stylesheets in particular).