it's unfortunate that UI review believes (basically) that <select> is not very touch-friendly, as this affects all of the web.

Yeah. The UI provided by <select> is under our control. If UX thinks it's bad for touch we should fix it at the platform level.

Indeed the menu that shows up when I click a <select> looks nothing like the menu that appears when I click the three dots on Chrome OS. Those two menus should look the same though in terms of spacing, highlighting, etc.

<select> should feel "platform native".

esprehn@: the general gripe was that the touch targets can't be enlarged by changing padding, but only by font-size (I haven't verified this myself)

I don't think the author should be expected to make the menu look different for touch. The OS should handle that, the same as we adjust Chrome OS UI to be touch friendly.

Please specify OS.
We have four different SELECT popup menu implementations.

1) Windows, Linux, CrOS
2) macOS
3) Android phone
4) Android tablet

Maybe this issue is for 1?  It's possible to add more padding for touch-enabled device in 1.  We have similar conditional styling in <input type=date>.

Yep, this is for #1, specifically Windows/CrOS touch devices. How can we enable the additional padding on those devices?

We can add style for touch-enabled devices by adding

@media (any-pointer:coarse) {
 ...
}

to third_party/WebKit/Source/web/resources/listPicker.css, or
  matchMedia('(any-pointer:coarse)').matches
to listPicker.js.


> We have similar conditional styling in <input type=date>.

I found this didn't work well on touch-pad + touch-screen devices. calenderPicker.js incorrectly uses '(pointer:coarse)' query.

Hi tkent@, we're confirming with UI Review but it sounds like we may just change the <option> height for all Chromebooks, not just those with touchscreens.

Here's the new spec for row-height:
- The minimum height of each option should be 32px.
- There should be 4px of top/bottom padding separating options.

See example: http://jsbin.com/yidisef/edit?output

At the same time can we make the styling of the drop down look like the chrome menu (white background, blue highlight, soft borders, etc.) instead of being grey and looking like windows 95? :D

esprehn@: unlikely in the 1.5w that we want to launch settings in

good idea otherwise.  i suspect you'll get a bit of pushback, but hopefully most folks are styling it themselves anyways.

You can't style it yourself, we don't let you change things like that. Also why would there be push back for making the select menu look like the rest of Views?

We're after feature freeze for M59, so we're only look at dropdown touchability because it was a launch-blocking request from UI Review.

@sgabriel and I were talking about a few other improvements we'd like to make (including colors), so let's track that in Issue 708415

> we're confirming with UI Review but it sounds like we may just change the <option> height for all Chromebooks, not just those with touchscreens.

So, we apply this style only on CrOS, and popups on CrOS and Linux should have different appearance, right?

HTML/DOM team takes this.

I think we should make this uniform on all platforms that use the HTML menu. There should be two appearances, the Mac native one and the Views one that matches what the triple dot menu did.

> See example: http://jsbin.com/yidisef/edit?output

The page says:
> Default left/right padding: 12px (though developers can override)

The horizontal padding in popups should be same as paddings of <select> box on the page.
Should we change the default paddings of <select> box on the page?  Only for CrOS?  It looks weird to me.
If not, popup rendering result looks inconsistent with <select> box.

esprehn, let's discuss it in Issue 708415.

Agreed that we should keep the horizontal padding in the <select> box and the popups consistent.

Could you share a screenshot of a dropdown with 12px horizontal vs the default (is it 4px?)? If 12px looks strange we should be able to keep 4px for now, and change horizontal padding as part of Issue 708415.

Attached a screenshot with a WIP change.

* Left side of text in SELECT and OPTION texts are not aligned.
* The popup extends over the right side of SELECT because of 12px padding-right.

Deleted: Screen Shot 2017-04-07 at 14.55.19.png 35.5 KB

	Screen Shot 2017-04-07 at 14.55.19.png 35.5 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/112094796a99ff35f551467912814d08935b6055

commit 112094796a99ff35f551467912814d08935b6055
Author: tkent <tkent@chromium.org>
Date: Mon Apr 10 08:24:02 2017

SELECT popup: Make OPTIONs taller for touchscreen.

On Windows and Linux:
If a touchscreen is connected, OPTIONs in SELECT popups have 8px paddings and at
least 24px height in order to make it touch-friendly.

On CrOS:
Apply the taller OPTIONs regardless of existence of touchscreen.

On macOS and Android:
This CL has no effect.

BUG= 703971 

Review-Url: https://codereview.chromium.org/2810583002
Cr-Commit-Position: refs/heads/master@{#463194}

[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/content/child/runtime_features.cc
[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/LayoutTests/fast/forms/select-popup/popup-menu-appearance-coarse.html
[add] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/LayoutTests/platform/linux/fast/forms/select-popup/popup-menu-appearance-coarse-expected.png
[add] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/LayoutTests/platform/linux/fast/forms/select-popup/popup-menu-appearance-coarse-expected.txt
[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/Source/web/PopupMenuImpl.cpp
[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/Source/web/WebRuntimeFeatures.cpp
[modify] https://crrev.com/112094796a99ff35f551467912814d08935b6055/third_party/WebKit/public/web/WebRuntimeFeatures.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50618404a0eb5e2a3acb99144907ee0484a08a44

commit 50618404a0eb5e2a3acb99144907ee0484a08a44
Author: Rebaseline Bot <blink-rebaseline-bot@chromium.org>
Date: Mon Apr 10 17:02:58 2017

Auto-rebaseline for r463194

Build: https://build.chromium.org/p/chromium.infra.cron/builders/rebaseline-o-matic/builds/658860

https://chromium.googlesource.com/chromium/src/+/112094796a99f

BUG= 703971 
TBR=tkent@chromium.org

Review-Url: https://codereview.chromium.org/2808903002 .
Cr-Commit-Position: refs/heads/master@{#463298}

[modify] https://crrev.com/50618404a0eb5e2a3acb99144907ee0484a08a44/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/50618404a0eb5e2a3acb99144907ee0484a08a44/third_party/WebKit/LayoutTests/platform/win/fast/forms/select-popup/popup-menu-appearance-coarse-expected.png
[rename] https://crrev.com/50618404a0eb5e2a3acb99144907ee0484a08a44/third_party/WebKit/LayoutTests/platform/win/fast/forms/select-popup/popup-menu-appearance-coarse-expected.txt

Is the color difference between touch and non-touch intentional?

Deleted: touch_select_different_color.png 2.0 KB

	touch_select_different_color.png 2.0 KB View Download

Deleted: normal_select_color.png 1.8 KB

	normal_select_color.png 1.8 KB View Download

> Is the color difference between touch and non-touch intentional?

They should have no different colors.  What platforms did you take the screenshots on?

> What platforms did you take the screenshots on?
Linux

> > What platforms did you take the screenshots on?
> Linux

I guess you compared Chromium browser and content_shell. They have different default color theme.

I used a Linux build (not ChromeOS for Linux).
1) Opened a dummy <select> took screenshot.
2) Then opened devtools, turned on "Device mode" to emulate touch
3) Refreshed the page.

I hope this clarifies the repro steps. Does that mean I used content_shell (I don't know)?

> 2) Then opened devtools, turned on "Device mode" to emulate touch

Oh, I see. The color difference is a bug of Device mode, and the difference has existed even before r463298.  We won't see such difference with real devices.

9534.0.0, 60.0.3092.0