Re: UA's implementation of ::selection

From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
>> Based on my tests, I would say Safari has the following behavior
>> when it comes to ::selection :
>>
>>> The ::selection doesn't propagate at all in the DOM Tree.
>
> You mean that ::selection is only applied to the immediate child textnodes 
> of the element selected by the rest of the selector it's attached to (as 
> in Gecko)?

Yes, it is what I intented. Sorry for being unclear.

>>> The ::selection background is used to paint a layer which
>> is between the Text Layer and the Background Layer. This
>> layer has an intrinsec opacity. This opacity still apply when
>> the background property set on ::selection specify already
>> an alpha component (alpha values are multiplied). 'Ad
>> nauseum', I would say it's a 0.75 opacity.
>>
>>> The selection layer has an honnor the traditional opacity
>> (in the sense that it's opacity falls down to 0.375 when we
>> set a 0.5 opacity on the parent element).
>
> OK.  What about the behavior where it sometimes ignores the background 
> styling altogether in cases that are equivalent to background styles it 
> doesn't ignore?

Well. The selection layer ignores every background-related property.
The only things he should honor is things that involves the whole
shape (like opacity or 2D transform). I don't know how 'layers' are
defined in the CSS Specification, however.

>>> Non textual elements are not concerned by the ::selection
>> properties (the IMG selection overlay doesn't update).
>
> That also sounds like Gecko; did you test table cell selections, or does 
> Webkit not support those?

Webkit performs the cell selection using the default style, since
::selection don't propagate through the DOM.

>> In IE and Opera, the ::selection propagate through the DOM
>> Tree (it means that any child of a div::selection inherits from
>> the div::selection values).
>
> What happens if there's a span child of the div which has span::selection 
> specified?  Does one or the other win?  What if one specifies the color 
> and the other the background?  Do both get used, or only one?

I have specified it later in my mail. The span::selection should have
the predecence over the div::selection.

>>> When a ::selection rulebapply
>
> Which is when?  This is one of the things that needs to be defined.
>
>> the background behind the text
>> should be *exactly* the color described in the pseudo-element.
>
> Cascaded how, if there are multiple pseudo-elements that might "apply"? Or 
> can that not happen?

Don't see any case where two rules may apply in a case that's not defined
by the CSS cascading rules already. It's an evidence that #myDiv::selection
has the preference over div::selection.

As the ::selection is a pseudo element, it can't be used in combination with
::before and ::after, which would require more phrasing. But it can't occur.

>> The browser selection extension rule should also apply on
>> other type of selections like image overlay. They are left
>> undefined, but they should use the color defined in the rule.
>
> I'm not sure what that actually means.

It means that, when the selection is extended by the UA (for exemple
by Safari to 'fill' the gaps), they should use the same color as defined
in the ::selection background, but they can apply transforms like opacity.
This is why I said the behavior is left partially undefined.

Another problem was the IMG selection. When a selection is performed,
it seems normal that the selection overlay over the image has to be of
the same color as the selection background. To make sure this will be
done by conforming UA's, I specified that any special selection extension
(like an overlay) should honnor the background specified in the ::selection.
As for any extension, transforms (like opacity) may be applied.

Is this explaination more clear than the first one ?

>>> If an element with ::selection has been found, we use
>> the value that applies to that ancestror
>>> If no element has been found, we use the normal behavior
>> for the selection.
>
> 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 ?

> 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.

To make it clear, let's show a sample :

div::selection { color: red; background: white; }
span::selection { color; inherit; background: yellow }
<div><span>Red on yellow</span></div>

> You haven't defined what should happen if the ::selection rule doesn't 
> specify the background-color or the color or both.

When no background color is specified, no background should apply.
When no text color is specified, the text should not change of color when 
selected.
When no usable property is defined, the ::selection should be considered as
invalid and should be discarded by the UA.

The only exception to those rules is when no valid ::selection is 
encountered at
all in the element chain. In such case, the behavior is left undefined but 
should
be the normal UA selection.

It's kinda like if a :root::selection { color: auto; background: auto; } had 
been defined.
auto would resolve as "no background" in the background property if a color
has been defined, and has "default background" if no color has been defined 
too.
The 'auto' of the color is 'no change applied on the text color when 
selected' in
the case a background has been defined in another ::selection rule. If not, 
we're
in the case none of the two have been defined. So, we can use normal 
selection.

Actually, those rules will not be triggered vrey much in the real life, as 
authors
will nearly always specify both color and background (it makes no sense 
doing
things otherly).

> -Boris
>

Received on Saturday, 15 May 2010 09:00:06 UTC