search

w3c / selection-api

Selection API
http://w3c.github.io/selection-api/
Other
47 stars 30 forks source link

Triple-click selection bounds #70

Open caub opened 8 years ago

caub commented 8 years ago

Browsers have all a different behavior with triple-click, as mentioned here. Is there plan to specify it?

rniwa commented 8 years ago

In general, the behavior on what selection the browser creates (or lack thereof) upon user actions such as click is implementation dependent. I don't think there is much we can spec about it since each browser is constrained by the underlying operating system in terms of UX and limitations.

mlewand commented 6 years ago

The problem here is that in issue mentioned by @caub Chrome / Webkit is expanding the selection outside of a block element - which does not make sense. Upon bringing it up, browser vendor ignores the problem saying that the behavior is not specified. This lead to poor interoperability between the browsers.

browser is constrained by the underlying operating system in terms of UX and limitations

I don't think this is the case here, as other browser vendors (Mozilla, Microsoft) handle that correctly.

Reinmar commented 6 years ago

This problem is much deeper. It's not only about triple click but also about making a whole-line selection by mouse. In such case, the selection may also span outside the block that you're trying to select. This wouldn't be such a problem if all browsers were rendering EOL selections in a visible way.

E.g. this is the same selection in Chrome and Safari:

image

image

In both cases, I did it by mouse. But the same happens on triple click. And while we could standardize triple click's behaviour, the problem would remain, because an RTE still needs to handle selections made by a mouse.

Finally, we can't completly get rid of such selections:

<p>[xxx</p>
<p>]yyy</p>

Because we need to support shift+left/right which allows you to toggle between the above and:

<p>[xxx]</p>
<p>yyy</p>

I also checked how EOL selection looks in Pages (native) and Google Docs (custom selection rendering):

image

image

GDocs does the same thing like Chrome – it extends the end of the selection rect ~20px to the right when you add EOL to the selection. Pages renders a pilcrow there.

PS. In most RTEs (I checked CKEditor 5, GDocs, Pages) applying a block format (e.g. a heading) to the below selection affects only the first block:

<p>[xxx</p>
<p>]yyy</p>

Which, IMO, is a thing that needs to be implemented by the RTE itself. A block at which boundary the selection ends, should not be affected by such commands.

chinanderm commented 4 years ago

Ran into this issue today while testing in Chrome. Safari and Firefox don't have this issue.

Any update?

rniwa commented 4 years ago

I don't think this is something we can solve by a specification change. Different browsers on different operating systems are going to have different behaviors because what click, double click, etc... do on different operating systems are different.

chinanderm commented 4 years ago

@rniwa Thanks for the quick response. Unfortunately, the Chromium team is blaming the lack of spec from the W3C as an excuse for not fixing their issue.

rniwa commented 4 years ago

@rniwa Thanks for the quick response. Unfortunately, the Chromium team is blaming the lack of spec from the W3C as an excuse for not fixing their issue.

I'm not sure "fixing their issue" is the right way to phrase it this way. I understand the behavior Chrome exhibits is different from what you want, that doesn't necessarily mean it's a bug. They might have intentionally implemented their current behavior.

Regardless, I don't think we can ever specify what happens when a triple-click happens because whether the line break is selected or not is one of primary behavior differences between macOS and Windows, and it's not something that's going to change in either operating systems.