Re: Proposal of @ua

On Nov 28, 2007, at 2:04 PM, Andrew Fedoniouk wrote:

>>> This construction will match IE6, IE7, Opera but not FF2 as IE  
>>> and Opera do have support of inline-block.
>>>
>>> (IE supports it partially, only for <span> alike elements, but  
>>> still)
>>>
>>
>> It is exactly that word "partially" that makes such a proposal of  
>> very limited use. It might be worthwhile for as far as it goes,  
>> but it doesn't go far enough precisely because of support that is  
>> incomplete. I've mentioned a couple, such as how some values cause  
>> changes to the meaning of z-axis, and some things when gaining  
>> dimension cause all manner of weirdness, including to descendants.  
>> For many other places where support for a particular browser is  
>> partial, pay attention to the yellow rectangles on the following  
>> page that compares IE6, IE7, FireFox 2, and Opera 9:
> Regarding display:inline-block
> 1) It makes sense almost only for intrinsically inline elements.

Maybe in your designs. That is not how "display:" is supposed to  
work, however. Not according to the spec, and not a restriction the  
others have.

> 2) IE was the very first UA that implemented them right (if you  
> consider #1)

I give them credit for implementing it. My purpose was not just IE- 
bashing, or even the merits of how that particular value was  
implemented, but rather to show the type of things that require  
detecting the rendering engine. There are many other instances where  
a property is "supported" in a particular browser, but not as fully  
or as accurately as other UAs.

> And about supports() function in general:
>
> 1) As CSS makes custom keywords perfectly legal then you can do:
>   @media screen and supports(-moz-radius) { }
> to filter out Mozilla only rules.

In other words, (like other hacks) it would be a de facto Gecko- 
detector, if they started supporting a "supports" keyword in media  
queries and included their custom extensions. Except that whatever  
custom extension I choose might be replaced (by border-radius without  
the -moz prefix, for instance) before I needed to stop detecting for  
Gecko.

I don't see how "supports(-moz-radius)" would be better than "@media  
screen and (renderer: gecko)" for detecting Gecko. It is just  
obscuring what it is the author is actually trying to do: reliably  
detect Gecko.

> 2) @ua(name, version) is not practically useful as e.g. Mozilla is  
> publishing new updates pretty frequently.
> I do not think that you would want to make your CSS look like  
> version tracker or so.

I was not advocating that particular grammar. For version checking I  
suggested something more powerful, but still simple.

To illustrate, using your Gecko example, and hypothetically supposing  
that the Gecko in FireFox 2 supported my proposed vocabulary, you  
would start with something like this:

     @media screen and (renderer: gecko) {  /* FF general rules  */  }

When a new version of FF came out that changed the support for  
certain rules enough that you would want to change the rules you  
sent  it, you could add another @media rule to support the new  
version too:

     @media screen and (renderer: gecko)  {  /* FF general rules  */  }
     @media screen and (renderer: gecko) and (min-render-version:  
1.9)  {  /* FF3 rules  */  }

... where "min-render-version" would mean that it would only match if  
the version of the rendering engine was 1.9 or higher. Alternately,  
if everything that required the first @rule was fixed in 1.9, then  
you could just change your original rule to this:

     @media screen and (renderer: gecko) and (max-render-version:  
1.8999)  {  /* FF2 rules  */  }

You could also make 2 mutually exclusive @media rules for 2 versions,  
use the version detection on both of them:

     @media screen and (renderer: gecko) and (max-render-version:  
1.8999) {  /* FF2 rules  */  }
     @media screen and (renderer: gecko) and (min-render-version:  
1.9)  {  /* FF3 rules  */  }

Without this, you have to track whether or not the hack you used  
(including the hack of looking for an identifying "-moz" property in  
your "supports" property) was still available in the new version. If  
it was, then you need a new hack, or you have to let the new version  
use your existing workaround instead of using the new support.

I actually had a similar problem in the design I am working on now,  
which uses display:inline-block to create a row of centered, button- 
like links (anchors). Each one has a span in the middle that is  
styled to be display:block and position:relative, and on hover that  
span is moved down and to the right by one pixel in each direction.  
It works well, and looks nice, giving the impression of a button  
being pushed in, without changing the size the containing "A" tag or  
vertical alignment with the other elements on the same text line. The  
padding on the "A" tag allows the inner span to shift position  
without seeming to go outside the block. In FireFox 2 there is no  
inline-block, so I used their inline-box, and put the display  
attributes in this order:

     a.button { display:inline-box; display:inline-block; }

Then I used my Gecko-detecting hack to give the span some extra 1px  
of margin on its upper left, since relative positioning didn't work  
right on the inner span in Gecko (some other factors involving  
padding were also involved in why it didn't work right in Gecko, but  
the long and short of it was that inline-block and inline-box worked  
differently, and for me on this project inline-block worked better).  
It looked something like this:

     a.button:not([href*=""]):hover span { margin:1px 0 0 1px;  }

It was a clunky workaround, but it allowed the same effect to look  
the same in the top 4 browsers. Other UAs without support for inline- 
block would still see the links, but without some of the extra  
styling that inline-block supports.

But now I've downloaded FireFox 3 beta, which supports inline-block,  
and I see that it is applying the inline-block effects AND the  
margin, causing the inner span to move too far and actually go  
outside its container. Not horrible, but not what I was after. So I  
have a choice: I can change the order of the "display" attributes on  
my "A" rule so that FireFox 3 continues to work the same as FireFox 2  
(in effect, negating the value of their new support for inline- 
block), or I can try to discover another de facto UA-version- 
detecting CSS hack that works only with Gecko 1.9 (FireFox 3). Ah, if  
only it were easier.

BTW, the point of this Gecko example is not to pick on that UA in  
particular (I've already picked on IE), and is not meant as a "how do  
I do this?" for this one problem, just something to illustrate the  
point of how version checking could work so much better than what we  
have to resort to today.

> 3) CSS3 is now modular - means that modules can be supported by UA  
> selectively. This requires some mechanism that allow
> to check if module supported or not on CSS level to make all this  
> schema  practically useful.
> That would be a nightmare (precisely: combinatorial explosion ) if  
> you will rely on @ua(name,version) to discover features
> supported in your style sheets.
> Andrew Fedoniouk.
> http://terrainformatica.com

Its already a nightmare, and a huge time-suck. I am merely proposing  
a better, more reliable, standardized vocabulary for what huge  
numbers of authors are using today (CSS hacks) to deal with changing  
or limited or varied support for various attributes and values. Each  
UA would only have to know the name and version of its rendering  
engine (2 static values per implementation), so it should be very  
simple to implement for anyone who is already implementing the media  
query vocabulary. From the authoring side of the fence, it would be  
much, much, much simpler than what we have to do today. There is a  
real need that is not being addressed.

The people who use the hacks today are the very ones who are trying  
to support the widest variety of user agents. The ones who would  
exclude any users agents that weren't "supported" by the those  
authors already have adequate means of doing so. I continue to see no  
downside to this proposal (aside from possibly delaying Proposed  
Recommendation of Media Queries), in spite of all the resistance from  
implementors.

> Andrew Fedoniouk.
> http://terrainformatica.com
>