Clip or squash favicon, instead of hiding, when tab space decreases |
||||||||||||||||||||||||||||||||||||
Issue descriptionWhen tab width becomes less than the favicon width, the favicon is dropped and the first letter of the text label is shown. I think it will be better to show the favicon even if cropped, ideally centered in whatever space remains. The case is shown for Mac in [1]. I am also attaching screenshots of what happens to tabstrip when adding just one tab (from 21 to 22). Note - this is a small corner case of issue 188 but I felt this could be taken on separately if necessary. [1] - https://motherboard.vice.com/en_us/article/leave-chrome-for-opera
,
May 16 2017
,
May 16 2017
There are some other exploration into making tabs more usable at smaller sizes, eg https://docs.google.com/presentation/d/17_AjeagqThCof_LG1ApE8hqhFBJ-M_12mGgK_pcvkng/edit ccing designers who are thinking through this. Please don't implement favicon squishing just yet. :)
,
May 16 2017
That article comes right on time, I was putting together come thoughts around this since pkasting pointed me to bug 188. The screenshots from varkha@ show how less recognisable the tabs are when you switch from favicon to 1/2 letters from the title. Sticking to favicons keeps the tab identifiable. Adding other reference screenshots from Vivaldi and Opera, where overlapping icons.
,
May 16 2017
Note that bug 722927 covers the tab shape exploration in comment 3. I think this bug and that one are largely orthogonal, though they should be considered cohesively. My suggestion is that we find someone interested in doing the engineering here and just start playing with this, to avoid the possibility that we navel-gaze too long (as we've arguably done already) :)
,
May 16 2017
#5, that was exactly my motivation for filing this separately. I think there are some low-hanging fruits here.
,
May 24 2017
Issue 637343 has been merged into this issue.
,
Jan 19 2018
Friendly ping to see if there is an engineering, or if we can get eng support to work on this for Mac and Views. This would be a much appreciated change to those users with lots of tabs and buys some time before future tab efforts land. I'm willing to provide UX support, prototyping, as part of on going tab efforts. If we use the starting point of just showing the favicon and clipping it (without shaping it to the tab), then we can refine from that.
,
Jan 19 2018
PK, would it make sense for you to also take this?
,
Jan 20 2018
Yeah, probably. This would be a lot easier for a new person to tackle than dynamic tab shape would, though, if we're looking for such opportunities.
,
Jan 20 2018
I was hoping that someone else could do this bug so pkasting can focus on the shaping. Also because this isn't contingent on the tab shaping part and we should really have shipped this last year!
,
Jan 24 2018
Hello everyone! If you don't mind i'd like to work on this. May I?
,
Jan 29 2018
Though I did't get any response yet, I implemented this roughly. In the process, I find that we need to give some thought to throbber too. Which way is better, clip or squish? Please give me your opinion :) Here's CL to test this https://chromium-review.googlesource.com/c/chromium/src/+/890696
,
Jan 29 2018
Thanks, Seems like in your screenshot the favicon is clipped but the loader is squished. I need to patch your CL to test but immediately we shouldn't squash the progress spinner. @pkasting since tab shaping is on hold for now, did you want to take this on, or guide Sangwoo108?
,
Jan 29 2018
I'm happy to provide guidance. My suggestion for now is: * Clip both icon and throbber, rather than squashing * Clip the edges equally (leaving the center section), rather than clipping off the trailing edge Bonus points: * Allow the icon to eat the padding even into the "slanted" area, and clip to the tab shape (there's already a path you can use to clip to, so the clipping itself should be trivial here; the tricky bit is the positioning logic).
,
Jan 29 2018
I would suggest fading to a clip rather than an abrupt clip (whether that clip is vertical or matches the tab shape).
,
Jan 29 2018
I agree that a couple-pixel fade will look even better especially in the tab-shape-clip case; we can implement that as an enhancement. We already fade text this way today, so it shouldn't be too hard to do something similar.
,
Jan 30 2018
@edwardjung Exactly :) @pkasting, @est Thank you for guidance. I'll do my best :)
,
Jan 31 2018
The fading actually looks weird to me because it's implemented as fading the right side (but not the left), and it fades on a horizontal gradient but we clip to a diagonal tab edge, so the top doesn't actually get faded at all while the bottom fades "too early". I think if we're going to fade, we'd need to do it at both edges, on diagonal gradients that match the tab slope. This is nastier to implement than I thought it would be, so it probably makes sense to punt it (unless you think you know how to do it easily). Even without this fading, I think the clipped favicons look surprisingly (shippably) good. Edward, WDYT?
,
Jan 31 2018
[@pkasting, I assigned it to you for the moment as sangwoo108@ isn't a project member] @sangwoo108 could you update your CL so we can patch to get an a better feel how this looks in the not so extreme cases. Also wanted to check the throbber animation when clipped. My immediate reaction was I was expecting some inner padding to the tab itself so the favicons don't merge into each other. I don't know how this would look with 1dp or 2dp padding. Fading: agree with pkasting the fading needs to match the angles of the tab on both sides if we we're doing this. I would like to compare no fading but with some padding and the fading option. Overall this is a way better state than we have now, but I don't want that to be the bar we're setting ourselves. Would also like to get this front of our visual designers for any other thoughts they may have.
,
Jan 31 2018
@21: By "inner padding", I assume you mean "following the contour of the tab edge? That will be trickier to implement, since we don't want to inset every edge, but only the sides. That is, we'd want "padding" to work a bit like the proposal for "fading" I give above, but with a hard transition instead of a blended one. I can think how to do that (by changing the function that computes the fill path), but getting some of the details right could be nontrivial. And actually, I'm not sure that'll do as much as you think, since when tab A is atop tab B, tab B won't have any padding "outside" the edge of tab A that overlaps it, but will be clipped by it directly. I'm a little worried as well about "when in this state, we should maximize information density, even at the cost of visual cleanliness, since that keeps it maximally usable". Losing even 1 dp off each side of an already-clipped favicon seems like a meaningful usability cost. I would certainly like to see this with padding just to see how big a deal the above is, I just don't know whether it will be simple to implement.
,
Feb 1 2018
@edward Sure. You can patch clip + fade version from https://chromium-review.googlesource.com/c/chromium/src/+/890696 and clip only version from https://chromium-review.googlesource.com/c/chromium/src/+/897022 (The second one is only for testing) As for throbber, I guess it might not be clipped when it has own layer. But it seems perfectly fit in tab for me when it's centered. Please check it out and let me know if throbber needs further work :) @edward @pkasting * Fading : It certainly looks weird to me too. Let me try fading both side along tab's shape. I think I can sort out this. * Padding : I'm not sure I can do that easily but let me try this too. * I didn't looked into cocoa yet, but when views implementation finishes, I'll try that too.
,
Feb 1 2018
Attach some pictures to share progress in "Diagonal fading" * Fading starts from both side on top. * Fading width can be different according to tab's width.
,
Feb 1 2018
I think we can get away with more of a fade from both sides. Or possibly adjusting the fade so that it's full opacity along the edges and more quickly get's to 0 opacity. Thanks for making progress so quickly. I'll try out the CLs today when I get the chance. One additional request, once we're happy with some options (maybe fade, padding, straight clipping), would it be possible to get them behind a flag, for more folks to try.
,
Feb 1 2018
@edward Yes. The fade is too faint, isn't it? Let me tune this. Thank you for pointing this out. As for flags, I totally agree with you. I've been thinking about it too :) I think it won't take long.
,
Feb 2 2018
@Sangwoo, I met with Alan our visual design and went through the current implementation with the various options we are exploring. The faded version felt the best to him if can refine this a bit more. The straight clipping feels too sharp. The only option we would want to look at is a padding one without fading. Thanks for your efforts on this.
,
Feb 2 2018
Re: To clarify the padding option. This is where a straight clip happens against an insetted tab shape. The padding I'm thinking is minimal - 1dp or 2dp. Actually there was another option that Alan raised, which was to shrink the whole favicon to the available tab space. Given the low fidelity of favicons, I wonder if the favicon would be completely unrecognisable at 8dp x 8dp.
,
Feb 2 2018
#28, I think shrinking icons will look worse than what's in the recent screenshots here. Also I suspect the tabs layouts are independent from one another and so special care would need to be taken not to have different favicon resolutions for adjacent tabs at some window widths. Separately I've noticed that sometimes the close tab icon gets misplaced when opening lots of tabs, probably a separate bug that has to do with the assumption that the tab having a close button has some minimum width. Awesome progress, can't wait to see this in action!
,
Feb 2 2018
@29: Misplaced close button is a known bug on file elsewhere. I agree that shrinking the tab favicons will look worse than all other options.
,
Feb 3 2018
@varkha Thanks :) Current state: Now you can try these via chrome://flags . Please check out a flag named "More recognizable tab". There are several options. - Default(Clip only) - Clip with padding - Fading - weak - Fading - Strong (Opacity drops to 0 twice faster than "weak" above) - Scale (For Alan's suggestion, hope I didn't misunderstand his request) https://chromium-review.googlesource.com/c/chromium/src/+/890696
,
Feb 5 2018
Thanks for the update. The flags selection is very welcome. + The fading on both the weak and strong seem to overlap into the icon too much causing it to be faint. Are the fades from each side intersecting causing this? Could the fade width be narrower or adjusted based on available width? Only a slight adjustment from your initial implementations is required. + Scaled version, clearly doesn't work very well the favicon is too pixelated to be distinguishable. + Clip with padding - the diagonal clipping is jagged, losing an extra pixel from each edge makes it slightly less identifiable at the extreme case where the favicon becomes a triangle. However it feels neater as the favicons don't merge into each other so I'm . For me the clip with padding and a more refined fading would be the options to consider. We can remove the strong version of the fade.
,
Feb 5 2018
@edwrad Thank you for the feedback * Fading: Yes, The fading from both side can cross as they have fixed width(as wide as tab's padding, so they can intersect at the top). I guess making it narrower is not that big like you guessed. For now, Their width is related to padding for a tab. I'll try to make it aesthetic. * Clip with padding and jagging: Maybe it's just a matter of antialiasing. Let me try this.
,
Feb 6 2018
@edward I tried to make fading better. Fading starts at the same point of initial version and fading width is narrower. And fading start point is affected by available capacity, Fading looks slightly different. If you're satisfied with this version, I'll update my CL. And I applied antialiasing to clip. This looks much better. Thank you :)
,
Feb 6 2018
Thanks, the screenshots look better. The fading still makes the favicon look desaturated, maybe the fade width needs to be scaled / positioned back a few pixels more. If you could update the CL I can check more closely. @pkasting any preferences. I'm siding with the straight clip with padding.
,
Feb 6 2018
I like the clip with padding best, but I think the amount of padding there is too large. The proportions on the screenshot don't match 1x or 2x on my system so it's hard for me to tell what padding it is. It looks as if that's maybe 1.5x with 2-3 DIP of padding? I'd like to see 1x and 2x screenshots with 1 DIP of padding. I could probably generate this locally, I just don't have time to patch the CL in and play with it at the moment.
,
Feb 7 2018
Agreed, 1dp padding may look better. @sangwoo could you make the requested changes for a 1dp padding.
,
Feb 7 2018
@peter You're right. The screenshots above were taken where DPI is 1.5x and padding was 2. @peter @edward Here it is. I think 1 dip padding gives us more recognizable favicon as you expected. I attached 4 files with different dpi and padding so that you can compare them. And I also made fading narrower. Though clipping and fading look quite similar, they are slightly different according to DPI and available width. So I've updated CL. I hope you check it out if you have time. Thank you :)
,
Feb 7 2018
1dp padding looks great. The fading option is improved at the smaller sizes, but at the wider widths it seems to start too early and obscures too much of the favicon shape. I don't think we need to tweak any more. I'll ask UI review to see if we want to experiment, but I'll be happy to get this in with the 1dp padding on by default. Attached some extra 1x screenshot (done through remote desktop).
,
Feb 7 2018
Does this also work for Mac because I don't see a chrome flag for mac it's only unix and windows? Is there any work to be done for it to work on mac?
,
Feb 7 2018
Re: #40 The code isn't checked in yet, but also it's views only so will be for Windows, Linux and CrOS for now. A separate implementation for Mac would be required.
,
Feb 8 2018
@edward Thank you. Please let me know when the decision is made. Then I'll do clean up and restart code review process with @peter :) One question, It's okay to remove flags and fading version, isn't it?
,
Feb 8 2018
@41 Can you show me the file where the mac version will be implemented if it doesn't require Objective C/Swift I can implement it myself. I really want this feature on Mac.
,
Feb 8 2018
Re #41: The implementation will be in Objective C. We hope to be able to get this onto Mac too.
,
Feb 8 2018
,
Feb 10 2018
Re: #42 SangWoo, we have approval for the clipping with 1dp padding. Yes please remove the experiment and fading code. Thanks and appreciate your work on this.
,
Feb 14 2018
,
Feb 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6a306a35961de0cbdd5eebc12dbb43a54f8ab939 commit 6a306a35961de0cbdd5eebc12dbb43a54f8ab939 Author: sangwoo.ko <sangwoo108@gmail.com> Date: Wed Feb 14 23:04:39 2018 Show favicon even if there's no enough space In this case, we will do: 1. Align favicon ceter. 2. Clip favicon to the tab's shape with 1 DIP padding. Bug: 722841 Change-Id: Ie69c7135a560a57656e8b777009b9fa04c00cc1f Test: TabTest.LayoutAndVisibilityOfElements Reviewed-on: https://chromium-review.googlesource.com/890696 Commit-Queue: Peter Kasting <pkasting@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#536862} [modify] https://crrev.com/6a306a35961de0cbdd5eebc12dbb43a54f8ab939/chrome/browser/ui/views/tabs/tab.cc [modify] https://crrev.com/6a306a35961de0cbdd5eebc12dbb43a54f8ab939/chrome/browser/ui/views/tabs/tab.h [modify] https://crrev.com/6a306a35961de0cbdd5eebc12dbb43a54f8ab939/chrome/browser/ui/views/tabs/tab_unittest.cc
,
Feb 15 2018
Great work Sang Woo. Thanks being so responsive to our comments! We now need to see if there is someone able to get the same thing done for Mac.
,
Feb 15 2018
@49 Can you give me the googlesource URL for the Mac file that needs to be changed?
,
Feb 15 2018
Re 50: I suspect tab_view.mm https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/tabs/tab_view.mm?sq=package:chromium&dr
,
Feb 15 2018
@Peter @Edward My pleasure :) @50 I guess these two files should be changed too. * https://cs.chromium.org/chromium/src/chrome/browser/ui/tabs/tab_utils.cc?q=tab_utils.cc&sq=package:chromium * https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/tabs/tab_controller.mm?q=tab_controller.mm&sq=package:chromium&l=1 |
||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||
Comment 1 by pkasting@chromium.org
, May 16 2017Status: Available (was: Untriaged)
Summary: Clip or squash favicon, instead of hiding, when tab space decreases (was: Favor favicon when tab width becomes small)