[css-ui-4] variants of user-select:none

During the F2F, we discussed what the behavior of a user-select:none child of a user-select:<something-other-than-none> parent should be when the whole parent is selected.

The current spec says that in browsers that support multi-range selections, the selection does not include does not include the child. We agreed this was a useful behavior, but it was also brought up that the alternative ('none' elements cannot be selected directly, but can be as part of a broader selection) could be useful as well.

(Note that this is different from the none vs moz-none behavior difference that used to exist in gecko (but no longer does), as that relates to the children of the none element, not its parents.)

In browsers that do not support multi-range selections, the behavior would be identical (i.e. include the 'none' children).

The only browser that would be affected by this (since it has multi-range selections) is Gecko. And I've been through bugzilla in search of people asking for that behavior, and found none.

I did find numerous requests for the opposite, since Firefox had a bug between FF11 and FF35 which made selections look like they included 'none' children (although copying would not include them), as well as requests in the bug trackers of webkit and blink to match the FF behavior.

This makes me think that we should probably not add this behavior.

But since I was tasked (http://www.w3.org/Style/CSS/Tracker/actions/691) with proposing a design for it, here are 2 alternative ways we could spec that (both to be bikesheded):

a - user-select: auto | none | [ [ text | all | element ] include-children?]

b - user-select: auto | none | not-directly | text | all | element

syntax 'a' means you specify that on the parent element that may contain 'none' elements that you want included in broader selections

syntax 'b' means you specify that on the element which is not selectable directly but should be selectable as part of a broader selection.

'b' seems less surprising to be from an author standpoint, as behavior differences due to parent elements not reflected in the computed value could be somewhat confusing ("I set 'none' on both these elements, and the browser showing it in the computed value so I got my selector right, but why can I still select this element and not that one!?"). It also allows for extra flexibility if you want some children one way and some the other way, although I am not sure what the use cases for that would be.

I think that it would be useful if the people who want this switch could provide some use cases, so that we can confirm that there's actually a need for this, and if there is, so that we can evaluate the syntax in the context it'd be likely to be used.

 - Florian

Received on Monday, 1 June 2015 13:39:07 UTC