Intent to Implement and Ship: CSS4 user-select:none

[Yoichi Osato]

Contact emails

yoi...@chromium.org

Spec

https://drafts.csswg.org/css-ui-4/#content-selection

Summary

The user-select:none CSS property lets user not select elements via mouse dragging.

Blink already has -webkit-user-select. For interoperability let’s unprefix it.

Motivation

https://bugs.chromium.org/p/chromium/issues/detail?id=461018

https://bugs.chromium.org/p/chromium/issues/detail?id=481985

developers will write “ .noselect {user-select:none;}” rather than “ .noselect {user-select:none; -webkit-user-select:none} ”.

Interoperability and Compatibility Risk

FF/IE behave as spec but Blink doesn’t.

This intent let Blink follow spec and other browser.

https://bugs.chromium.org/p/chromium/issues/detail?id=481985

Thus we have benefit of interoperability and  have compatibility risk.

compatibility risk:

Most important defference between -webkit-user-select:none and user-select:none is

if user start selection from a *-select:none element.  http://jsbin.com/zufeva/1/

-webkit-user-select:none: user can select  user-select:text element dragging over .

user-select:none: nothing.

-webkit-user-select is used over 70% pages in wild:

https://www.chromestatus.com/metrics/css/timeline/popularity/339

Thus I’m also considering to have user-select implementation and -webkit-user-select simultaneously and deprecate -webkit-user-select as usage downs.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

I’m not sure this is the OWP lauching.

Link to entry on the feature dashboard

https://www.chromestatus.com/metrics/css/timeline/popularity/339

Requesting approval to ship?

No.

[Philip Jägenstedt]

Do you intend to preserve the behavior of -webkit-user-select? Given its usage, it's a safe bet that it can never be removed or deprecated, so if it's different from user-select that's likely going to be a long-term difference. I would support an attempt to change -webkit-user-select to a simple alias of user-select, the risk ought to be limited since the user can always select the thing they want by clicking it directly instead.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

Yay, thanks for pushing on this Yoichisan!

On Thu, Apr 7, 2016 at 6:51 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Do you intend to preserve the behavior of -webkit-user-select? Given its usage, it's a safe bet that it can never be removed or deprecated, so if it's different from user-select that's likely going to be a long-term difference. I would support an attempt to change -webkit-user-select to a simple alias of user-select, the risk ought to be limited since the user can always select the thing they want by clicking it directly instead.

Yeah, that's what I suggested here.  I'd support shipping user-select as an alias of -webkit-user-select and changing the behavior of 'none' to match the spec at the same time.

But I'm not familiar with the other ways user-select is defined to be different from our -webkit-user-select implementation.  Yoichi do you have a list of the differences?  "user-select: contain" is new, right?  I think when we unprefix we should at least try to match other browsers behavior for the values we support (not supporting some values like 'contain' may be fine).

If this is hard, I'd also support incrementally shipping changes to -webkit-user-select to get it more compliant with the spec (but not adding new features like 'contain'), and waiting until we think we have them all before un-prefixing.

Note that I do expect some complaints about the new user-select:none behavior.  Some developers use -webkit-user-select:none to try to make some text hard for users to copy.  With user-select the user can click on something selectable and drag into the user-select:none region to select that text.  Personally I wouldn't worry about this, it's consistent with Edge and (IIRC) Firefox and there's really no way to prevent copying (eg. devtools makes it nearly trivial, printing to PDF can achieve the same thing, etc).

[Yoichi Osato]

> Yoichi do you have a list of the differences?  "user-select: contain" is new, right?  I think when we unprefix we should at least try to match other browsers behavior for the values we support (not supporting some values like 'contain' may be fine).

Investigated. Here is rough doc:

https://docs.google.com/document/d/1158E0YvlUJ5Lwd-8XZBFqE2Ow_FWLrNVik1MFqk3WRU/edit#heading=h.88011od53mkb 

Summary: The common values supported by Firefox and IE/edge are "text" and "none".Given that "text" is as-is selection, user-select:none is the only value

 supported by Chrome,FF,IE.

2016年4月8日(金) 5:29 Rick Byers <rby...@chromium.org>:

[Philip Jägenstedt]

Based on that, shipping support for just "text" and "none" sounds fine. What do you think about -webkit-user-select:none, what's your preferred course of action on issue 481985?

[Yoichi Osato]

I plan to make -webkit-user-select:none follow the spec and ship -webkit-user-select:all, then unprefix -webkit-user-select.

2016年4月11日(月) 21:39 Philip Jägenstedt <phi...@opera.com>:

[TAMURA, Kent]

On Tue, Apr 12, 2016 at 1:17 PM, Yoichi Osato <yoi...@chromium.org> wrote:

I plan to make -webkit-user-select:none follow the spec and ship -webkit-user-select:all, then unprefix -webkit-user-select.

What's the scope of this intent?  Only -webkit-user-select:none behavior change?

--

TAMURA Kent
Software Engineer, Google

[Rick Byers]

On Tue, Apr 12, 2016 at 1:37 AM, TAMURA, Kent <tk...@chromium.org> wrote:

On Tue, Apr 12, 2016 at 1:17 PM, Yoichi Osato <yoi...@chromium.org> wrote:

I plan to make -webkit-user-select:none follow the spec and ship -webkit-user-select:all, then unprefix -webkit-user-select.

What's the scope of this intent?  Only -webkit-user-select:none behavior change?

From the subject / summary I assume it's the whole sentence above (even if that happens in multiple CLs across multiple releases).

Sounds like a good plan to me!   LGTM1 to ship.

[Yoichi Osato]

I plan to make -webkit-user-select:none follow the spec and ship -webkit-user-select:all, then unprefix -webkit-user-select.

> What's the scope of this intent?  Only -webkit-user-select:none behavior change?

I had thought only -webkit-user-select:none but I decided to ship all above.

2016年4月13日(水) 4:00 Rick Byers <rby...@chromium.org>:

[TAMURA, Kent]

ok, lgtm2.

[Simon Pieters]

On Tue, 12 Apr 2016 06:17:33 +0200, Yoichi Osato <yoi...@chromium.org>
wrote:

> I plan to make -webkit-user-select:none follow the spec and ship
> -webkit-user-select:all, then unprefix -webkit-user-select.

By unprefix, do you mean remove support for the prefixed property, or ship
user-select with -webkit-user-select as an alias?

Note that other browsers have implemented -webkit-user-select and the spec
now requires it to be supported.
https://drafts.csswg.org/css-ui-4/#propdef-user-select

--
Simon Pieters
Opera Software

[Rick Byers]

On Wed, Apr 13, 2016 at 3:48 AM, Simon Pieters <sim...@opera.com> wrote:

On Tue, 12 Apr 2016 06:17:33 +0200, Yoichi Osato <yoi...@chromium.org> wrote:

I plan to make -webkit-user-select:none follow the spec and ship
-webkit-user-select:all, then unprefix -webkit-user-select.

By unprefix, do you mean remove support for the prefixed property, or ship user-select with -webkit-user-select as an alias?

Definitely the latter - we know usage is high :-)

Note that other browsers have implemented -webkit-user-select and the spec now requires it to be supported.
https://drafts.csswg.org/css-ui-4/#propdef-user-select

Oh awesome, I hadn't noticed that the spec said -webkit-user-select must be an alias.  That's exactly the right thing to do in this case IMHO, thank you!

[Yoichi Osato]

> UAs that support 'user-select' must also support ''-webkit-user-select'' as an alias.

That's great.

This description was committed 11 days ago:

https://github.com/w3c/csswg-drafts/commit/dfde9cf322831e1bc0d1385e6df68057adc08ec6

+Florian Rivoal, anything on your mind?

2016年4月14日(木) 6:28 Rick Byers <rby...@chromium.org>:

[Florian Rivoal]

On Apr 14, 2016, at 11:32, Yoichi Osato <yoi...@chromium.org> wrote:

> UAs that support 'user-select' must also support ''-webkit-user-select'' as an alias.

That's great.

This description was committed 11 days ago:

https://github.com/w3c/csswg-drafts/commit/dfde9cf322831e1bc0d1385e6df68057adc08ec6

+Florian Rivoal, anything on your mind?

What you're planning to do sounds great to me. The cat is out of the bag (and has been for a long time), so the sooner we get unprefixed implementations out there the better. And yes, I agree there's no way you could remove the prefixed implementation without breaking stuff all over the place, which is why the spec makes aliasing mandatory.

I think it'd be nice if you also implemented the contain value, but I totally understand if you want to deal with that at a later stage.

I would also appreciate feedback on the spec about what your implementation does about issues 19 and 20, and whether what you do is a deliberate decision, or if it just falls out of the implementation but you'd be open to something else if there was a rationale for it.

 - Florian

[Philip Jägenstedt]

LGTM3

[Yoichi Osato]

Thanks. I got 3 LGTMs. I go forward this.

2016年4月19日(火) 17:55 Philip Jägenstedt <phi...@opera.com>:

[Joe Medley]

Yoichi,

Can you please create a tracking bug and a dashboard entry?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Yoichi Osato]

> Can you please create a tracking bug and a dashboard entry?

Done.

https://www.chromestatus.com/features/5722186220306432

I don't understand atmosphere of OWP tracking bug and the dashboard.

I plan to fix -webki-user-select:none behavior, ship -webkit-user-select:all and unprefixed user-select:text, all, none.

Is it better to create each tracker?

2016年4月20日(水) 22:05 Joe Medley <jme...@google.com>:

[Rick Byers]

Do you intend to do all those things in the same milestone?  If so, one entry seems perfect to me.

Really this is all just about communicating to changes to developers that they need to know about WHEN they need to know about it (eg. impacts the blog post, developers scanning for changes in a given release, etc.).  Definitely changing the semantics of "none" is something developers need to be aware of (perhaps the most critical one since it can change some behavior).  And shipping the unprefixed "user-select" is also something that could be valuable to know about.  So if those two things are to happen in different milestones then we should have separate chromestatus entries at least.

[Yoichi Osato]

> Do you intend to do all those things in the same milestone?

Yes, I plan to ship all in M53.

> Really this is all just about communicating to changes to developers ...

I see. Relationship between developers and Blink is very important. Thanks.

2016年4月21日(木) 22:48 Rick Byers <rby...@chromium.org>: