Re: @media and browsers conditional statments

On Aug 9, 2008, at 5:41 PM, Joshua Cranmer wrote:

> Brad Kemper wrote:
>> There's really no reason to use @media (firefox) except to overcome  
>> bugs that are specific to FireFox. Any way, sites that would do  
>> that are probably already blocking those user agents from entering  
>> at all because they are not on the white list.
> What I was trying to point out is that the average developer is  
> going to think "oh look, this thing selects on *browser*, let's use  
> @media (firefox)" without realizing the distinction between the  
> layout engine and browser.

Then they've made a poor choice. I would rather have reasonable  
choices available than to try than to try to protect the world from  
the mindless. Preventing poor design should not be part of the CSS  
charter, but allowing for powerful alternatives should be. With great  
power comes great responsibility.

>> Anyone who would use the new feature would likely look upbthe spec  
>> and see a note about why filtering on "gecko" would be preferred  
>> over filtering  for "firefox". Alternately you could have @media  
>> work with rendering engine and version number but not UA name.
> @media (firefox) shouldn't work, period, IMO (using gecko is more  
> precise, but I'm doubtful as to the utility overall).

There have been occasions where I was more interested in the browser  
than in the rendering engine, although I admit that is more rare. But  
anyway, at least give us something like @media(engine:gecko and max- 
engine-version:2008061004).

The usefulness of this sort of thing is proven by the lengths people  
still go to in order to find hacks to target it or filter it out (or  
Safari, or Opera, or IE7, etc.).

> I also think you're being too optimistic of people to assume that  
> people are looking up the specs. Most probably feel that the  
> language is too "legalistic" and prefer to get watered-down versions  
> form tutorials churned out by publishing houses, or similar media. I  
> can see how it would happen too:

Most CSS tutorials I've seen have parroted whatever advise was offered  
in the spec about how something is expected to be used (unless they  
are about how to work around limitations of the specs, etc.). But with  
less legalese. If these was an emphasized note in the spec about  
proper expected usage, it would end up in tutorials as well. But  
whatever. I would be deliriously happy to have a media query about  
just the rendering engine and its version.

> John Doe comes across site "Blazing Edge of CSS", and finds an  
> article on the @media feature, which "allows one to specify rules  
> specific to browsers." A while later, he comes across a bug in IE  
> and thinks "okay... I need to make an IE-specific hack" and puts in  
> @media (ie), based on his recollection of the article he read  
> earlier. It doesn't work, naturally, so he chalks it up to IE's poor  
> standard supports. Later on, he sees (or reads elsewhere, more  
> likely) that FF borks on this input, see he puts in an @media  
> (firefox) but assumes it to work.
>> Absolutely false. Try hanging around a large corporate call center  
>> sometime when a significant portion of your large user base  
>> suddenly finds that they can no longer use your site.
> If it were unusable, I think the corporation would be blamed; but if  
> it were just... somewhat off, people would probably be more apt to  
> blame the browser.
>> There's no doubt in my mind that it would be better than the  
>> alternative.
> I'll be frank: I have no real alternative either. @has-feature is  
> less likely to be spoofed, but solves nothing in the case of borked  
> implementations.

That's really a huge problem with has-feature. IE would say it  
supports lots of CSS properties, but none of them accept "inherit" as  
a value. Is any implementor going to return false to a "has-feature"  
query, if they have implemented the feature with a bug, or in a way  
that is different from the others but not covered by the spec, or in  
an incomplete-but-nearly-so manner? And yet those are exactly many of  
the sort of things that currently need to be hacked around today,  
nearly as often as just not having the feature at all. Even with  
something like "opacity", a "has-feature" property would not have told  
you that there is a filter alternative in IE6 that works almost as  
well, nor could you assume that based on it returning false for that  
query (if has-feature were hypothetically available in IE6).

> Conditional comments are non-starters. Given the current state of  
> things, I think I best like the idea of sending out different CSS  
> pages for different browsers, but that returns to UA spoofing  
> problems. And it's not one I particular enjoy, either.

Nor would I, but spoofing is just so unlikely. This is not JavaScript  
in the 90s. Things have progressed since then. Those authors who have  
not progressed are blissfully unaware of more modern css features  
anyway. I recently had to deal with a dot-net "author" who uses white- 
listing of browsers to even use his company's Web app, even though it  
worked fine with FireFox and Safari (and Opera, which wasn't on his  
list). And I tell you, he did not know what an "em" was, and almost  
every rule in his extremely lengthy CSS file used classes only,  
usually one class per rule. The HTML was a mess of classes everywhere,  
and not even used consistently at all.

It takes some effort to learn all the things you can do with modern  
CSS, and learning it exposes you to best practices over and over again.

Do you see other browsers spoofing IE's conditional comments so that  
they could be included? Do you see authors putting conditional  
comments around their entire CSS and hanging out a "looks best in IE"  
shingle? No you don't. You DO see authors sometimes using CSS hacks to  
try to target Gecko only, but you don't see smaller less-known user  
agents intentionally replicating Gecko's few selector differences in  
order to be able to see and render the CSS inside those rules. Authors  
have no reason to target FireFox only for all their non-IE code, when  
they could more easily write it to work in virtually all browsers  
(aside from all the IE exceptions, which we typically are forced to  
use hacks or conditional comments to deal with).

Authors that don't know these basic truths are writing for IE-only  
anyway, and aren't even aware of what their pages look like in FireFox  
or anything else.

> P.S. Apologies to any Trident developers reading these messages. I  
> know you're trying, but the fact still remains that IE 6 is a prime  
> example of buggy CSS support.

Yeah, I salute their effort in trying to turn such a turd into  
anything close to being in the same league as FireFox, Safari, or  
Opera. I'll give a meaningful apology for insulting it, once Microsoft  
gives me back the hundreds (if not thousands) of hours in lost  
productivity I've personally spent in working around its horrendous  
CSS bugs, which are legion.

> -- 
> Beware of bugs in the above code; I have only proved it correct, not  
> tried it. -- Donald E. Knuth
>