Closed Bug 350690 Opened 18 years ago Closed 18 years ago

tab images should be semi-transparent so that they work with the OS theme and high contrast mode

Categories

(Firefox :: Tabbed Browser, defect)

2.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2

People

(Reporter: dao, Assigned: moco)

References

Details

(Keywords: fixed1.8.1, Whiteboard: [Fx2 theme change])

Attachments

(12 files, 29 obsolete files)

79.75 KB, image/png
Details
25.48 KB, image/png
Details
29.50 KB, image/png
Details
428 bytes, image/png
Details
3.12 KB, application/x-gzip
mconnor
: review+
Details
127.71 KB, image/png
Details
9.20 KB, patch
mconnor
: review+
mconnor
: approval1.8.1+
Details | Diff | Splinter Review
47.73 KB, image/png
Details
36.76 KB, image/png
Details
54.70 KB, image/png
Details
48.58 KB, image/png
Details
38.89 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060829 Minefield/3.0a1 Build Identifier: tab-*-bkgnd.png and tab-*-hover.png are 100% opaque. This way the tabs won't match the OS theme. Reproducible: Always Actual Results: attachment 236060 [details] Expected Results: http://wiki.mozilla.org/FX2_Visual_Update/Default_Theme_Update
Flags: blocking-firefox2?
Version: unspecified → 2.0 Branch
Blocks: NewTheme
Whiteboard: [Fx2 theme change]
Summary: tab background and hover images should be semi-transparent → background tab images should be semi-transparent
I second this. Some transparency similar to the Go/Search button would help match the theme color. This is especially important since the Toolbars will still derive the native color (as they have not been given colors matching the tabs). As a result the Toolbars and Tabs will look highly disjointed as far as their colors are concerned. In such a scenario the Tabs, even if not completely, should atleast have shades of the native theme (through some built in transparency) so that they don't look completely out of place. The new tab images are much much better by the way.
I think this should be duped against bug 348975. Dao, you happen to be the reporter of both bugs, can you tell how they are different?
(In reply to comment #2) > I think this should be duped against bug 348975. Dao, you happen to be the > reporter of both bugs, can you tell how they are different? This is a spin-off from bug 350139 and it addresses the background tabs only, whereas bug 348975 is about the whole tab strip.
Blocks: 348975
(In reply to comment #1) > I second this. Some transparency similar to the Go/Search button would help > match the theme color. > This is especially important since the Toolbars will still derive the native > color (as they have not been given colors matching the tabs). As a result the > Toolbars and Tabs will look highly disjointed as far as their colors are > concerned. > In such a scenario the Tabs, even if not completely, should atleast have shades > of the native theme (through some built in transparency) so that they don't > look completely out of place. > > The new tab images are much much better by the way. > I am having second thoughts about what I have written above. I just changed my theme from XP Royale -> Luna Blue -> Luna Silver -> Classic and Firefox looks pretty decent in all of these. And the new Tab as well as Tabstrip look pretty sexy. I also worry that with the transparency, their new look might be compromised.
> I am having second thoughts about what I have written above. I just changed my > theme from XP Royale -> Luna Blue -> Luna Silver -> Classic and Firefox looks > pretty decent in all of these. > And the new Tab as well as Tabstrip look pretty sexy. I also worry that with > the transparency, their new look might be compromised. Although the new tab strip looks great it looks pretty bad IMO on Classic. Transparency would look MUCH better then the current implementation (instead of the tab strip sticking out like a sore thumb). Please don't forget all of those users too. ~B
Assignee: nobody → sspitzer
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox2? → blocking-firefox2+
Summary: background tab images should be semi-transparent → tab images should be semi-transparent
Attached file new winstripe tab images (obsolete) —
screenshots coming
Attachment #236394 - Flags: review?(mconnor)
Attached image before / after screenshot (obsolete) —
Attached image before / after screenshot (classic) (obsolete) —
Blocks: 350689
(In reply to comment #8) > Created an attachment (id=236396) [edit] > before / after screenshot (classic) Before taking these screenshots, I applied changes to the tabstrip background as described in bug 350689 comment 6.
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=236396) [edit] > > before / after screenshot (classic) > > Before taking these screenshots, I applied changes to the tabstrip background > as described in bug 350689 comment 6. The tab strip background is still too dark. I don't believe we should deviate this much (if at all) from the native theme color. ~B
(In reply to comment #10) > The tab strip background is still too dark. Note that the proposed tab images are independent from the tabstrip background. To that effect, see also attachment 236402 [details].
*** Bug 350994 has been marked as a duplicate of this bug. ***
Setting target milestone. These new tab images are good. I wonder if mconnor et. al would be OK with a slight gradient applied to the hovered/active tab images as in the original mockup (from comment 0)? Your new inactive tab image looks really excellent, and the hovered and active images are definite improvements to the current images, but I feel like they could look even better.
Target Milestone: --- → Firefox 2
Attached file new winstripe tab images v2 (obsolete) —
Attachment #236394 - Attachment is obsolete: true
Attachment #236395 - Attachment is obsolete: true
Attachment #236396 - Attachment is obsolete: true
Attachment #236573 - Flags: review?(mconnor)
Attachment #236394 - Flags: review?(mconnor)
Attached image v2 screenshots (obsolete) —
Actually, these really don't help solve all of the issues I want to solve here. The approach that seems saner is to create the gradient effect only with the images, and then use the native background color on the tab itself. This ends up meaning we can get the right color of tab, with the effect we want, even if its white on black. Discussed this with Seth, and that's the path we're looking to take, since that also solves the high contrast issue. It should also look a lot better and closer to the app color.
(In reply to comment #16) > Actually, these really don't help solve all of the issues I want to solve here. > > The approach that seems saner is to create the gradient effect only with the > images, and then use the native background color on the tab itself. This ends > up meaning we can get the right color of tab, with the effect we want, even if > its white on black. This requires some CSS change. I'll upload new images, but I had a hard time reducing the tab background-color to the region that is covered by the images. I guess somebody else will have to do this.
Attached file new winstripe tab images v3 (obsolete) —
Attachment #236683 - Flags: review?(mconnor)
Attached image v3 screenshots (obsolete) —
Attachment #236573 - Flags: review?(mconnor)
Attached file new winstripe tab images v4 (obsolete) —
Attachment #236683 - Attachment is obsolete: true
Attachment #236684 - Attachment is obsolete: true
Attachment #236685 - Flags: review?(mconnor)
Attachment #236683 - Flags: review?(mconnor)
Attached image v4 screenshots (obsolete) —
Note that I'm not marking v2 obsolete, because I'm not sure if it doesn't look better than this.
(In reply to comment #17) > This requires some CSS change. I'll upload new images, but I had a hard time > reducing the tab background-color to the region that is covered by the images. > I guess somebody else will have to do this. An alternative would be not to apply any color to the tab (as in v2, but with less opaque images) so that the tabstrip background is visible, though that's darker because of the background gradient.
Attached image v4 screenshots without CSS changes (obsolete) —
Attached file new winstripe tab images v5 (obsolete) —
Did some testing on more OS themes and that's what I concluded with.
Attachment #236685 - Attachment is obsolete: true
Attachment #236686 - Attachment is obsolete: true
Attachment #236687 - Attachment is obsolete: true
Attachment #236721 - Flags: review?(mconnor)
Attachment #236685 - Flags: review?(mconnor)
Attached image v5 screenshots (obsolete) —
(In reply to comment #25) > Created an attachment (id=236722) [edit] > v5 screenshots > While this looks great overall (in terms of Tabs inheriting the theme color), but the differentiation between inactive, hovered and active tabs in terms of color is minor. Under such circumstances, IMO the gradient should be more prominent on hovered and active tabs i.e. while the inactive tab is fine looking 'flat', the hovered and active tabs should look more 'curved/3Dish'. That'd solve the problem I guess.
Attached image v6 WIP screenshots (obsolete) —
OK, what do you think about that? Notes: - hover not done yet; the contrast between background tabs and the active tab is more important anyway. - I've raised the active tab 1px manually on the screenshots.
(In reply to comment #27) > Created an attachment (id=236786) [edit] > v6 WIP screenshots > > OK, what do you think about that? > > Notes: > - hover not done yet; the contrast between background tabs and the active tab > is more important anyway. > - I've raised the active tab 1px manually on the screenshots. > Perfect. This really looks good. Also as far as your comment here https://bugzilla.mozilla.org/show_bug.cgi?id=351372#c4 The White Strip should inherit the color of the active tab so that they look seamlessly connected. That should solve the problem.
(In reply to comment #27) > Created an attachment (id=236786) [edit] > - I've raised the active tab 1px manually on the screenshots. > I think this effect (of raising the active tab by 1 px) looks nice and really helps the active tab stand out. This change should be incorporated.
(In reply to comment #28) > Also as far as your comment here > https://bugzilla.mozilla.org/show_bug.cgi?id=351372#c4 > > The White Strip should inherit the color of the active tab so that they look > seamlessly connected. That should solve the problem. You can make the white strip semi-transparent, too, but you still have that border between the strip and the active tab.
i think that it is not easy to recognize the active tab from others in the first case of the screenshot, greys are too similar. The 1px raising helps but not much, i think that between 10 tabs could be difficult to find it at first sight... maybe make it a little less transparent, or change border color, or do some "negative" effect so non active are darker and active is "negative" lighter. and if you cannot unify the white strip to the tab maybe it should be removed cause it is useless with this change.
(In reply to comment #31) > i think that it is not easy to recognize the active tab from others in the > first case of the screenshot, greys are too similar. > Do you mean the one on Royale Blue Theme. I think the font used there is different than the regular fonts. Besides, somehow the Bold on active tab is not as Bold as it should be. I guess again thats because of the Font.
(In reply to comment #30) > (In reply to comment #28) > > Also as far as your comment here > > https://bugzilla.mozilla.org/show_bug.cgi?id=351372#c4 > > > > The White Strip should inherit the color of the active tab so that they look > > seamlessly connected. That should solve the problem. > > You can make the white strip semi-transparent, too, but you still have that > border between the strip and the active tab. > But today there is no border between the white strip and the active tab (which is also white i.e. the same color) although there is border on the white strip everywhere else. How is that done? Isn't something similar possible?
(In reply to comment #32) > Do you mean the one on Royale Blue Theme. I think the font used there is > different than the regular fonts. Besides, somehow the Bold on active tab is > not as Bold as it should be. I guess again thats because of the Font. Yes, it's Trebuchet MS, where bold doesn't really look bold. (In reply to comment #33) > But today there is no border between the white strip and the active tab (which > is also white i.e. the same color) although there is border on the white strip > everywhere else. How is that done? Isn't something similar possible? The active tab is opaque and overlays the strip's border.
Attached file new winstripe tab images v6 (obsolete) —
Attachment #236721 - Attachment is obsolete: true
Attachment #236722 - Attachment is obsolete: true
Attachment #236786 - Attachment is obsolete: true
Attachment #236792 - Flags: review?(mconnor)
Attachment #236721 - Flags: review?(mconnor)
Attached image v6 screenshots (obsolete) —
Note that I didn't raise the active tab now, because that's not part of this bug. (But besides, I think beltzner said the active tab should be raised by 2px.)
(In reply to comment #36) > Created an attachment (id=236793) [edit] > v6 screenshots > > Note that I didn't raise the active tab now, because that's not part of this > bug. > > (But besides, I think beltzner said the active tab should be raised by 2px.) > The Tabs look great (Hover could be a shade lighter though). Besides: - Is there a Bug filed for raising the active tab? - The white strip is looking real bad now. Can we atleast have it derive the color of the active tab and see how it looks? Also maybe remove its top border completely?
(In reply to comment #34) > > Do you mean the one on Royale Blue Theme. I think the font used there is > > different than the regular fonts. > > Yes, it's Trebuchet MS, where bold doesn't really look bold. i'm using the royale theme on my machine, but with build 20060901 i have a different font that is clearly bold, not that non-boldish font... i will test when the new build with your changes comes out. could you try to change the border of the active tab to a darker one? i have also tried with an orange-ish border, not so bad, hwv a darker border makes the active tab very first-look findable on light themes as royale...
(In reply to comment #38) > (In reply to comment #34) > i'm using the royale theme on my machine, but with build 20060901 i have a > different font that is clearly bold, not that non-boldish font... i will test > when the new build with your changes comes out. I set the font to Trebuchet MS manually. > could you try to change the border of the active tab to a darker one? i have > also tried with an orange-ish border, not so bad, hwv a darker border makes the > active tab very first-look findable on light themes as royale... Just attach your screenshot / mockup.
(In reply to comment #37) > - Is there a Bug filed for raising the active tab? bug 349187
(In reply to comment #37) > The Tabs look great (Hover could be a shade lighter though). I agree that they look nice; I'm not sure I see anything wrong with hover. > - The white strip is looking real bad now. Can we atleast have it derive the > color of the active tab and see how it looks? I totally agree. With the old images, the active tab was obviously an extension of the white strip. Now it doesn't look like it relates to the strip at all. The colors need to match. > Also maybe remove its top border > completely? I thought that in the old images, the white strip had a top border between it and the background tabs, and no border between it and the active tab. Now it looks like there's a border on the active tab too. That looks strange. Is that a bug with this patch?
(In reply to comment #41) > I thought that in the old images, the white strip had a top border between it > and the background tabs, and no border between it and the active tab. Now it > looks like there's a border on the active tab too. That looks strange. Is > that a bug with this patch? The border was always there, but it was overlayed by the active tab. Of course this doesn't work if the active tab is transparent.
(In reply to comment #42) > (In reply to comment #41) > > I thought that in the old images, the white strip had a top border between it > > and the background tabs, and no border between it and the active tab. Now it > > looks like there's a border on the active tab too. That looks strange. Is > > that a bug with this patch? > > The border was always there, but it was overlayed by the active tab. Of course > this doesn't work if the active tab is transparent. I see. It would be good to figure out how to fix that. The border is a Good Thing, as is not having it between the strip and the active tab... Another comment I have is that I think the gradient is too severe now. The more subtle effect in v5 had the major advantage that it was more readable. The v6 images' gradient is sever enough to hinder readability.
(In reply to comment #43) > > Another comment I have is that I think the gradient is too severe now. The > more subtle effect in v5 had the major advantage that it was more readable. > The v6 images' gradient is sever enough to hinder readability. > I think the readability is hindered only in the first case (Royale Blue Theme) and that too because of the font used. It looks fine in other cases.
(In reply to comment #44) > (In reply to comment #43) > > > > Another comment I have is that I think the gradient is too severe now. The > > more subtle effect in v5 had the major advantage that it was more readable. > > The v6 images' gradient is sever enough to hinder readability. > > > > I think the readability is hindered only in the first case (Royale Blue Theme) > and that too because of the font used. It looks fine in other cases. > Actually I think the gradient line (the horizontal line) can be shifted up by a couple of pixels so that it is just above the text than cutting through right across it. It will look fine then since the text will fall into the seemingly flat area.
In reply to comment #39: My idea for royale (but it does not hurts other themes if implemented) was to darken the active tab border, the inactive borders are white surrounded by dark-grey... i have removed (or ligthen up) the dark-grey border and replaced the white border with a dark-grey gradient border that attach to the grey bottom strip. I have used a gradient because a full dark border needed a dark strip and that was not "native looking". this is not a big improvement, very little changes, but i think it helps to find tab on royale, don't know if this can be implemented/tested, but it's an idea that i've not seen yet. and mybe it can be used also to make more findable the scrolling and all tabs buttons.
Attached file new winstripe tab images v7 (obsolete) —
Attachment #236573 - Attachment is obsolete: true
Attachment #236574 - Attachment is obsolete: true
Attachment #236792 - Attachment is obsolete: true
Attachment #236793 - Attachment is obsolete: true
Attachment #236910 - Flags: review?(mconnor)
Attachment #236792 - Flags: review?(mconnor)
Attached image v7 screenshots (obsolete) —
Your turnaround time is impressive Dao :-) Ok, overall the placement of gradient line looks fine now and this is definitely getting better, but with an unexpected result. Let me explain. Of the three themes used in the screenshot, the one that looks the best is surprisingly the third one (Classic Theme). And the reason is that in the classic theme, unintentionally (because of the theme color), the portion of the tab below the horizontal gradient line is (looks?) a shade darker than the portion above the line. This gives a nice gradient effect. In the other themes (Royale and Luna) the shades below as well as above the horizontal gradient line is almost the same and hence it looks as if a dark line is passing right through the tab, which doesn't give a great gradient effect. The solution ofcourse is to ensure through the gradient effect that the portion below the horizontal line is a shade darker than the portion above it as has been illustrated in the attachment (for Classic/IE7 active tabs).
(In reply to comment #47) > Created an attachment (id=236910) [edit] > new winstripe tab images v7 > > As per comment 45 and comment 46. Personally I'm not a fan of these changes. Moving the gradient up makes it look out of place with the centered gradients on the Go button and the new (not yet landed) urlbar dropmarker. The gradient is still too obvious and distracting for me. And I think the new tab border colors simply look odd and out of place.
I tend to I agree with Peter. The gradient is pretty harsh compared to v5, maybe too harsh. Weakening it could make the proposed change in comment 45 unnecessary. I'm not sure about the strong tab border. It makes the active tab stand out more, but it doesn't affiliate to the OS theme. I'll try to weaken it, too.
Attached file new winstripe tab images v8 (obsolete) —
Attachment #236910 - Attachment is obsolete: true
Attachment #236912 - Attachment is obsolete: true
Attachment #236937 - Flags: review?(mconnor)
Attachment #236910 - Flags: review?(mconnor)
Attached image v8 screenshots (obsolete) —
(In reply to comment #53) > Created an attachment (id=236938) [edit] > v8 screenshots > Even if this approach is used i.e. keeping the gradient line a little mild and in center, I still think that the best gradient effect can be obtained only if the shading is different above and below this line (darker shade below the gradient line as per my comment #49 and as shown in https://bugzilla.mozilla.org/attachment.cgi?id=236914&action=view ). Because if the shades above and below the gradient line are the same, then it just looks like a dark line passing through a light background which does not look good.
Screenshot of what I have been trying to explain. I took the image posted by Dao, picked the color of the Gradient line and colored the portion of tab below the gradient line with that color, in effect making it a shade darker than the portion above the gradient line. I think this looks good in terms of gradient effect for Active tab, as well as text readability. Also, we don't see that odd effect of the dark line running right through the tab.
(In reply to comment #55) > Created an attachment (id=236941) [edit] > Active Tab with darker shade below the gradient line I'm not going to shade the whole portion below the gradient line like you do, because this creates a contrast between the active tab and the light line beneath it. I can try to expand the gradient downwards, though.
Attached file new winstripe tab images v9 (obsolete) —
Attachment #236937 - Attachment is obsolete: true
Attachment #236938 - Attachment is obsolete: true
Attachment #236953 - Flags: review?(mconnor)
Attachment #236937 - Flags: review?(mconnor)
Attached image v9 screenshots (obsolete) —
(In reply to comment #58) > Created an attachment (id=236954) [edit] > v9 screenshots > Better, but I think it is still too subtle a change. I guess I will want to see it in action when you land the patch before making any more comments. (In reply to comment #58) >I'm not going to shade the whole portion below the gradient line like you do, >because this creates a contrast between the active tab and the light line >beneath it. Even without shading the whole portion below, the contrast between the active tab and white strip is high in 'Classic' theme. Aren't we going to make the white strip semi-transparent so that it derives its color from the theme color and matches the active tab color?
(In reply to comment #59) > Better, but I think it is still too subtle a change. I guess I will want to see > it in action when you land the patch before making any more comments. You can also download the images and repack classic.jar. > Even without shading the whole portion below, the contrast between the active > tab and white strip is high in 'Classic' theme. Aren't we going to make the > white strip semi-transparent so that it derives its color from the theme color > and matches the active tab color? I wouldn't do that. First of all, it's not the default Classic theme, it's a darker one; not very spread, I guess. Anyway, I think it looks acceptable. Secondly, if you make that line darker, you also reduce the contrast to the background tabs. I think the status quo is a fair tradeoff. That's how I did it: .tabbrowser-tabs { border-bottom: 2px solid; -moz-border-bottom-colors: ThreeDShadow ThreeDHighlight; } Hence I didn't use the "white strip" at all. And it will always match the OS theme this way.
(In reply to comment #60) > (In reply to comment #59) > > Better, but I think it is still too subtle a change. I guess I will want to see > > it in action when you land the patch before making any more comments. > > You can also download the images and repack classic.jar. I just did as you suggested. Repackaged classic.jar. I checked it on Classic and Royale themes. - Though not as pronounced as before, the gradient line cutting through tab is still evident (especially on active tabs which have lot of empty space i.e. large size tab with less text in the title). I would think a little more shading is required in the bottom half. Actually the problem is not really the color. Its the smoothness of the gradient. It should be something like light on top (as it is right now)) -> dark shade of gradient line (as it is right now) -> continue the same shade as the gradient line for some distance below and then fade off a bit slowly towards the end Currently it shows like: light on top -> dark shade of gradient line -> immediate fading off right below the gradient line (this causes the gradient line to look like a 'line' instead of giving it a smooth gradient effect) - The gradient line effect of cutting through on hovered tabs is as it was before (I assume you haven't changed that yet) I guess other users as well as beltzner/connor should have a look at this before you make any further changes. Since I have been looking at every minor change so closely for last 2 days, I might just be in nit-mode right now :-)
Attaching a screenshot of a possible gradient effect for active tab.
(In reply to comment #62) > Created an attachment (id=237061) [edit] > Possible Gradient for Active Tab > > Attaching a screenshot of a possible gradient effect for active tab. This lets me think that you're actually having a problem with Radiant Core's concept shown in the mockups, which I'm trying to follow. Your screenshot looks completely different.
(In reply to comment #63) > (In reply to comment #62) > > Created an attachment (id=237061) [edit] > > Possible Gradient for Active Tab > > > > Attaching a screenshot of a possible gradient effect for active tab. > > This lets me think that you're actually having a problem with Radiant Core's > concept shown in the mockups, which I'm trying to follow. Your screenshot looks > completely different. > Not at all. That screenshot was intended as an example of smooth gradient so that the 'gradient line' problem could be solved. Radiant Core's design look perfectly fine with a 'White' active tab as we can see in the current nightlies (and in the original mockup) coz in that case the 'gradient line' problem does not exist. But now since we are planning to have semi transparent tabs which will derive color from the theme and hence will not be 'white', the 'gradient line' problem will be more evident since it (active tab as well as gradient line) will get considerably darker as we have seen in the screenshots. But now that you mentioned Radiant Core, I went back to see the mockups again. Just had a thought. Can't we allow the background tabs to be semi-transparent and derive the native theme color (like in your screenshots) but keep the active tab completely 'White' with a slight gradient as it is in the original mockup (as well as current nightlies). This will solve the following problems: - Background Tabs will adjust themselves as per the native theme (as in the mockup) and hence look good & fit the respective themes. - Active Tab will be white (with a slight gradient) exactly as it is in the original radiant core mockups (as well as current nightlies). This will make it easily distinguishable from bakcground tabs too. - Gradient line problem will get automatically solved. - The white strip problem will also not exist since white active tab integrates very nicely with the white strip. Hence basically: - Keep the active tab exactly as it is today. Don't change it. - Make the Background Tabs semi-transparent (like in your screenshots)
(In reply to comment #64) > Not at all. That screenshot was intended as an example of smooth gradient so > that the 'gradient line' problem could be solved. I don't see how this gradient fits into the active tab. > Radiant Core's design look perfectly fine with a 'White' active tab as we can > see in the current nightlies (and in the original mockup) coz in that case the > 'gradient line' problem does not exist. The mockup's gradient is - pretty similar to the one I use, it's just lighter -- like v5, where you stated: "the gradient should be more prominent". - also shorter, contrary to your "continue the same shade as the gradient line for some distance below" approach. > But now since we are planning to have > semi transparent tabs which will derive color from the theme and hence will not > be 'white', the 'gradient line' problem will be more evident since it (active > tab as well as gradient line) will get considerably darker as we have seen in > the screenshots. I hardly see how white (or the lack of it) is conjunct to a "gradient line problem". We do have to deal with the problem that the contrast between the active and background tabs is weaker this way. That's why I want the active tab to be raised 2px. > But now that you mentioned Radiant Core, I went back to see the mockups again. > Just had a thought. Can't we allow the background tabs to be semi-transparent > and derive the native theme color (like in your screenshots) but keep the > active tab completely 'White' with a slight gradient as it is in the original > mockup (as well as current nightlies). That's what I tried first, but it's wrong. It looks displaced in many themes and it's not accessible (also see comment 16).
(In reply to comment #65) > The mockup's gradient is > > - pretty similar to the one I use, it's just lighter -- like v5, where you > stated: "the gradient should be more prominent". That was because the gradient was fine to distinguish it from background tabs IF the active tab was lighter in color. But as it got darker (and hence more similar to background tabs) my thought was a more prominent gradient would help. After seeing all your screenshots, I agree that the original gradient (v5) is good enough. > > - also shorter, contrary to your "continue the same shade as the gradient line > for some distance below" approach. Again, as the Active Tab got darker in color, having a short gradient meant having the 'gradient line' problem. Hence I felt that 'continuing the same shade for some distance below' will solve this problem. I still think this is the correct approach. Active tab in https://bugzilla.mozilla.org/attachment.cgi?id=236954 screenshot definitely looks better than https://bugzilla.mozilla.org/attachment.cgi?id=236722 > I hardly see how white (or the lack of it) is conjunct to a "gradient line > problem". We do have to deal with the problem that the contrast between the > active and background tabs is weaker this way. That's why I want the active > tab to be raised 2px. Even I liked the 2px raising solution. Sad that it has been WONTFIXED. I really hope it is reconsidered. About relation between white active tabs and gradient line: In 'White' Active Tabs, the gradient line problem is not very pronounced since the line itself is very light and not very visible. Thats not the case with darker tabs where the line is very visible. > That's what I tried first, but it's wrong. It looks displaced in many themes > and it's not accessible (also see comment 16). I was going to correct myself here (you replied before I could :-). I basically meant adusting the opacity/transparency of the tab so that it can be made as light as possible, not hard-coding it as white. I know you have been working **** this. I am just trying to give feedback/suggestions to the best of my ability. I hope all your hard work bears fruit and we finally come up with a great solution. Thanks for everything.
Comment on attachment 236953 [details] new winstripe tab images v9 This inherits the color just fine, but makes the gradient the differntiation, which seems to not fit well. I also think they lose a lot of needed contrast and visual style, especially with the texture these add. On the plus side, I know that this bug, done right, should resolve the problems in high-contrast mode!
Attachment #236953 - Flags: review?(mconnor) → review-
(In reply to comment #67) > (From update of attachment 236953 [details] [edit]) > This inherits the color just fine, but makes the gradient the differntiation, > which seems to not fit well. I also think they lose a lot of needed contrast > and visual style, especially with the texture these add. OK, so that's what I'm going to do now: - Make the gradient weaker again (active tab only?). - Try to lighten up the top of the active tab. I don't think I can lighten up the whole tab much more, especially because of the high-contrast issue.
Attachment #236953 - Attachment is obsolete: true
Attachment #236954 - Attachment is obsolete: true
Attachment #237108 - Flags: review?(mconnor)
Attached image v10 screenshots
these look great! (both bugs) Seth is working on some CSS tweaks to brighten them up (basically getting background of -moz-dialog on the tab elements as well so these don't darken from the tabstrip gradient), and should have screenshots tonight. Dao, would you be able to work with Seth to get scrollbutton/all tabs versions of this image style?
yes, I'm playing with dao's images (thanks dao!) from this bug and bug #350689. so far, I have made two additional css changes to work with dao's images. the changes are for high contrast mode and to make the selected tab brighter. here come screen shots.
Status: NEW → ASSIGNED
things to note: 1) for the high contrast, please excuse the problems caused by large dpi 2) for the "pixels on the corners issue", will try to following myk's trick of -moz-border-radius-topright and -moz-border-radius-topleft to fix that. 3) will be working on the narrow white strip below the tabs (to use css, instead an image) dao: do you have cycles to help me with images for the left scroll, right scroll and all tabs buttons (both in overflow and non overflow, and animation)?
mconnor / beltzner / dao / pkasting / et al: I like https://bugzilla.mozilla.org/attachment.cgi?id=237225 more than https://bugzilla.mozilla.org/attachment.cgi?id=237224, as I like having just the selected tab be lighter. opinions?
(In reply to comment #75) > Created an attachment (id=237225) [edit] > screen shot of just the selected tab give -moz-dialog Seth, there appears to be a problem here. Look at the top each tab, on the left and right. There are a few extra pixels in the tab images. It's especially bad between two tabs where they would join if they weren't rounded at the top. See what I'm talking about? ~B
(In reply to comment #78) > (In reply to comment #75) > > Created an attachment (id=237225) [edit] > > screen shot of just the selected tab give -moz-dialog > > Seth, there appears to be a problem here. Look at the top each tab, on the > left and right. There are a few extra pixels in the tab images. It's > especially bad between two tabs where they would join if they weren't rounded > at the top. > > See what I'm talking about? > > ~B Oopsss... I see that you are working on it! Thanks for all of the work! ~B
(In reply to comment #77) > I like https://bugzilla.mozilla.org/attachment.cgi?id=237225 more than > https://bugzilla.mozilla.org/attachment.cgi?id=237224, as I like having just > the selected tab be lighter. I agree that having the selected tab lighter is good, but not at the expense of having the background tabs disappear into the tabstrip. One of the goals of the redesign of the tabstrip was to have the background tabs (on both platforms) be visually distinct from the tabstrip - I feel they're too transparent in the first one.
I have a patch, and it even works for RTL! (I also have a couple additional rules to fix a RTL bug, but I'll be it's a dup of a bug that asaf's owns.) RTL screen shot coming, and then the patch.
Assignee: sspitzer → nobody
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Assignee: nobody → sspitzer
Status: ASSIGNED → NEW
Attached image screen shot of rtl (obsolete) —
Attached patch patch (obsolete) — Splinter Review
(In reply to comment #80) > (In reply to comment #77) > > > I like https://bugzilla.mozilla.org/attachment.cgi?id=237225 more than > > https://bugzilla.mozilla.org/attachment.cgi?id=237224, as I like having just > > the selected tab be lighter. > > I agree that having the selected tab lighter is good, but not at the expense of > having the background tabs disappear into the tabstrip. One of the goals of the > redesign of the tabstrip was to have the background tabs (on both platforms) be > visually distinct from the tabstrip - I feel they're too transparent in the > first one. From the screenshots I had agreed with Seth, but after testing on Linux I think I agree with Jay. I actually can't easily tell where my background tabs are or how many I have with the current patch on this. I then tried testing with the dialog color behind everything, but I think I screwed up the patch, because it didn't do what I wanted :). So I'd like to see a patch that puts the dialog color behind everything; I think that would perhaps be better.
Also, after testing both with and without the patch/images, I find that the white tab in the current builds is easier to distinguish as the active tab, and the blend effect where it flows into the white strip at the bottom is nicer and makes the window more unified. The patch makes the white strip basically disappear, and I lose the sense that this tab is "flowing into" the whole window. The tab strip background definitely seemed better in the new patch, but I'm not so sold on any of the other changes. Maybe they're a win for high-contrast mode though.
Attached image screen shot to match the last patch (obsolete) —
Attachment #237241 - Attachment is obsolete: true
I see what jay and pkasting mean about how not setting the background-color for the other tabs makes them "disappear", but I think https://bugzilla.mozilla.org/attachment.cgi?id=237224 has the problem that the selected tab doesn't appear different enough from the other tabs. mconnor / beltnzer: comments or suggestions?
Status: NEW → ASSIGNED
Attachment #237223 - Attachment is obsolete: true
Attachment #237224 - Attachment is obsolete: true
Attachment #237225 - Attachment is obsolete: true
Attachment #237248 - Attachment is obsolete: true
Attachment #237272 - Attachment is obsolete: true
comments: 1) I'm using a place holder version of tabstrip-bottom.png (that I made). Hopefully dao can help make a better one. 2) Now winstripe appears to have the same optical illusion where the selected tab appears to be 1px shorter (but it is not). (see https://bugzilla.mozilla.org/attachment.cgi?id=237279) For more on this optical illusion (which pinstripe is suffering from, because it uses the winstripe background), see https://bugzilla.mozilla.org/show_bug.cgi?id=351100#c8 Still seeking review from mconnor, even with these two notes.
Attachment #237108 - Flags: review?(mconnor) → review+
Comment on attachment 237278 [details] [diff] [review] patch, use moz-dialog as bg color for every tab, screen shots coming... r+a=me I don't know if this is perfect, but it solves a lot of problems, and is a lot closer to perfect than where we are!
Attachment #237278 - Flags: review?(mconnor)
Attachment #237278 - Flags: review+
Attachment #237278 - Flags: approval1.8.1+
fix landed on the branch. thanks again to dao for all the work on these images. I'll see (in another bug) if he can help come up with a better version of the tabstrip-bottom.png that I hacked up.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Summary: tab images should be semi-transparent → tab images should be semi-transparent so that they work with the OS theme and high contrast mode
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: