Re: [css-pseudo] ::selection issues

On Tue, Nov 11, 2014 at 9:50 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 1. We discussed adding ::spelling-error and ::grammar-error alongside
> ::selection,
>    but there was no resolution at the F2F. Do we want to add these?

Yup.

> 2. The current list of acceptable properties is
>    - color
>    - background-color
>    - cursor
>    - outline
>    - text-decoration
>    - text-emphasis-color (but not text-emphasis)
>    - text-shadow
>
>    a. Are these acceptable?
>    b. Should any other properties be added?
>    c. All but the first two are currently optional. Should any others be
> required?

Why aren't we just using the ::first-line list?

> 3. All four browser engines drop the OS colors with when either of 'color'
>    or 'background-color' is unspecified. This means we have to violate
>    dbaron's #2 requirement (that the OS colors be representable as a UA
>    style rule):
>      http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
>
>    Given that, I'm assuming this is a Web-compat requirement.
>    Shall this be required behavior?

Assuming it's web-compat, yes.

> 4. Most implementations currently draw the text decoration with its
>    original color. This looks super weird, so I'm thinking we
>    should require using the selection-specified color (when
>    there is one), which is what IE does. Are there any concerns with
>    this?
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20%3A%3Aselection%20%7B%20background%3A%20blue%3B%20color%3A%20white%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3ESome%20%3Cu%3Eunderlined%3C%2Fu%3E%20%3Cstrike%3Estruck-through%3C%2Fstrike%3E%20text.

No, it seems pretty straightforwardly wrong.  I suspect it's just a
matter of the way the existing decoration code works (not changing
color unless you explicitly create a new decoration).  While this is
technically the same thing that'll happen if you just put a <span> in
there with a different 'color' and 'background-color', I think this is
common enough that we should magic it up.

> 5. If a ::selection rule specifies inheritance, does it inherit from its
>    originating element (i.e. the unselected text) or does it inherit from
>    the parent ::selection?
>      a. Presto implements inheritance from the parent ::selection
>      b. Gecko/Blink implement inheritance from the originating element
>      c. IE does half and half.
>
>    The interesting question here for authors is probably less about
>    inheritance and more about "how do you erase a rule". If we go with
>    Gecko/Blink, then the 'unset' keyword is the only way to have a
>    previously-styled special::selection use the same colors as its
>    parent::selection.
>
>    We could also leave this undefined for now, since it's unlikely to
>    matter to authors (as long as 'unset' is implemented).
>
>    What does the WG prefer?
>      A. inherit from parent ::selection
>      B. inherit from originating element
>      C. undefined
>      D. Need to ask my dev team what they think, I'll take an action
>         to do that, so give me more time.

B, because it's the closest to consensus, and there are technical ways
to achieve either situation.

> 6. What to do wrt the CSSOM section?
>     A. Keep as-is it for FPWD.
>     B. Drop it for FPWD, replace it with an issue that we need an OM.
>     C. Fix these issues [...] or drop these features [...] and then
>        publish FPWD.
>     D. Hang on, need more time to review.

D

> 7. All implementations draw text-shadow over the selection color.
>    This does not seem user-friendly, particularly when that shadow
>    is an incompatible color. Some options:
>      A. Add this UA style rule or its equivalent effect:
>           :root::selection { text-shadow: none; }
>      B. Draw text-shadow underneath the selection background.
>      C. Leave as-is, we like it.
>    (I prefer option A.)

Can you give an example of it not being friendly?  It seems fine on,
say, the heading of http://xanthir.com/recipes, whether it gets the
default desktop Chrome blue selection, or the default CrOS extra-light
selection.  So far, I'm with C.

~TJ

Received on Wednesday, 12 November 2014 21:27:37 UTC