- 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