Re: Proposal of @ua

On Nov 30, 2007 9:54 AM, Alan Gresley <alan1@azzurum.com> wrote:
>
> Brad Kemper wrote in reply to Freyjkell:
>
> > > // valid:
> > >
> > > body
> > > {
> > >     background: url('top_left.jpg') top left, url('bottom_right.jpg')
> > > bottom right;
> > > }
> > > @media (renderer:Trident)
> > > {
> > >     body
> > >     {
> > >             background:url('alternative.jpg');
> > >     }
> > > }
> > >
> > > --
> > > Freyjkell
> > >
> >
> > Yes. I would see something like this example as a useful guidance
> > note to accompany the specification in the Recommendation.
>
>
> But that is not needed. The same can be done with.
>
> body
> {
> background: url('alternative.jpg') center;
> }
> body
> {
> background: url('top_left.jpg') top left, url('bottom_right.jpg') bottom right;
> }
>
or

body {
  background: url('alt');
  background: url('top_left.jpg') top left, url('bottom_right.jpg')
bottom right;
}

> All browsers that I have tested in that doesn't support multiple backgrounds will ignore the later rule block and use the earlier rule block instead. This is what this updated test case demonstrates.
>
And those browsers are correct.

> http://css-class.com/test/css/colorsbackgrounds/multiple-backgrounds.htm

<snip to reply to brad>
On Nov 29, 2007 9:31 AM, Brad Kemper <brkemper@comcast.net> wrote:
>
>
> On Nov 28, 2007, at 2:04 PM, Andrew Fedoniouk wrote:

>
> 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.

Support is really the matter of concern, isn't it?

>
> 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.


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 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.


>
>
>     @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 | ?

> 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.

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.


> Kind regards, Alan
>
>
>



-- 
Monkey, so they say, is the root of all people today.

Received on Saturday, 1 December 2007 05:47:16 UTC