- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 16 May 2010 09:15:07 -0400
- To: François REMY <fremycompany_pub@yahoo.fr>
- CC: www-style@w3.org
On 5/15/10 10:11 AM, François REMY wrote: > << > 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. Yes. Or something like it. > 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 *::selection is exactly equivalent to ::selection. That's part of the definition of '*'. So you're proposing the definition of '*' is changed. What exactly is the proposed change? > BTW, can we have ::after or ::before alone ? Yes. And ::first-letter and ::first-line, etc. > 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). That's incompatible with what you call "DOM Propagation", right? > BTW, I don't feel ::selection should be viewn as a pseudo-element > at all. Very possibly, yes. Then it needs a different syntax, yes? Or we need a change to the general parsing + processing model. > 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) ? I don't follow that. If it's a pseudo-element, it just wraps around the text, no? >>> 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. Same as what? > 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> Uh.... why? Where are your ::selections inheriting from? You need to give a definition of the behavior, not examples. > 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. In Mozilla you would get a selection with the color and background of the <span>, whatever those are. Do IE/Opera draw both selections above, or just the innermost one? That is what happens if a non-opaque background color is specified for p::selection? >>> 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 ? I have no idea. It really depends on how the rest of the model works. > Maybe we could consider that > a ::selection has "background: inherit; color: inherit;" by default ? I can't answer that question, since you haven't explained how "inherit" should work in your model. -Boris
Received on Sunday, 16 May 2010 13:16:04 UTC