Deleting selection gap painting

[Chris Harrelson]

TL; DR I would like to delete selection gap painting from Blink. Some more details are in this bug. I've also prepared a CL to remove it which leaves the code but puts the feature behind a run-time flag, in order to make this decision easy to roll back if required.

Details / background / rationale:

Selection gap painting is a feature where, when selecting content on a webpage, the gaps between content and the end/beginning of their containing line is highlighted. The easiest way to see the difference between having it and not is to try selecting some paragraphs of text on your favorite website in Chrome and in Firefox, and observe the visual difference. There is no actual difference in selected content, just its visual display.

The reasons why I would like to delete it are:

 * Slower painting code, due to painting extra space. In some cases this can be quite bad, or paint content multiple times.

 * Ugly / buggy looking display on many websites that have non-trivial layout. For example, observe incorrect gaps in bullets and double painting on http://en.wikipedia.org/wiki/Main_Page [ Press Ctrl-A to select the whole page].

 * Added code complexity, including storing extra state.

It can also be argued that selection gaps painting confuses the user, because the gaps are not actually selected.

As I understand it, selection gap painting originally was in Chrome because of WebKit, which was in turn driven mostly by OS X concerns, and OS X has a UX standard for selection gap painting in apps. Linux and Windows do not have this standard. Android has the same standard as OS X, but selection is in practice much smaller and simpler on a mobile device due to the way touch interactions work.

Please let me know if you have strong concerns with this proposal. Thanks,

Chris

[Emil A Eklund]

+1, I'm strongly in favor of this proposal.

Selection gap painting adds a lot of complexity with little upside,
especially considering the ugly rendering it results in on many
websites.

[Ian Vollick]

It would be great if we could get rid of this. Selection gap painting adds complexity to the compositor integration in addition to painting.

[Christian Biesinger]

+1 this behavior always seemed strange to me

[Philip Rogers]

I also support this change. Here's a visual example of the difference:

With selection gaps:

Without selection gaps:

​
​

[Paul Irish]

Another screenshot of more localized text selection..

On Tue, Mar 31, 2015 at 4:26 PM, Christian Biesinger <cbies...@chromium.org> wrote:

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

[Steve Kobes]

I think painting the selection gaps improves the visual appearance, and (from experience) it is not that hard to fix the cases that are broken.  But it probably does add more complexity than it is worth.

So... +0.5.

On Tue, Mar 31, 2015 at 4:26 PM, Christian Biesinger <cbies...@chromium.org> wrote:

[Adam Klein]

This seems like more of a Chromium UX question than a blink-dev question. Have you brought this to the folks who focus on Chromium UX?

[Nico Weber]

On Tue, Mar 31, 2015 at 4:34 PM, Paul Irish <paul...@chromium.org> wrote:

Another screenshot of more localized text selection..

The "after" effect looks very out of place on OS X to me.

[Yoshifumi Inoue]

+99

I filed this issue as http://crbug.com/402772 last year. But, chrome-UX team refused to fix at that time. (T_T)

Once we can get rid of selection gap, we can also simplify selection handling code in LayoutView.

2015年4月1日水曜日 8時08分54秒 UTC+9 Chris Harrelson:

[Nico Weber]

Sounds like there already was a decision to WontFix that bug, and to instead try and simplify this code.

[Ojan Vafai]

Do we really want to move away from matching mobile? I think that makes just removing this behavior a deal breaker. Although, like Adam, I'm curious what Chrome UX folks think of this.

There's also some UX issues here that don't just have to do with painting. Without selection gaps, you can't tell if you have a newline or line-wrapping point selected, e.g. the attached case doesn't clearly indicate what is selected. This is particularly problematic when doing editing.

[Shezan Baig]

The other case where I think selection gaps are useful is when selecting table cells, especially when editing.  Without selection gaps, its difficult to tell the difference between (a) selection that ends at the last character in the cell, and (b) selection that extends into the next cell.

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

[Peter Kasting]

On Tue, Mar 31, 2015 at 7:17 PM, Ojan Vafai <oj...@chromium.org> wrote:

Do we really want to move away from matching mobile? I think that makes just removing this behavior a deal breaker. Although, like Adam, I'm curious what Chrome UX folks think of this.

As one of the last remaining Windows engineers: at least on Windows, we absolutely should not paint selection gaps.  It feels extremely non-native in a noticeable way.  The linked bug referenced Material Design guidelines, which should not outweigh platform-native text-handling behavior.

There's also some UX issues here that don't just have to do with painting. Without selection gaps, you can't tell if you have a newline or line-wrapping point selected, e.g. the attached case doesn't clearly indicate what is selected. This is particularly problematic when doing editing.

Normally on Windows this is indicated by a small extension of the selection if a trailing newline is selected, similarly to if there were an extra space after the line.  We should ensure something like this happens, because otherwise being unable to distinguish the cases you mention is indeed bad.

PK

[Alexandre Elias]

On Tue, Mar 31, 2015 at 7:17 PM, Ojan Vafai <oj...@chromium.org> wrote:

Do we really want to move away from matching mobile? I think that makes just removing this behavior a deal breaker. Although, like Adam, I'm curious what Chrome UX folks think of this

On Android, most text selection actually occurs within WebViews.  So, selection gaps being a "mobile convention" actually originates from WebKit.  If we change selection gap behavior in Blink, then Android L+ devices will automatically change selection behavior to match when they receive the next WebView update, maintaining consistency.  So personally, I wouldn't consider this a dealbreaker.

[Alexandre Elias]

Also, about mobile UX -- on iOS, a box-based selector is used which is philosophically well-aligned with selection gapping.  But on Android, selection works by dragging around "handles" representing the start and end of the selection.  The handles can only settle within or around characters; they'll pop to the nearest character if the user releases it at an invalid location.  Disabling the selection gapping would clarify where it's legal to put the handles, so I there's a UX case to be made it would be a mild improvement to disable the feature on Android.

[aga...@google.com]

On Tuesday, March 31, 2015 at 7:17:18 PM UTC-7, Ojan Vafai wrote:

Do we really want to move away from matching mobile? I think that makes just removing this behavior a deal breaker. Although, like Adam, I'm curious what Chrome UX folks think of this.

There's also some UX issues here that don't just have to do with painting. Without selection gaps, you can't tell if you have a newline or line-wrapping point selected, e.g. the attached case doesn't clearly indicate what is selected. This is particularly problematic when doing editing.

Note that the opposite is also true: when lines contain trailing whitespace (spaces, tabs, etc), painting the selection gaps hides this from the user. You can't tell if the tail of a line is hilighted because there are whitespace character there, or if it is hilighted just because we're painting to the end of the line.

Note also the Google Docs implements its own selection painting, and takes its cue from Microsoft Word (and thereby from Windows) and does not paint selection gaps.

[Daniel Bratell]

On Wed, 01 Apr 2015 05:56:53 +0200, Shezan Baig <shezb...@gmail.com> wrote:

The other case where I think selection gaps are useful is when selecting table cells, especially when editing.  Without selection gaps, its difficult to tell the difference between (a) selection that ends at the last character in the cell, and (b) selection that extends into the next cell.

I approve of removing the gap painter, but I think it's in place to check the selection rendering of thing like "trailing whitespace" and empty lines (<br><br><br>) because those things are tricky and they might have been assisted by gap rendering (not that I know exactly how it works).

The selection rendering is crucial for editing and when you edit a document such selections appear all the time as part of the work.

/Daniel