Re: UA's implementation of ::selection

> François, instead of arguing 'ad nauseum', could you please
> provide us with a complete and detailed description of the
> WebKit's implementation of ::selection?

Sorry, I don't have such documentation on my computer.
What I well can do is retro-analysing the behavior of the
Safari browser when applied to tests.

In this mail, I tried to compare the different implementations
of the ::selection pseudo element, and to define a base on
which we could start writing a true specification (as a web
developer, I don't feel I could do that in a good manner).

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.

> The ::selection doesn't propagate to generated content

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

> Non textual elements are not concerned by the ::selection
properties (the IMG selection overlay doesn't update).

--------------------------------------------------------------------

The behavior of Opera and IE are interoperable. They have
a very different selection system which only select text, while
Safari tries to select the whole element when possible. This
allowed them to not apply a special 0.75 opacity. It seems
better, since the opacity seems undesirable here. Did'nt test
what do Gecko here.

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). IE has still a bug because the back-
ground don't propagate (only the selection text color) but it
has been reported by myself some time ago and Microsoft
said they are going to fix that before RTM).

Mozilla seems to not propagate, too. I didn't run the full test
on it (because it's the only one which need a special test doc-
ument). Anyway, no browser used the ::selection property for
the image overlay, which seems bad.

----------------------------------------------------------------------

Based on this, I think we could use this definition for an
interoperable ::selection :

> The selection layer is displayed between the text and the
background layer. This layer behaves as any other layer of
shape regarding to the properties like opacity. It should not
affect (and be affected) by properties like box-shadow, though.

> The selection layer displays the "selection background". When
no ::selection is specified, the background behind the selected
text is left unspecified (UA-dependant).

> When a ::selection rulebapply, the background behind the text
should be *exactly* the color described in the pseudo-element.
(It means no opacity should apply). UA are still free to extend the
selection where no text is shown, but should use the background-
color of the ::selection rule (an additive opacity may be applied here).

(This last sentence is for the Safari browser. We can't force it
to have no selection background outside the specified text
because it's his normal behavior. but the background behind
the text should be exactly of the color defined in the ::selection
rule. if the webdeveloper want an opacity, he's still free to
use rgba. if he has choosen for a opaque color, the selection
should be opaque, a least under the text, to have an identical
behavior on every browser and makes things more easy for
blind people).

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.

Beside that point, it makes no sense to not propagage the
::selection property (because an element in bold in a span
where the ::selection pseudo element is defined would not
inherit the selection behavior of its parent, which is not
what we would expect).

So, to compute the background and text-color to apply, we
should have this behavior :

> Find the nearest element of the DOM which is parent of
the selected text node (or part of it).
> While there's no special ::selection rule on the element,
or while the element has no parent, we consider its parent.
> 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.

The text is rendered as usual in the Text Layer. The only change
applied to it when it's selected should be its color. Other proper-
ties like text-shadow should continue to apply.

------------------------------------------------------------------------

What do implementers think of this specification base ?
Is that something that will allow interoperable behavior ?

Regards,
François

--------------------------------------------------
From: "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>
Sent: Friday, May 14, 2010 7:27 PM
To: <www-style@w3.org>
Cc: "François REMY" <fremycompany_pub@yahoo.fr>
Subject: Re: Selectors, vendor prefixes (again...) and IE9 and Opera and 
WebKit

> François, instead of arguing 'ad nauseum', could you please
> provide us with a complete and detailed description of the
> WebKit's implementation of ::selection?
>
> Without that, we won't be able to move on and if we (hear the
> WG) can't make a decision here, the rule is simple: vendor
> prefix mandatory.
>
> </Daniel>