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

Re: UA's implementation of ::selection

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Sat, 15 May 2010 16:11:28 +0200
Message-ID: <1BE8391FBC6C47FFA3174F69469123B7@FREMY2>
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 GMT

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