New issue
Advanced search Search tips

Issue 822967 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug


Participants' hotlists:
pbos-backlog


Sign in to add a comment

Unify all toolbar buttons sizes in all material modes on all platforms

Project Member Reported by afakhry@chromium.org, Mar 16 2018

Issue description

On my most recent browser actions buttons CL, pkasting@ suggested having a unified size for all toolbar buttons, which I think is a very good suggestion and will simplify the code a lot, but it will slightly change the existing behavior a bit:

- In the touchable chrome new design, we unified all button sizes to be 48x48 which is great, but for normal and hybrid modes, things are not unified. Consider the following:


For normal mode:
  1.a - buttons (back, forward, reload, home, menu) are 28x28 laid out side by side with no paddings.
  1.b - browser actions buttons are 28x28 with 4px paddings. By embedding the paddings inside the view's bounds (as suggested here: https://bugs.chromium.org/p/chromium/issues/detail?id=818034#c12), it makes the button 32x32.
  1.c - on Mac, browser actions buttons are 24x24 with 4px paddings. By embedding the paddings, the button becomes 28x28.

For hybrid mode:
  2.a - buttons (back, forward, reload, home, menu) are 28x28 with 8px paddings between each. If we embed the paddings, the buttons become 36x36.
  2.b- browser actions buttons are 28x28 with 8px paddings. By embedding the paddings, the buttons become 36x36, which matches (2.a) nicely.
  2.c - on Mac, browser actions buttons are 24x24 with 8px paddings. By embedding the paddings, the buttons become 32x32.

Given the above, I think we can unify the button sizes as follows for all platforms:
32x32 --> normal
36x36 --> hybrid
48x48 --> touchable.

But before, we need to check with someone from Chrome UX team.
 
Even in the meantime, we could have separate constants for overall size of toolbar buttons and toolbar action views, which in turn could return different values depending on the mode and OS.  This doesn't simplify today's behavior, it just moves LayoutProvider to returning overall button sizes instead of insets, which would be a step towards the above.

This is what I was actually suggesting.  The simplification above goes beyond that :).

Comment 2 by pbos@chromium.org, Apr 5 2018

Cc: pbos@chromium.org
Tangentially as I ran into this, using insets to size inkdrops has implications on dialog anchoring as the dialog attaches to the bounds of the view (inkdrop host).

Though to be fair, sizing the buttons to 28x28 which they actually are and having gaps have implications as smaller hit targets.

Sign in to add a comment