I'm all for unifying, the current state has two issues for me which I addressed in my spec:

- The touch target ripple touch one another when hovering the bar
- The spacing between bookmarks looks bigger than the spacing between the label and favicon within a bookmark.

I'm more than happy to have bigger spacing between them, as long as the concerns above are addressed.

Hmm... having the hover areas touch is kinda desirable insofar as

- We want the actual hoverable areas to touch so there's no "dead zones" that don't activate anything, to eliminate misclicks
- It's nice to have the visible and actual hover areas match, so we don't have the odd "item you're not pointing at is getting activated anyway" state

It also might be tricky to code insetting the hover effect from the true borders, maybe not too hard though (I haven't seen any CLs yet that try it).

I don't think the above are dealbreakers, just reasons why the current behavior may be a win.

That said, I think making the hover targets touch or not is mostly orthogonal -- we can implement that independently of the concerns here.

I see bookmarks as button rather than just layout surfaces, I'm not concerned by missed targeting. If that's an issue we should make them bigger but keep some space in between. If insetting hover effect is not possible to extend the touch target, limiting the touch target is fine. 

In addition, having them against one another does not work well with rounded corners, creates weird effects at the angles.

So are you saying that there _should_ be a dead zone between the buttons that doesn't trigger mouse hover of anything?

We've striven to avoid that elsewhere in our UI (e.g. between the toolbar buttons), including escalating back to designers when it tries to sneak in.  The issue isn't that the button targets themselves aren't big enough to click but that when the buttons don't have visible borders in the non-hovered state it's frustrating to have a lot of area that's clickable but a small amount of area that's not -- users expect that whatever their mouse is closer to should be activated.

I think it would be better to violate the second of my bullets (and activate things where the pointer doesn't appear to be over the hovered item) than to violate the first (and have true dead zones).

Hopefully the "adjacent rounded corners" thing isn't a problem since only one item would be visibly rounded at a time, but if it is, then insetting just the hover region and not the actual button size should address that.

Again, though, this might be tangential for this bug.

>We've striven to avoid that elsewhere in our UI (e.g. between the toolbar buttons), including escalating back to designers when it tries to sneak in.

Not sure what you mean, right now if you have your mouse between the back and forward button in the toolbar, there is not hover and it's a dead-zone and their hover don't touch. I just want the bookmark to behave the same way.

That's not true on Windows at least.  What platform are you testing on?  I don't vouch for bug-free top chrome on any non-Windows platform since the rest of them get only token investments :)

On Windows we currently have inset hover effects, but the activation regions touch.  We also take care to extend the activation region to the window edge when maximized.

> That's not true on Windows at least.  What platform are you testing on?
I see what's happening. You are testing on normal, I'm testing on Hybrid. Activate the flag on windows, you'll have dead-zone between your toolbar icons.

Happy to try insetting ripple with touching touch targets.

Ah, interesting that we inserted padding in Hybrid.  We just had some discussion on GM2 last week in which we noted that we can't just insert padding between toolbar buttons :).

I'd file this as a bug against Hybrid, but since Hybrid is kinda EOLed, it seems like it'd be a waste of effort.

> Ah, interesting that we inserted padding in Hybrid.  We just had some discussion on GM2 last week in which we noted that we can't just insert padding between toolbar buttons :).

Well I'd say this is an assumption that it wouldn't work, it obviously did because we I've never heard of issues with our current padding in Chrome OS. You'll ultimately run into this as Chrome touch is revamped for 10th bday. 

Nevertheless, I'd like to move forward and unblock Malay on bug 810902 as this is time sensitive. Chrome can then do whatever with the bookmarks bar behavior.

Like I said, we already made sure this isn't carried forward into the GM2 revamp.

This whole discussion doesn't block anything on this bug in any case.

Sorry then missed the point of this bug if we're going to re-implement bookmarks in GM2 anyway :)

We're not reimplementing bookmarks in GM2.  The GM2 discussion was related to toolbar buttons.

The point of this bug is to get Harmony, which affects all desktop platforms including CrOS today, to agree with the touchable spec on how to do bookmark bar padding.

Pinging this bug. I'd like to find resolution on this for M67 and Chrome tablet as the current implementation looks pretty bad. The positionning of the folder is confusing, hard to know if it belongs to the previous label or following label.

I'd like to find a solution to get tighter padding between header icon and label.
@Alan, would you be ok with 8?

Thanks

Deleted: Screenshot 2018-04-04 at 11.25.36 AM.png 616 KB

	Screenshot 2018-04-04 at 11.25.36 AM.png 616 KB View Download

I'm OK with 8dp in the areas of concern (same is proposed in GM2), but I'm not OK with making that a global change throughout our UI. 12dp is still desirable in a few areas (in Harmony and GM2) so I recommend we remove the dependencies between favicon+label and control+label. It doesn't make sense (from a design POV) to keep them interdependent. 
 

8dp spacing should be used for: 
- favicon and page title
- bookmarks bar

12dp spacing should be used for: 
- radio/checkbox controls
- icon to label

Over to pkasting. LMK if that's possible. 

Deleted: 12dp_control_to_label.png 76.8 KB

	12dp_control_to_label.png 76.8 KB View Download

Deleted: 12dp_pageInfo.png 104 KB

	12dp_pageInfo.png 104 KB View Download

Deleted: 12dp_radio-to-icon.png 44.5 KB

	12dp_radio-to-icon.png 44.5 KB View Download

Deleted: 8dp_GM2.png 190 KB

	8dp_GM2.png 190 KB View Download

Thanks a lot Alan.

Kicking this to Bret partly as load balancing and partly because he did the previous work in this area.

Delegating

Elly is implementing some bookmark bar padding/spacing changes on  bug 826264 .  It's not clear to me what this bug covers that's not being done in that bug.

There's also the general  bug 822072  here.

Agreed, if anything wasn't covered there please reopen, file something new against me or use  issue 822072 . :)

That should do it. Thanks :)