Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 12.11.2010 09:29, Julian Reschke wrote: ... Surely, there is no way (that I'm aware of) to guarantee correct downloaded file name in all browsers for all users. A lot of server operators only care about users in their country, and can reasonably (i.e. with negligible cost to business) rely on Windows locale being set. They can just send raw bytes in language default encoding in Content-Disposition, and that works for them and their clients. For all I know, that's what almost everyone does, and it's interoperable for them. Yes. That was the case back in 2003 when I only had to worry about IE and Mozilla/Firefox, and it hasn't been improving until 2008 when I started the work on collection test cases *and* results, and started updating the specs. Since then some of the implementations of 2231 encoding (now 5987) have improved a bit (Opera) / a lot (Konqueror), FF has a few pending patches, and Chrome nighties have started implementing this (two weeks ago). So we are making slow progress now. ... Just for the record: Chrome 9 with 2231/5987 is released. Furthermore, IE9RC supports the 2231/5987 encoding (UTF-8 only). So Safari is the last UA left not supporting this. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11.11.2010 22:14, Alexey Proskuryakov wrote: 11.11.2010, в 11:38, Julian Reschke написал(а): I don't think the IETF will ever approve a standard where the encoding depends on the recipient's locale, with no reliable way to find out upfront what that locale is. Yes, that makes good sense to me. Note that Safari's doesn't rely on OS locale (other than for picking its original default browser encoding, which can then be changed by the user). Surely, some people are allergic to the idea of default browser encoding too, but it's unavoidable in practice - we can't interpret untagged content as Latin-1. There's a difference between HTTP payloads and the actual HTTP header fields, for which the encoding never has been changeable. I disagree that raw bytes are a de facto standard; they do not interoperate across UAs (see above)... I think that we agree about technical details and empirical data now, but describe them differently. Surely, there is no way (that I'm aware of) to guarantee correct downloaded file name in all browsers for all users. A lot of server operators only care about users in their country, and can reasonably (i.e. with negligible cost to business) rely on Windows locale being set. They can just send raw bytes in language default encoding in Content-Disposition, and that works for them and their clients. For all I know, that's what almost everyone does, and it's interoperable for them. Yes. That was the case back in 2003 when I only had to worry about IE and Mozilla/Firefox, and it hasn't been improving until 2008 when I started the work on collection test cases *and* results, and started updating the specs. Since then some of the implementations of 2231 encoding (now 5987) have improved a bit (Opera) / a lot (Konqueror), FF has a few pending patches, and Chrome nighties have started implementing this (two weeks ago). So we are making slow progress now. Global operators like Google or Yahoo obviously want to cover many languages at once, and they just send different HTTP headers to different browsers. That's not great, but that's unavoidable unless IE changes - whether changing interpretation of raw bytes or implementing RFC5987, IE would have to change. The problem are not only operators but also software vendors that sell to customers that operate globally, such as, for example, Web Content Management systems serving content to customers just everywhere. And the issue with UA sniffing is that it only works for existing UAs, and only if they do not change. Back when I encountered the problem first (working on a component of SAM's content management system) I made the optimistic assumption that IE would be the only UA ignoring RFC 2231, so I sniffed for IE and added a workaround. Guess what? The workaround for IE doesn't work in a few locales (because of different encoding defaults), and also Chrome and Safari came out breaking my optimistic assumption that new UAs would do the right thing (so the implementation I worked on doesn't work with Safari, even as today). The spec (RFC 2616) already says that raw bytes are ISO-8859-1, so UAs overriding this are in violation of the spec (IMHO). Yes, that's why I'd really welcome a spec that's closer to reality in this regard. No browser whose vendor cares about markets not covered by Latin-1 can actually treat raw bytes in Content-Disposition as ISO-8859-1. No server operator who wants to serve downloadable content in those markets can stick to ISO-8859-1. IE and Opera do treat the octets as ISO-8859-1. So the issue is that the problem space is *very* complex; many UAs came up with *different* workarounds. None of these interoperate. Some even fail for the same UA in different locales. Introducing a separate parameter (filename*) that doesn't carry the legacy problems is in my opinion the best way to move forward. As a browser implementor, I don't have a strong opinion about filename*. The actual content I see on the Web uses raw bytes in Content-Disposition, so I mostly care about that being adequately specified, so that at least non-IE browsers could all work the same. Firefox and Safari are already pretty close. It's unfortunate if Chrome does not implement this fallback scheme. When you say I see, does that refer to Safari? In which case your perception may already be influenced by the fact that senders are forced to sniff for the User Agent. Generally speaking, having no custom encoding is better than having an opaque custom encoding. In my opinion, the ideal situation would be for servers to send raw UTF-8, and for clients to do what Safari and Firefox do (try UTF-8, then fall back to other encodings). This may be unachievable in practice, in which case interoperability via opaque RFC2231-style encoding is a lesser evil. Optimally, we would just declare that all header fields use UTF-8. But that would be an incompatible change.
[webkit-dev] HTML5 Web Links (RFC 5988)
Gavin wrote in https://lists.webkit.org/pipermail/webkit-dev/2010-November/015026.html: Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin That sounds great. Two thoughts: - please do not forget to take the anchor parameter into account -- either drop the header when it's present, or use it to determine the context of the link (see http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.2) - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11 November 2010 03:59, Julian Reschke julian.resc...@gmx.de wrote: Gavin wrote in https://lists.webkit.org/pipermail/webkit-dev/2010-November/015026.html: Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin That sounds great. Two thoughts: - please do not forget to take the anchor parameter into account -- either drop the header when it's present, or use it to determine the context of the link (see http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.2) - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). Thanks Julian! I'll consider these points carefully. - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 00:59, Julian Reschke написал(а): - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. [*] the approach is to support raw non-ASCII bytes in Content-Disposition file name, decoded as UTF-8 - and if that fails, as referring document's encoding, and if that fails, as browser default encoding. See http://trac.webkit.org/browser/trunk/WebCore/loader/FrameLoader.cpp?rev=71625#L2689. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11.11.2010 18:06, Alexey Proskuryakov wrote: 11.11.2010, в 00:59, Julian Reschke написал(а): - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list athttps://code.google.com/p/chromium/issues/detail?id=57830). As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 9:19, Julian Reschke написал(а): As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Raw bytes seem to be the most common representation for non-ASCII file names on the Web. Implementing that fixed all bug reports I had about Web compatibility in that respect (except for GMail, of course), and didn't cause new ones. Some examples were Yahoo! Mail, several file sharing services, and several Korean forums. This is not surprising, as that's the only way to make a download link that works in both IE and Firefox (at least for target audiences, see below). Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). The Encoding Sniffing column looks somewhat misleading to me, because browsers interpret raw bytes differently. I don't know if any browser sniffs encoding in the common sense of the word. But both IE and Firefox support raw bytes in Content-Disposition, although in different ways. IE: Uses Language for non-Unicode programs setting. So with the system language set to Russian, Content-Disposition is interpreted as windows-1251 (Cyrillic). I'm not sure what it does if decoding fails. Firefox: Tries UTF-8, then referring document's encoding, then Latin-1. Safari: Tries UTF-8, then referring document's encoding, then browser default encoding, and then Latin-1, which can never fail. The IE's mechanism is obviously the weakest - it only works if the file name encoding happens to match local user default. But that's almost always the case for end users. Anyway, if a certain Content-Disposition with raw bytes works in IE _or_ Firefox, it's almost certain to work in Safari, too. If the link works in both, it's pretty certain to work in Safari. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Perhaps I misunderstood your comment or was unclear myself - I don't have a strong opinion about RFC2231-style encoding. It seems cleaner than raw bytes, but with de facto standard being raw bytes, it also seems superfluous. I would welcome it if the standard described what to do with raw bytes, because that's the practical case both browser and server developers need to work with. Obviously, I think that Safari solution is best for browsers (with possible addition of RFC2231/5988 support). It would seem very weird and unfortunate to me if file names were looked up in both Content-Disposition and Link header fields. This is what I referred to as two sources. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11.11.2010 20:10, Alexey Proskuryakov wrote: 11.11.2010, в 9:19, Julian Reschke написал(а): As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Raw bytes seem to be the most common representation for non-ASCII file names on the Web. Implementing that fixed all bug reports I had about Web compatibility in that respect (except for GMail, of course), and didn't cause new ones. Some examples were Yahoo! Mail, several file sharing services, and several Korean forums. This is not surprising, as that's the only way to make a download link that works in both IE and Firefox (at least for target audiences, see below). Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). The Encoding Sniffing column looks somewhat misleading to me, because browsers interpret raw bytes differently. I don't know if any browser sniffs encoding in the common sense of the word. But both IE and Firefox support raw bytes in Content-Disposition, although in different ways. Oh, I called it sniffing because according to HTTP/1.1 it's ISO-8859-1, and some browsers sniff for different encodings. IE: Uses Language for non-Unicode programs setting. So with the system language set to Russian, Content-Disposition is interpreted as windows-1251 (Cyrillic). I'm not sure what it does if decoding fails. Firefox: Tries UTF-8, then referring document's encoding, then Latin-1. Safari: Tries UTF-8, then referring document's encoding, then browser default encoding, and then Latin-1, which can never fail. Thanks for the details, my data in http://greenbytes.de/tech/tc2231/#attwithisofnplain and http://greenbytes.de/tech/tc2231/#attwithutf8fnplain was based on blackbox testing. The observable effect, from testing in a Western European locale, is that the UAs do not interoperate; some stick to 8859-1 (Konq, Opera, IE), some sniff (Safari, Chrome, FF). The IE's mechanism is obviously the weakest - it only works if the file name encoding happens to match local user default. But that's almost always the case for end users. Anyway, if a certain Content-Disposition with raw bytes works in IE _or_ Firefox, it's almost certain to work in Safari, too. If the link works in both, it's pretty certain to work in Safari. Indeed; and I wasn't even aware of that because I'm testing with the local I'm in. I don't think the IETF will ever approve a standard where the encoding depends on the recipient's locale, with no reliable way to find out upfront what that locale is. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Perhaps I misunderstood your comment or was unclear myself - I don't have a strong opinion about RFC2231-style encoding. It seems cleaner than raw bytes, but with de facto standard being raw bytes, it also seems superfluous. I disagree that raw bytes are a de facto standard; they do not interoperate across UAs (see above)... I would welcome it if the standard described what to do with raw bytes, because that's the practical case both browser and server developers need to work with. Obviously, I think that Safari solution is best for browsers (with possible addition of RFC2231/5988 support). The spec (RFC 2616) already says that raw bytes are ISO-8859-1, so UAs overriding this are in violation of the spec (IMHO). Introducing a separate parameter (filename*) that doesn't carry the legacy problems is in my opinion the best way to move forward. It would seem very weird and unfortunate to me if file names were looked up in both Content-Disposition and Link header fields. This is what I referred to as two sources. Ah, so that was a misunderstanding. I was referring to the fact that Link: uses the same *encoding* (RFC 5987) for the title parameter (not filename). So if a UA was to process Link headers for, for instance, chapter titles, it could parse title* to discover I18Nized chapter titles. So no overlap with C-D, except that maybe the library for decoding RFC5987-encoded parameters could be re-used. Best regards, Julian
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 11:38, Julian Reschke написал(а): I don't think the IETF will ever approve a standard where the encoding depends on the recipient's locale, with no reliable way to find out upfront what that locale is. Yes, that makes good sense to me. Note that Safari's doesn't rely on OS locale (other than for picking its original default browser encoding, which can then be changed by the user). Surely, some people are allergic to the idea of default browser encoding too, but it's unavoidable in practice - we can't interpret untagged content as Latin-1. I disagree that raw bytes are a de facto standard; they do not interoperate across UAs (see above)... I think that we agree about technical details and empirical data now, but describe them differently. Surely, there is no way (that I'm aware of) to guarantee correct downloaded file name in all browsers for all users. A lot of server operators only care about users in their country, and can reasonably (i.e. with negligible cost to business) rely on Windows locale being set. They can just send raw bytes in language default encoding in Content-Disposition, and that works for them and their clients. For all I know, that's what almost everyone does, and it's interoperable for them. Global operators like Google or Yahoo obviously want to cover many languages at once, and they just send different HTTP headers to different browsers. That's not great, but that's unavoidable unless IE changes - whether changing interpretation of raw bytes or implementing RFC5987, IE would have to change. The spec (RFC 2616) already says that raw bytes are ISO-8859-1, so UAs overriding this are in violation of the spec (IMHO). Yes, that's why I'd really welcome a spec that's closer to reality in this regard. No browser whose vendor cares about markets not covered by Latin-1 can actually treat raw bytes in Content-Disposition as ISO-8859-1. No server operator who wants to serve downloadable content in those markets can stick to ISO-8859-1. Introducing a separate parameter (filename*) that doesn't carry the legacy problems is in my opinion the best way to move forward. As a browser implementor, I don't have a strong opinion about filename*. The actual content I see on the Web uses raw bytes in Content-Disposition, so I mostly care about that being adequately specified, so that at least non-IE browsers could all work the same. Firefox and Safari are already pretty close. It's unfortunate if Chrome does not implement this fallback scheme. Generally speaking, having no custom encoding is better than having an opaque custom encoding. In my opinion, the ideal situation would be for servers to send raw UTF-8, and for clients to do what Safari and Firefox do (try UTF-8, then fall back to other encodings). This may be unachievable in practice, in which case interoperability via opaque RFC2231-style encoding is a lesser evil. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On Tue, Nov 9, 2010 at 6:01 PM, Alexey Proskuryakov a...@webkit.org wrote: Moving or copying essential information about a document into HTTP headers is frustrating for charset declarations, why do that for anything else? With charsets, there is at least the explanation that many text formats don't have a place to declare it internally. The charset parameter on the content-type header is more reliable than what is in the document. It also gives you a way to know how to decode the bytes into a character stream before you look into those bytes. The absence of a charset parameter requires the user agent to attempt strange things as the default character encoding for HTTP 1.1 is ISO-8859-1. In this way, it is very unlike the reservations some might have for the Link header. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
Even for prefetching this seem rather worthless as it won't allow prefetching start significantly earlier over the resources specified in the document source. There is also (based on the experience in similar things) a high chance that whatever is listed in the Link header won't match what the document actually uses and so will end up slowing down the page load. antti 2010/11/9 Gavin Peters (蓋文彼德斯) gav...@chromium.org: Firefox supports it for rel=prefetch, and it was my thought to include that support in my patch. That use is worthwhile: it allows server specification of prefetch resources, as opposed to author (as in HTML).l - Gavin On 9 November 2010 12:20, Maciej Stachowiak m...@apple.com wrote: On Nov 9, 2010, at 9:00 AM, Alexey Proskuryakov wrote: 09.11.2010, в 03:51, Alex Milowski написал(а): Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2] Note the way in which HTML5 references it: Some versions of HTTP defined a Link: header. That's about HTTP 1.0 only. Specifying stylesheets in HTTP headers seems like a most obvious misfeature to me, and other potential uses of the Link header field are so unimportant that RFC 5988 doesn't even bother to mention them in its introduction. It might be worth testing which other browsers support it. I know at least Firefox supports associating a stylesheet with Link. It does seem like a fairly ill-conceived feature, but not so much that it is worth being the sole holdout, if other browser engines all do it. And there are some plausible use cases - same document served with multiple stylesheets, without having to modify the document on the fly, just the headers. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
10.11.2010, в 01:59, Alex Milowski написал(а): Moving or copying essential information about a document into HTTP headers is frustrating for charset declarations, why do that for anything else? With charsets, there is at least the explanation that many text formats don't have a place to declare it internally. The charset parameter on the content-type header is more reliable than what is in the document. If you meant that it is authoritative, then yes, that's how it works. On the other hand, it's certainly not reliable. If you move your content to a different server, or just download it to a local file, the information is lost. It also gives you a way to know how to decode the bytes into a character stream before you look into those bytes. Yes, knowing charset in advance certainly simplifies things. But since it cannot always be present, clients need to have code that checks for charset declaration in content anyway. In this way, it is very unlike the reservations some might have for the Link header. I think that issues are the same - but as mentioned before, charset in HTTP headers is necessary for some types of content, and that's a good excuse for its existence. Link doesn't appear to ever be necessary. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HTML5 Web Links (RFC 5988)
Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2], has anyone plans to introduce such support into WebKit ? It seems like a straight forward behavior to adopt. At minimum, the CSS stylesheets specified in the Link: header would be inserted, in order, between the user agent stylesheets and the document's stylesheets. Are there any implementation issues that one could imagine with this RFC? There are some obvious interoperability questions until enough browsers sufficiently support this feature. [1] http://tools.ietf.org/html/rfc5988 [2] http://dev.w3.org/html5/spec/Overview.html#the-link-element -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin On 9 November 2010 06:51, Alex Milowski a...@milowski.org wrote: Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2], has anyone plans to introduce such support into WebKit ? It seems like a straight forward behavior to adopt. At minimum, the CSS stylesheets specified in the Link: header would be inserted, in order, between the user agent stylesheets and the document's stylesheets. Are there any implementation issues that one could imagine with this RFC? There are some obvious interoperability questions until enough browsers sufficiently support this feature. [1] http://tools.ietf.org/html/rfc5988 [2] http://dev.w3.org/html5/spec/Overview.html#the-link-element -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
Are there any specific link types we should support in the Link: header besides stylesheets? I know other browsers support Link to reference a stylesheet, so it's probably good for interop if we do it too. Regards, Maciej On Nov 9, 2010, at 3:51 AM, Alex Milowski wrote: Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2], has anyone plans to introduce such support into WebKit ? It seems like a straight forward behavior to adopt. At minimum, the CSS stylesheets specified in the Link: header would be inserted, in order, between the user agent stylesheets and the document's stylesheets. Are there any implementation issues that one could imagine with this RFC? There are some obvious interoperability questions until enough browsers sufficiently support this feature. [1] http://tools.ietf.org/html/rfc5988 [2] http://dev.w3.org/html5/spec/Overview.html#the-link-element -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
09.11.2010, в 03:51, Alex Milowski написал(а): Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2] Note the way in which HTML5 references it: Some versions of HTTP defined a Link: header. That's about HTTP 1.0 only. Specifying stylesheets in HTTP headers seems like a most obvious misfeature to me, and other potential uses of the Link header field are so unimportant that RFC 5988 doesn't even bother to mention them in its introduction. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
09.11.2010, в 9:20, Maciej Stachowiak написал(а): It might be worth testing which other browsers support it. I know at least Firefox supports associating a stylesheet with Link. It does seem like a fairly ill-conceived feature, but not so much that it is worth being the sole holdout, if other browser engines all do it. Agreed. I don't know whether IE supports it, but given that this hasn't been a source of compatibility bugs, I suspect that it doesn't. And there are some plausible use cases - same document served with multiple stylesheets, without having to modify the document on the fly, just the headers. Yes, and that seems to be a (potential?) source of trouble for everyone, not just browser vendors. Surely one doesn't want to fight with a misconfigured hosting that forces a CSS stylesheet on their pages, or to discover that their own server was doing that, after spending an eternity analyzing their HTML source for mistakes. Moving or copying essential information about a document into HTTP headers is frustrating for charset declarations, why do that for anything else? With charsets, there is at least the explanation that many text formats don't have a place to declare it internally. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
