Re: Proposal of @ua

On Oct 19, 2007, at 9:25 AM, Brad Kemper wrote:

>>> [1] http://meiert.com/en/blog/20070201/why-conditional-comments-are-
>>> bad-repeat-bad/
>>
>> The link gives good reason why conditional statements should be in
>> the CSS (such as with @ua) instead of the HTML itself. It is why I
>> often have to resort to CSS hacks in one CSS file, rather than adding
>> conditional statements to every HTML file. I would much rather use a
>> legitimate @ua rule (if it worked similarly to media queries) than
>> the hacks I use now to get the job done.
>
> Sure, but as long as user-agents mean quite “differing” spec  
> implementations, those “hacks” – when really needed – are certainly  
> still more maintainable than having n style sheets polluting the  
> HTML (as with CCs) or having n “@ua” rules. The latter might be  
> slightly better, but it's still about having working, standards  
> compliant implementations, I fear :/
>
> However, it will stay exciting ;)
>
>
> Best regards,
>  Jens.
>
> -- 
> Jens Meiert
> http://meiert.com/en/

Using a media query or @au would not necessitate extra files. They  
could be used to encapsulate rules within the same sheet. And they  
would be much, much more easily maintained than hacks that are based  
on changing support or interpretation of selector language. And I  
would be long dead if I held my breath waiting for all browsers to be  
exactly the same in the way they render CSS. I'm all for idealism in  
the concept of standards compliant implementations, but there is a  
more urgent need for something simple to handle lack of perfection in  
the real world.


>>   | min-build | max-build | min-version | max-version
>>
>
> Getting people to update max-version retrospectively is the  
> problem. That's essentially why IE User-Agent strings spoof  
> Netscape, and why
> everyone else, including Netscape(!) spoof IE, in the comment that  
> contains IE's real identity.
>
> Basically what happens is that the user agent gets updated to  
> remove a restriction, but the legacy web pages (and those cut and  
> paste coded from them) still effectively reject it.  The result is  
> that the browser has to spoof the market leader to get round this.
>
> The original CSS concept was that unsupported properties were  
> simply ignored, so that they would automatically start working when  
> the browser starts supporting them.  I know this makes pixel  
> perfect designs difficult.
> -- 
> David Woolley

I read something similar the interview with Bert Bos. It was a good  
interview, but that was the one thing he said that I completely  
disagree with (with all due respect, Mr. Bos).

I think this group should try to recognize the lengths authors and  
designers have to go through in order to try to use features that are  
not universally supported. The hacks I discover and use are  
absolutely essential, yet they will inevitably break when the  
implementors change their support for some selector or another. Yet I  
use the hacks anyway, because I have no official way to deal with  
exceptions, and there will always be exceptions. Just hoping and  
campaigning for a perfect world in which all browsers support all  
aspects of CSS3 won't cut it.

There will ALWAYS be varying levels of support, and the WG is failing  
us if they do nothing to recognize and help deal with that cold, hard  
fact. If there was a way to safely target different rendering engines  
and different versions of rendering engines, from within the style  
sheet, in a way that was officially supported by the browsers long  
term, then CSS authors around the world would stand up and cheer. The  
conditional statements in IE were the right idea, but in the wrong  
place (should be in the CSS, not the HTML, and that makes all the  
difference).

I know there are several here that are afraid of repeating the  
situation with JavaScript in which new browsers had to spoof old  
browsers in order to be included, but the situation with CSS is  
completely different. You don't see Safari or FireFox or Opera trying  
to peer inside the IE conditional statements to get at the CSS there  
do you? Of course not, because they know that the only CSS they find  
there will be to work around the problems that IE has with rendering  
the CSS being served to all the other browsers. No other browser  
maker would spoof IE for that, unless their browser had the same  
rendering engine and the same problems to deal with.

But it is not just IE that needs a few lines of its own CSS. FireFox  
is the only major browser (among the top 4) that doesn't support  
inline-block. They have inline-box ('box", not 'block"), but you  
can't do the same thing with its contents because things like margin  
and relative positioning don't seem to work the same within it. So in  
order to style an A tag just for FireFox (that at least SEEMS to look  
and behave similarly), I have to resort to relying on FireFox's  
different interpretation of what it means to negate the existence of  
an empty string as being a substring of another string. It looks like  
this:

a.buttonlink:not([href*=""]) { /* FireFox-specific rules here */  }

I can only hope that if FireFox changes their interpretation of this  
to match the other browsers, that at the same time they will start  
supporting inline-blocks the way the others do. If not, well, people  
using that browser are not going to get the same experience as they  
have now on the site I author. It won't be so nice for them until I  
can then find some other hack. If only I could do something  like the  
following, I would sleep easier at night:

@media all and (renderer: Gecko) { a.buttonlink { /* FireFox-specific  
rules here */  } }

If a new version of Gecko comes out that changes what CSS I need to  
feed it, I am going to have to change my CSS regardless of whether I  
use hacks or something more officially supported. So lets say the new  
version doesn't need that bit any more because it now supports inline- 
block the same as everyone else. It would be really wonderful if I  
could then just change that line to something like this:

@media all and (renderer: Gecko) and (max-build: 20071025)  
{ a.buttonlink { /* "older" FireFox-specific rules here */  } }

...and be done with it. Instead, I have to worry about if it is still  
seeing that rule because it still believes it is right about what :not 
([href*=""] means. In which case it would be picking up two sets of  
rules. and combining them in unexpected ways.

That is but one example. I also use similar measures for other  
browser and for other situations:

 >> I use a background image on an input filed in order to simulate  
Safari's "placeholder" property for other browsers. It works out  
well, since Safari 2.x doesn't support background images on inputs.  
But the latest Webkits do, so I use a CSS hack to change the  
background for just Safari: @media all and (min-width: 0px) { body:not 
(:root:root) input#username { /* Just for latest Webkits */ } }
Of course that will need updating once other browsers support media  
queries more, or the ones that do have a similar take on what body:not 
(:root:root) means.

 >> IE, including IE7, uses line-height differently than all the  
others, and the text always ends up shifted vertically compared to  
other browsers. So when I need it to be precise, I set line-height  
and padding for IE first, and then use a selector IE doesn't  
understand in order to "correct" it for other browsers: html>/**/body  
a.buttonlink { /* non-IE sees this */ } I could have used IE's  
conditional statements in the HTML instead, but I really don't want  
to add it to  hundreds of HTML pages and then update them all when  
things change. It belongs in the CSS file. If IE8 had conditional  
statements in the CSS file that looked like CSS comments to other  
browsers, that would be OK, but something that is part of a standard  
would be much better. There are myriad other situations where IE- 
specific CSS is needed, but I won't get into that now.

In the early days there were two browsers with very different feature  
sets. Authors built for one or the other and hung out a logo that  
said "best viewed in Netscape" or "best viewed in Internet Explorer",  
because their feature sets were pretty different, and designing for  
one meant rendering problems and JavaScript problems in the other.  
People used UA sniffing to minimize the errors the other browser  
would get. So new browsers would have to try to spoof an existing  
one. The CSS situation today is vastly different. There are 4  
browsers that are pretty common, and 3 of them follow the specs  
closely (the other is playing catch-up). Most authors, therefore,   
design to the standards, and then use hacks or HTML conditional  
statements for that one with lots of market share. Or if it is a Web  
app for a corporate environment, they just design for that one and  
let their pages look horrible in everything else.

If authors care about differences between the UA's (as I do) then  
they sprinkle in some hacks such as the ones I've described to deal  
with those differences, and try to make their pages look as good as  
possible in all common browsers. Those who would serve COMPLETELY  
different style sheets based on a white list of UA's that they sniff,  
well they are doing it already by sniffing on the server. Having  
better ways to serve up renderer-specific code is not going to make  
that any worse, and it will make the existing situation for designers  
much, much better. Even if you were to ignore everything else I have  
to say about CSS, I wish you could listen to me on this, and have  
this included in the standards and in the browsers. It is an  
absolutely real need that is frustrating a lot of designers today. I  
think media queries would be a great way to address the need.