- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Sat, 15 May 2010 16:11:28 +0200
- To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
- Cc: <www-style@w3.org>
From: "Boris Zbarsky" <bzbarsky@MIT.EDU> > 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 ----------------------------------------------------------------------------- << Authors should be able to change the selection style within a specific element. [...] If they can do so, such a change should apply to all of the descendants of that element. >> This requirement seems to indicate that the DOM Propagation of the ::selection properties is wanted. ------------------------------------------------------------------------------ The ::selection vs p::selection problem can be solved by making the use of ::selection alone forbidden. The webdeveloper would then need to use html::selection (or :root::selection) to have a (working) selection's default, or *::selection, which cleary express that any element of the DOM will have this rule applied, even if it's nested in an element which have a special ::selection put on it. But I agree that allowing ::selection alone can cause problems. BTW, can we have ::after or ::before alone ? Seems odd, too, right ? --------------------------------------------------------------------------- The "cascade vs nesting" problem seems to be easily solved by saying every element is responsible to draw its own selection (like it's currently on safari, and possibly other browsers). <p>A<span>B</span></p> with p::selection { ... } implies the P draws a selection background behind the A, and don't do anything behind the B, while the SPAN draws the background behind the B (it may or may not be the same ::selection that apply, it doesn't matter in that case). BTW, I don't feel ::selection should be viewn as a pseudo-element at all. It's rather a layer put between the text and the background of an element. Considering it as a pseudo-element is very difficult since it can be broken in many different parts, which may be separated by gaps (at least in non-webkit browsers). The layer-based definition simplifies many problems seen before. For example, it clarifies why the selected text is not drawn on the ::selection layer but rather in the text layer, by just having special attributes (color seems the only property UA must honnor, but they may also support other formating properties). If ::selection was just a pseudo-element, what would be the rationnale about hiding the selected text in the text layer and display it (at the same position) on another element (the ::selection pseudo-element) ? ---------------------------------------------------------------------------- >>> 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? It would be the same. p::selection { color: white; background: green; } span::selection { color: inherit; background: inherit; } <p><span>This text should be white on green when selected.</span></p> I just tested in IE and Opera, and they do so. Safari ignores the ::selection rule and apply normal selection (which is not wat we would intend). Did'nt test in Mozilla. >> 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)? Good question. What would you expect here ? Maybe we could consider that a ::selection has "background: inherit; color: inherit;" by default ? Regards, F. Remy
Received on Saturday, 15 May 2010 14:13:45 UTC