W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: UA's implementation of ::selection

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 16 May 2010 09:15:07 -0400
Message-ID: <4BEFEFDB.9080703@mit.edu>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT