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 20:03:14 +0200
Message-ID: <D7C1FFC606DC45B89AE1E464BBD04393@FREMY2>
To: "David Hyatt" <hyatt@apple.com>, "L. David Baron" <dbaron@dbaron.org>
Cc: "Boris Zbarsky" <bzbarsky@MIT.EDU>, <www-style@w3.org>
Why do you want to create a pseudo element for each
element of the DOM? It would be sufficient to use a
::selection object for the root element. Or at least only
one for each element of the DOM needing a special
styling. It's not needed to create a new instance of
the selection styling object for each element of the
DOM. They can share the same.

Or is that impossible ?

From: "David Hyatt" <hyatt@apple.com>
Sent: Saturday, May 15, 2010 7:27 PM
To: "L. David Baron" <dbaron@dbaron.org>
Cc: "François REMY" <fremycompany_pub@yahoo.fr>; "Boris Zbarsky" 
<bzbarsky@MIT.EDU>; <www-style@w3.org>
Subject: Re: UA's implementation of ::selection

> On May 15, 2010, at 12:24 PM, L. David Baron wrote:
>> On Saturday 2010-05-15 12:19 -0500, David Hyatt wrote:
>>> #mydiv {
>>>  selection: find-in-page(myfindstyle) selection(myselectedtextstyle);
>>> }
>>> I kind of like the idea of having only one pseudo element for each
>>> unique appearance you'd like to apply to any selection in the
>>> whole document.  Having the pseudo elements be singletons off the
>>> document root is very efficient, and then inheritance of all the
>>> selection types is handled using the same model as everything else
>>> in CSS.
>> Properties that accept value lists like that are a disaster in terms
>> of cascading.  We could never implement spellcheck or find-in-page
>> using a mechanism like that since the page would break it the second
>> it tried to style any other type of selection.
>> -David
> Yeah that's a problem.  I'd just really like us to avoid creating many 
> pseudo elements for a single selection appearance.
> dave
> (hyatt@apple.com)
Received on Saturday, 15 May 2010 18:03:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC