- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 15 May 2010 09:21:51 -0400
- 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 ?
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
>> 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?
-Boris
Received on Saturday, 15 May 2010 13:22:27 UTC