WNAS

Front end developer

chromium bug

images.jpegI read an interesting tweet just now by Sergey ilinsky, saying that his bug report to Chromium was being ignored. A bug that let's you include css only for chrome WebKit browsers, like apple's safari and google's chrome. Look here for the example page., the text is red in chromium WebKit and black in other browsers. The HTML is valid in case you're wondering, so you won't catch it that way.

All you have to do is to write a phony include that only chromium WebKit browser ( today ) will detect and act upon. Like this:


<link type="custom/mime+type"
rel="stylesheet"
href="css/chromehack.css" />

The type="custom/mime+type" is what does the magic. Chromium WebKit browsers will request the file from the server and add it to the document. What should happen is that browser shouldn't fetch the file or process it for that matter. The chrome team responded with a status: WontFix, which is wrong in my opinion. People will use this to write css to over come chromium WebKit bugs instead of learning what it is they are doing wrong.

The reasoning of the chromium team is:

Darin, given the number of web sites this would likely break I don't think we want to be this strict. If you disagree then I will re-open this.

I think that there is something to be said about this reasoning, but I am one of those people that wants browsers to be very, very strict... I understand that browsers don't want to "break the web", after all, who remembers the outrage that ensued when microsoft released version 7 of IE. A lot of people blamed IE for their own sloppy coding, breaking bad websites.

Why should this be fixed?

A lot of people write css to work around browser bugs, when they should go out and read the specifications. Very often I see people complain about bugs, they have done something wrong in their HTML. So when I see a reaction like the wontfix by chromium I think that a lot of people still will take the easy way out and choose the hack, instead of learning to do it the right way. Not knowing that they are walking a fine line, utilizing a "feature" in a browser which may be fixed at any moment, thus rendering their fixes obsolete.

So I hope that they will fix this soon, after all building browsers to allow sloppy coding is encouraging that very thing in my opinion. And yes, I know that the "we render anything you code, even our own front page garbage" is what made IE6 the greatest browser in it's time. But in the end it slowed down the web, as people were not encouraged to write proper code, but got away with building crap.

Update

Kyle made an excellent point in his comment. This is a WebKit bug or feature. The browser does not do anything wrong, as this is not being specified. So browsers can do what they want with it. He even makes some good points on how we could be using this. Still I am not conviced and urge people not to use this, as it will come back and bite you somewhere...

Kyle SImpson

I can understand why it frustrates you they won't fix this. But I just wanted to point out a few things:

1. afaik, the code in question is in webkit, not in chrome. so this bug should be a webkit bug.

2. i actually rely on this hacky behavior in the context of script tags and fake mime-types. It's key to the "preloading" hack that LABjs employs to be able to load script files in parallel but not have them execute.

that having been said, what they do with script files is to fetch them into cache, but NOT execute them. So I would argue the same should be true of CSS stylesheets with fake mime-types -- load them into cache but don't parse them for rendering.

the tradeoff between strict mode and loose mode becomes kind of gray when you get into the behavior of how resources are loaded by the browser, because this is a wild-wild-west with weird quirky behavior all over the map.

since there are *no* standards on how resources should be loaded by the browser (I'm advocating for there to be, but no such luck, being ignored thus far), I don't think it's fair to say that people who rely on those current quirks/bugs are doing things wrong.

the difference with your IE example is that IE deliberately diverged from spec -- but in this case, there is no relevant spec, so why should we force lock down the browsers to one particular behavior until it's been agreed what that behavior should be.

2010-05-10 21:09

Wilfred Nas

@kyle your first points is well taken and I will update the post to reflect this. It is a WebKit bug/feature and should be labeled as such.
On your second one, maybe you are right to use this. I on the other hand would rather stick to strict coding and hope that the specs will be updated to address these issues...

2010-05-11 06:15