W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: UA's implementation of ::selection

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 15 May 2010 09:21:51 -0400
Message-ID: <4BEE9FEF.2030901@mit.edu>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
CC: www-style@w3.org
On 5/15/10 4:53 AM, Fran├žois REMY wrote:
>> OK. I assume you've looked at the issues with that approach that
>> dbaron described in his mail? If so, are there any particular reasons
>> you've chosen to ignore those issues? (I'm not saying this is a bad
>> approach, just that it would be good to know why its known problems
>> are ok).
> Didn't see that mail. Do you have a reference to it on the w3.org
> archives ?


>> You haven't defined where inheritance and currentColor computation
>> happens from.
> I would define ::selection { color: inherit; } is the same as if no
> ::selection was set.
> This means that the next available ::selection (in the ancestror chain)
> will be used.

Why?  Note that not a single UA of the ones I've tested does that.  In 
any case, what about background:inherit?

> When no usable property is defined, the ::selection should be considered as
> invalid and should be discarded by the UA.

What does that mean?  Move on up the element tree?  Or is this a 
parse-time discard (which seems like a really bad idea)?

> The only exception to those rules is when no valid ::selection is
> Actually, those rules will not be triggered vrey much in the real life,
> as authors will nearly always specify both color and background (it makes no sense
> doing things otherly).

Not making sense has never stopped authors from doing stuff.  They 
commonly specify only color or only background right now on all sorts of 
things; why would ::selection be any different?

Received on Saturday, 15 May 2010 13:22:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:35 UTC