[blink-dev] Intent to Implement and Ship: user-select:contain

[Yoichi Osato]

Contact emails

yoi...@chromium.org

Spec

CSS Basic User Interface Module Level 4

https://www.w3.org/TR/css-ui-4/#propdef-user-select

Summary

This user-select:contain value allows authors to specify which elements in the document can enclose user selection.

Motivation

Many web pages today consist of columns or regions. Each region has an article. If user want to select an article, user drags inside the region that contains the article.

However user drag sometimes accidentally go over out of the region and selection is not what user wanted and ugly as a result.

An element with user-select:contain value encloses user selection inside.

Interoperability and Compatibility Risk

Low.

• Since user-select:contain is new value it won’t break existing web.

WebKit: No public signals.

Gecko: No public signals.

Edge: Supports as  ‘element’ value.

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

http://crbug.crom/658129

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

LGTM1

It looks like Edge supports -ms-user-select:element but not user-select:element. If they should want to add user-select:element as an alias in the spec instead of trying to remove it, I think we should support that.

[Joe Medley]

The bug link has a typo.

http://crbug.com/605419

The chromestatus link is also broken, but I can't find a matching item when I do a search there. 

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

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

--
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+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM2

[Rick Byers]

Please use https://drafts.csswg.org/css-ui-4/#propdef-user-select as the spec link, since there could be improvements there not reflected in the 'TR' version.

Since we're the first to ship "contain" the main interop risk here is that the spec will change the name (or drastically alter the semantics) in a way we can't easily adapt to in the future without breaking a lot of the web.  +Florian (who edits the spec), what is your opinion on the risk here?

Rick

On Fri, Oct 21, 2016 at 3:53 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Fri, Oct 21, 2016 at 9:54 AM, 'Joe Medley' via blink-dev <blin...@chromium.org> wrote:

The bug link has a typo.

http://crbug.com/605419

The chromestatus link is also broken, but I can't find a matching item when I do a search there.

Worked for me, standalone page is: https://www.chromestatus.com/feature/5730263904550912

[Florian Rivoal]

Hi,

Thanks for looping me in.

TL;DR:

* I don't expect any drastic change to the user-select spec, either in general or regarding the contain value in particular, and I think it is a good time to implement.

* The main compat risk is not in adding "contain", or future changes in the spec (since they're unlikely), but in harmonizing the rest of the behavior with the other browsers.

* We're short on tests, I'll write some, and I'll review yours if you want to submit any.

* I'll be in Tokyo soon. I am happy to meet if that helps.

== Long version ==

I don't expect a name change; this has already been bikesheded. A large part of the inspiration for that value is "-ms-user-select: element"; that naming was considered bad and we adopted the current one instead as a replacement.

As for the way the contain value affects selection, I am not too worried about changes. By and large, the design is meant to reflect how selection for textarea and contenteditable already works, and takes into account the implementation experience from microsoft. It is possible that there could be minor tweaks in that area, as not all browsers are identical. The current design aims to be a sane compromise between the various approaches, and maybe some of the tradeoffs are wrong, but this would not be major changes anyway, and I expect we won't get to this level of subtlety unless someone actually goes ahead and implements, as you're proposing to do.

To be concrete, here the kind of thing where I think we might still see changes about. Probably not, but maybe.

The spec currently says this:

A selection started outside of this element must not end in this element. If the user attempts to create such a selection, the UA must instead end the selection range at the element boundary.

A possible alternative could be:

A selection started outside of this element must not end in this element. If the user attempts to create such a selection, the UA must instead include the entire element..

I think the current design is the right one, and since it has been reviewed already, I think it is stable, but I don't rule out this kind of tweak. That said, if it does happen, I expect it will come from the first implementer (you), and that backward compat will be a good argument against further changes of that nature once you've shipped.

The biggest challenge to the mechanics of the property was about how computed values work, and came recently from Google (via Koji Ishii). After fairly extensive discussion, we agreed to keep the current design. Other browsers were happy with it already, so I expect no further challenge. To implement the "contain" value, you will need to do a revamp of how you deal with computed values in that property. Browsers differ from each-other in that respect, and the spec is an attempt at defining a sane, web-compatible, interoperable behavior that everybody can adopt. As we've already been through that, I don't expect you'll have issues with it, but it is different from what you currently have, and you'll need to do that change together with (or before) adding the contain value, as it has a dependency on this computed value logic. I see this as a good opportunity to make things better, but if you had not taken that into account, this does increase the scope of the task. Since Yoichi was part of the discussion where Google challenged—then accepted—that model, and he is initiating this thread, you probably have taken this into account already, but in case you have not, I prefer to be upfront about that. If still you have some concerns, I'm happy to talk (see last paragraph).

As far as I am concerned this is the part with the highest risk of web compat problems. The spec is designed with compat in mind, and is fairly close to IE, Edge and Firefox, but I don't have the infrastructure to test, so I cannot completely exclude risks here. Because of that, it is good that you are the first one to go at it. I don't expect anything to go wrong, but should you have any issue, it is much better to find out now rather than after everyone else has converged. I expect a successful implementation in Blink will lock this down.

Finally, the one part of the spec that has seen very little review is the suggestion about what should go into the UA stylesheet. If you're planning to touch this part as well, I'd recommend some thinking and discussion before diving in. I do not think it is critical, and could totally be tackled separately though.

One thing I am not proud of is that there is no test suite yet. I was planning to start writing it in the coming weeks, but I haven't done so yet. And since this feature relies on user interactions, I don't know of any way to write automated tests (at least in a way that can be used in the w3c context), so my upcoming tests will be manual ones. If you do plan to write tests that can be used cross browser and want to send them to the w3c, I promise to review your pull requests on this topic quickly, to make sure you don't get stuck in a review swamp. If you write blink-specific tests that don't fit the formats that can be submitted to the w3c, I'm still happy to have a look if you'd like me to.

Finally, I'll be in Tokyo on November 9 and 10, and plan to find a time slot during these two days to meet with Koji Ishii to discuss some spec related matters. If that would help, I can also take some time to talk about this with Yoichi (and anyone else who'd be in the Tokyo office and interested in this topic, or any thing else related to a spec I edit). Let me know if you're interested, and I'll loop you in for the meeting planning discussion.

 - Florian

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Yoichi Osato]

Thanks everyone to replay.

Joe, OWP launch tracking bug is

http://crbug.com/658129.

Rick. I'm little confused that we have different approach to ship a spec whether 

 it is Editos's Draft or Working Draft because we have

OWP-Standards-OfficialSpec OWP-Standards-UnofficialSpec labels in OWP tracking bugs

 and the feature dashboard has the 'standardization' item.

I thought Working draft was more strong reason to implement it. 

I'm very happy to know our stance. 

Thanks Florian. I'm happy to meet you.

How we implement computed value of user-select:

 I implement as on-time calculation rather than style inheritance in Blink. This 'on-time' means to calc the value when element.getComputedValue is called or 

 we need the value in order to react  user's selection. This works because user-select is not used to layout or paint.

How we test it:

 I will write layout tests with the blink-unique harness. I absolutely agree that we should have the browser-compat harness which can test user's interaction.

2016年10月24日(月) 12:32 TAMURA, Kent <tk...@chromium.org>:

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

[Joe Medley]

Thanks. Not sure where I got that other number.

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

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

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

[Rick Byers]

On Mon, Oct 24, 2016 at 1:29 AM, Yoichi Osato <yoi...@chromium.org> wrote:

Thanks everyone to replay.

Joe, OWP launch tracking bug is

http://crbug.com/658129.

Rick. I'm little confused that we have different approach to ship a spec whether 

 it is Editos's Draft or Working Draft because we have

OWP-Standards-OfficialSpec OWP-Standards-UnofficialSpec labels in OWP tracking bugs

 and the feature dashboard has the 'standardization' item.

I thought Working draft was more strong reason to implement it. 

I'm very happy to know our stance. 

The maturity of the spec is definitely a useful signal.  But just because a more mature spec exists, doesn't mean we actually want to refer to that older snapshot of the spec when implementing.  I.e. if there's a WD from a few months back that contains the API then that's probably worth mentioning in terms of the interop risk (and so why the OWP labels ask for it), but if there was some difference between the WD and latest ED we generally expect that it's whatever is in the current ED that we'd want to ship.  Everything other than the ED reflects a historical snapshot which won't necessarily reflect the current consensus in the standards community.

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

[Yoichi Osato]

> Everything other than the ED reflects a historical snapshot which won't necessarily reflect the current consensus in the standards community.  

I see. We should follow what the community is currently in agreement.

2016年10月25日(火) 3:53 Rick Byers <rby...@chromium.org>:

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

[Harald Alvestrand]

Of course, ED won't necessarily reflect the current consensus in the standards community either, since the ED is likely to range a little ahead of consensus actually being achieved.

Most of the time, changes in the ED reflect changes in the community consensus.