[css-ui-4] computed value of user-select

[yoichio]

https://drafts.csswg.org/css-ui-4/#propdef-user-select

In this section, the spec says computed value is determined in a way rather than inheritance.
However, computed value is used for inheritance and user-select is not ineherited:
https://drafts.csswg.org/css-cascade/#value-stages

Is this really computed value, not used value?

[frivoal]

Since there is no layout involved, it seems more natural to me to do it on the computed value, but I suppose we could do as a used value as well. Let's see what the group thinks

[kojiishi]

Using computed value has additional cost to implement at least for Blink, even if it doesn't involve layout, so we prefer used value unless there is strong reasons to use computed values. @dbaron ?

[upsuper]

Not completely sure what is the question here. Is this about the special computing rules under

The computed value is the specified value, except:

If it is, I think that making it computed value adds complexity to impl for Gecko as well, especially the rule for editable elements. I hope it could be done either in the UA sheet (so as specified value, no special computation rule), or as used value.

[frivoal]

I hope it could be done either in the UA sheet (so as specified value, no special computation rule), or as used value.

I don't think it cannot be done in the UA stylesheet, but I don't think there's a big problem in doing it as a used value instead of computed value. The need to lookup the value on parent elements, and to check whether the element it applies to is editable or not remains, so there is some inherent complexity to solve, but if that's more easily dealt with at used value time in both Gecko and Blink, we should probably do it there.

[upsuper]

Dealing things as non-queryable value is always easier than queryable value I suppose :)

[gregwhitworth]

We implemented -ms-user-select to resolve auto at computed value time and would prefer for it to remain that way.

[kojiishi]

I spoke from general principle, but then read the spec a bit more and wrote a test to understand the situation around this property. This looks like complicated enough that it's hard to make a call just from a general principle.

• Blink/WebKit implements this property as inherited.
• The spec defines this as non-inherited, but tries to be as if auto and none inherits.
• Edge either inherits, or non-inherited but do its own inheritance following the spec; can't determine from the test.
• Gecko doesn't inherit, and doesn't implement the computed value behavior of auto except for editable elements.

Were there discussions and resolutions to make this property non-inherited, but do its own inheritance only for auto and none?

[frivoal]

I don't remember where we discussed this, so finding the minutes will take a while, but yes, I did present this design and explain the justification behind it to the WG when adding it to the spec.

Long story short: Yes, I do know that this description is not a perfect match with existing reality, but nothing is, since existing reality is not fully interoperable. This is meant to be a compromise trying to preserve as much as possible interoperability where there is some already, and at the same time to be as sane as possible when we have some room for maneuver.

[frivoal]

Links to previous discussions:

• original mail discussion: https://lists.w3.org/Archives/Public/www-style/2015Apr/0022.html
• discussion about some aspects of pseudo-inheritance: https://lists.w3.org/Archives/Public/www-style/2015Jun/0000.html
• Presentation of the property and discussion at NY F2F: https://lists.w3.org/Archives/Public/www-style/2015Jun/0242.html

[kojiishi]

Thank you for the pointers. @yoichio, @yosinch, and I discussed on this, it looks like our concern was not explicitly discussed yet in the past, so please allow us to raise.

Background

From the spec, it looks like the intention is to make contain not to inherit but other values to inherit. We do not have a general mechanism for some values of a property inherits but some do not.

We compute all properties for all elements, regardless whether a property is used or not. Inheritance is normally computed by sharing a data structure that contains all inherited properties from parents.

Since the current spec defines user-select as not-inherited, but computes auto depends on parent's computed style, this logic needs to run on every element, in a way that it is not shareable, even when the property is not used. We'd like to avoid this performance impact.

Proposal

We propose to split values to two separate properties depends on whether we want to inherit or not.

user-select: text | all | none
initial: text
inherited: yes

user-select-contain: none | contain
initial: none
inherited: no

This change will add a new combination, all and contain, which looks like a positive side effect for authors.

Thoughts?

[frivoal]

Can you clarify if my understanding is correct?

• for both properties, the computed value is the specified value
• contain+text does the same as what contain does today
• contain+none does the same as none
• contain+all means:
  • if you are starting the selection from outside of the element, the same as contain today
  • if the selection would start from inside the element, select the entire element, but do not allow extending the selection outside of it

Is that right? I'd need to think deeper about this, but based on this first read (and bikeshedding aside), I think this might work.

A couple things we would probably need to tweak, though:

• user-select-contain would need an auto value that computes to (or behaves as, if you prefer used value time) contain on editable elements, and as none on the rest.
• user-select may also need to take an auto value. It wouldn't do the magic inheritance thing of today, but:
  • all implementations have it
  • we need auto to behave as none on ::before, ::after, ::marker, unless we want to break compat and make these things selectable by default, or deal with that in the UA stylesheet.