- 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