[whatwg] Style sheet loading and parsing (over HTTP)

[Darin Adler]

On May 24, 2007, at 11:25 AM, Ian Hickson wrote:

> On Thu, 24 May 2007, Jon Barnett wrote:
>
>> I would propose that the "type" attribute be more meaningful on, for
>> example, the <a> element and the <object> element:
>>
>> - If the "type" attribute is present, the UA must use its value as  
>> the
>> value of the Accept request header when requesting a resource
>>
>> And then apply sniffing rules that take the Accept request header  
>> into
>> account (including wildcards in the Accept header):
>> - If the Accept request header accepts text/plain and not text/ 
>> html, and the
>> Content-type response header is text/plain, it must not be sniffed  
>> as HTML.
>> - If the Accept request header does accept text/html, and the  
>> Content-type
>> response header is text/plain, it may be sniffed as HTML.
>>
>> That would allow, for example, Bugzilla to use <a type="text/plain">
>> when linking to an attachment without fear that the attachment  
>> might be
>> sniffed as text/html.
>>
>> I don't know how that would break existing content, but I did want to
>> mention it.  I don't think the "type" attribute is currently abused,
>> especially on links, in a way that would make this harmful.
>
> Interesting idea. Any browser vendors have any feedback on this?

A URL with additional parameters has implementation implications for  
many different parts of the browser. For example, browser history,  
bookmarks, back/forward, etc. would all need to store this additional  
MIME type parameter alongside the URL. And we'd have to decide what  
the rules are for preserving this invisible parameter when editing  
the URL in a bookmark, the location field, etc.

This means that implementing this feature would require changes to  
the API of a browser engine like WebKit as well as changes to browser  
applications.

> Any idea if it would break anything? There are millions of <a>  
> elements with type="" attributes out there, I don't know if any of  
> them would cause problems though.

No idea. It's always safe to assume a change like this will break  
some site, but I don't know how to measure the risk.

     -- Darin