[webkit-dev] Question on standards mode vs. site compatibility

[Chris Evans]

On Tue, Nov 10, 2009 at 8:37 PM, Darin Adler <darin at apple.com> wrote:

> On Nov 2, 2009, at 11:19 PM, Chris Evans wrote:
>
> Whilst mining a large list of URLs, I came across some sites that render
> incorrectly in WebKit but fine in IE.
>
> It turns out there exist some sites which declare themselves standards
> complaint in their HTML via their DTD. These sites then proceed to try and
> load CSS resources with the incorrect MIME type. This promptly fails due to
> standards mode.
>
> e.g.
> http://web.pcc.gov.tw/ uses application/x-pointplus
> http://www.emart.co.kr/index.jsp uses application/css
> http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in
> place of a slash)
> application/octet stream also appears to be a favourite.
>
>
> That's unfortunate. Out of curiosity, how do these sites behave in Firefox?
>

Broken, in the same way. Fine in IE.


> What is "enforceCSSMIMETypeInStrictMode()"? Is it a global setting or is
> there some per-page metadata somewhere?
>
>
> It’s a setting for applications. For web browsers it is set to true. It is
> not per-page.
>
>
> We can relax the MIME type list we enforce for "strict mode" without
> breaking ACID3, although I'm not even sure that's desirable? Is it worth me
> worrying about this at all or is the correct solution that these sites are
> just broken and need to fix themselves at some stage? (Pragmatically, I
> worry that these sites will never fix themselves so users of WebKit-based
> browsers are SOL).
>
>
> Sounds like a tough choice. It would be unfortunate to have to have a white
> list of sites that violate this rule.
>

I agree we don't want to be listing sites.
Our options would seem to be:
- Do nothing
- Permit application/x-point-plus and application/css as valid CSS MIME
types. This would fix some unknown number of sites, and retain ACID3
compatibility. (ACID3 checks for CSS load failure with text/plain, I think).

Cheers
Chris


>     -- Darin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091110/caa3eb74/attachment.html>