Fwd: Proposal of @ua

Darn it, I forgot to reply to the list again:

Begin forwarded message:

From: Brad Kemper <brkemper@comcast.net>
Date: December 1, 2007 11:39:52 AM PST
To: "Garrett Smith" <dhtmlkitchen@gmail.com>
Subject: Re: Proposal of @ua


On Nov 30, 2007, at 9:47 PM, Garrett Smith wrote:

>>> 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.
>
> It is common knowledge (if not obvious) that support of any feature
> does not imply any particular browser; it only implies support of a
> feature.

I took the comment before mine to mean that "-moz-radius" (a Gecko  
extension) should be used with "supports()" to give Gecko-appropriate  
rules to Gecko-based UAs (to "to filter out Mozilla only rules"). My  
point was that it would therefore serve the same purpose as a current  
hack would for targeting rules to a gecko rendering engine, but  
having the same disadvantages as such hacks in general.

> 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.
>>
> It has been well-explained that 1) user-agent strings do not reliably
> represent any particular browser

And it has similarly been well explained in response, that existing  
user agent strings would not be used. The browser could give a simple  
answer to the query for rendering-engine, and a separate numerical  
answer to a separate query for rendering-engine-version. Giving an  
honest answer would not worsen the situation for any browser, as I  
have argued at length in separate posts.

> 2) support of a feature XXX does not
> imply any particular version of a browser, and 3) a particular browser
> or "renderer" doesn't imply any support for any particular feature.
> The term "regression" means that a bug got fixed, but came back. It
> happens.

Which is why "supports(-moz-radius)" would be no better than existing  
CSS hacks, unless it was used specifically to deal with border-radius- 
related issues.

>>     @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.
>>
> Where did version checking come into  | supports | ?

Never. My example was not for "supports", it was for media queries on  
the rendering engine and version,  which I have argued is a better  
alternative than using one "supports" result to provide unrelated  
"Mozilla only" rules (as per the Andrew Fedoniouk example).

"supports" was suggested for a way around the problem that would not  
require actually asking what the rendering engine name and version  
are. Andrew Fedoniouk also seemed to suggest that it could be used in  
much the same way as current hacks are, where one feature or flaw  
could be used to make inferences about others. Which I consider  
inadequate for the reasons as current hacks are inadequate, but which  
I would probably use if it was all that was available.

>> 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.
>>
>
> You're assuming taht based on CSS parsing rule, the browser will not
> render inline block, and then apply margins. The problem is that you
> are programing by coincidence.

Exactly. Exactly my point. If I could have done a media query on the  
rendering engine and version to deal with this very Gecko-1.8-related  
issue, then I would not have to have "programmed by coincidence".

> Browsers that don't support a feature will simply ignore that feature,
> so you can use:
>
> display: inline-block;
> display: table;
>
> and browser s that don't support display: table will drop that rule,
> while browsers that do support display: table will use that rule.
>
> Or, you could use display: inline-box; (second).
>
> I tend to like display: table for the buttons because I've found it
> easier t omake exapandable buttons that are font-scalable, using 4
> background images.

Good tip regarding "table". Who would have thought that a small  
rectangular button link could be considered a table? Do you think  
that was the intended use of that particular value, or could this be  
considered a CSS hack?

My example was simplified, and I'm not sure that display:table would  
work with the other things I was trying to do at the same time (but I  
will give it a try and see what happens). But as I stated previously:

> BTW, the point of this Gecko example [...]  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.

There have been many other instances where I (and many, many others)  
have had to use a similar hack to deal with situations where  
attributes were interrelated and where a simple override would not  
adequately do the trick.