Re: [csswg-drafts] [css-ui-4] Make selection change behavior configurable

The CSS Working Group just discussed `Make selection change behavior configurable`, and agreed to the following resolutions:

* `RESOLVED: option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  Make selection change behavior configurable<br>
&lt;Florian> Github: https://github.com/w3c/csswg-drafts/issues/1317<br>
&lt;dael> github topic: https://github.com/w3c/csswg-drafts/issues/1317<br>
&lt;dael> Florian: User-select: none makes it impossible to select things. But also if something is selected somewhere else in the doc and you click in a user-select: none area the spec says this should not effect existing selection<br>
&lt;dael> Florian: I believe we picked this because in native UI there are often places that are inert.  However, someone has said they sometimes want the other way around where if you click in a user-select: none area it should unselect<br>
&lt;dael> Florian: Example for that I think was a FB page with posts. Post content is selectable, but if you click in the empty areas, like the margin around the post, people expect that to undo the selection<br>
&lt;dael> Florian: My original reaction was then don't use user-select:none However people that do app-like things do user-select:none on the root and make some small area selectable.<br>
&lt;dael> Florian: Maybe they shouldn't be doing that, but maybe there is a need. We should either flip the behavior or create the ability to do the two behaviors. What do people think?<br>
&lt;dael> fantasai: I don't think flipping makes sense. It seems there are two behaviors wanted here.<br>
&lt;dael> Florian: I think I agree flipping wouldn't be good. I'm less sure if we want 2 values or we recommend people don't do user-select:none on the root and instead selectively apply it.<br>
&lt;dael> Rossen_: Have we circled back witht he editing group and asked if they have any best practices for such scenarios?<br>
&lt;dael> Florian: We have not but could<br>
&lt;dael> Rossen_: I think they have reviewed these kinds of patterns. I don't think we should re-invent the wheel here. If they have a reocmmendation we should match.<br>
&lt;dael> Florian: I think it's fair to ask. I'm not sure we'llg et an answer as the editing TF is focused on content:editable that isn't primarily about selection. This is also used in non-editing places.<br>
&lt;dael> Rossen_: I don't disagree, but since editing is their charter I would expect most people would be expert in editing behaviors and use cases so they may have a recommendation. If they don't we're at square one.<br>
&lt;dael> Florian: Even if they do, this isn't about just editing so we may not want to jsut take it. We need to think about non-editing use cases. That's the majority of the use cases. This is about making tool bars and labels non-selectable so when people select somehting to copy/paste they don't get UI as well<br>
&lt;dael> Florian: It does interact with editing, but it's not limited to that<br>
&lt;dael> Rossen_: What are the options on the table?<br>
&lt;dael> Florian: 1) no change 2) change from current and make it so clicking in unser-selection:none undoes current section 2) have two values, one for each behavior.<br>
&lt;dael> Florian: Together with option 1 it comes with add a note about setting user-select:none on the root having undesireable behavior<br>
&lt;dael> Rossen_: What do people think? Can we live with #1?<br>
&lt;dael> bdc: From a designer perspective I feel this is a very minor issue I've never seen before. I feel we have everything in place to leave as-is. I would personally gow ith option 1<br>
&lt;dael> Rossen_: Thanks.<br>
&lt;dael> Rossen_: Other opinions or should we reasove?<br>
&lt;dael> Rossen_: Objections to option 1: no change and add a non-normative note explaining adding this on the root isn't a great pattern<br>
&lt;dael> RESOLVED: option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1317#issuecomment-310130977 using your GitHub account

Received on Wednesday, 21 June 2017 16:19:16 UTC