570279 - Tab+NavBar Connecting Curve Adjustments

Status: VERIFIED FIXED

(Firefox :: Theme, enhancement)

Description

[Stephen Horlander [:shorlander]]

Attachment: Tabs Connecting to NavBar

Curve that connects tab to navBar/contentArea should be more curved, gradual, smoother and have more overlap on background tabs

Comment 1

[imradyurrad]

Blocking 2.0? Unless the tentative code freeze of tomorrow actually sticks.

Comment 2

[Peter Henkel [:Terepin]]

The entire meta bug is blocking 2.0. The only question is which milestone.

Comment 3

[Dão Gottwald [:dao]]

Bug 554982 partly spoils the appearance here with tabs on bottom.

Comment 5

[Sierk Bornemann]

I confirm this bug also for at least MacOSX.
You should adjust "Platform: x86 Windows 7" to at least "Platform: x86 Windows 7 Mac OSX" or to "Platform: x86 All" in the bug's information.

Comment 6

[Sierk Bornemann]

(In reply to comment #5)
> I confirm this bug also for at least MacOSX.
> You should adjust "Platform: x86 Windows 7" to at least "Platform: x86 Windows
> 7 Mac OSX" or to "Platform: x86 All" in the bug's information.

See also https://wiki.mozilla.org/Firefox/Projects/New_Theme/Timeline .
That page should also be adjusted with respect to this bug and reflecting the outstanding bugs on Mac platform an Linux platform.
For instance only the [Windows] Theme Requirements (in order of priority) incl. screenshots mentions Bug 570279 and Bug 570282, although these two bugs also do apply on Mac OSX and Linux as well concerning "Tabs on Top" (Tabs on Bottom are curved, Tabs on Top are not curved) -- compare 1st screenshot (Tabs on Top) with 2nd screenshot (Tabs on Bottom) of either platform.

Comment 8

[Peter Henkel [:Terepin]]

Frank, any ETA?

Comment 9

[Dão Gottwald [:dao]]

hm? Original summary was much more descriptive and concrete.

Comment 10

[Frank Yan (:fryn)]

Attachment: patch for cleaner tabs

Since implementing a proper connecting curve would require negative margins and other voodoo (including SVG), we're going with a more angular appearance that eschews lower concave corners for this release (Firefox 4). Screenshot coming up.

Comment 11

[Frank Yan (:fryn)]

Attachment: screenshot of cleaner tabs

Said screenshot attached, showing tabs' appearance on backgrounds of varying lightness.

Comment 12

[Frank Yan (:fryn)]

Attachment: better patch for cleaner tabs

pixel push to make tabs-on-bottom look better and reduce UI movement when switching to personas (part of bug 616010).

Comment 13

[Dão Gottwald [:dao]]

Comment on attachment 516180 [details] [diff] [review]
better patch for cleaner tabs

>-  #main-window[sizemode="normal"] #TabsToolbar[tabsontop="true"]:not([inFullscreen="true"]):not(:-moz-lwtheme) {
>+  #main-window[sizemode="normal"] #TabsToolbar:not([inFullscreen]) {
>     padding-left: 4px;
>     padding-right: 4px;
>   }

Why are you removing the tabs-on-top condition?

>+.tabbrowser-tab {
>+  -moz-margin-end: 1px;
> }

Margins on tabs cause weirdness with scrolling, last time I checked.
This change isn't really necessary, is it? I.e. the gap could remain part of the border.

Comment 14

[Frank Yan (:fryn)]

(In reply to comment #13)
> Why are you removing the tabs-on-top condition?

It's a bit strange to have the leftmost tab flush with the left border of the content area, which happens in aero. TBH, I don't care about tabs-on-bottom mode, so if that seems okay to you, i'll leave the condition in.

> >+.tabbrowser-tab {
> >+  -moz-margin-end: 1px;
> > }
> 
> Margins on tabs cause weirdness with scrolling, last time I checked.
> This change isn't really necessary, is it? I.e. the gap could remain part of
> the border.

What sort of weirdness? I tried reproducing and didn't find any. With the gap in the border, we end up with an asymmetric border, since we want a one pixel gap, and it's difficult to specify a border-radius that will work the same on each side. I suppose we can approximate it if we need to, since it's already that way as is. |border-radius: 10px 8px 0 0;| etc. If that's really the best approach we've got, I'll update a patch with that later today.

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #14)
> It's a bit strange to have the leftmost tab flush with the left border of the
> content area, which happens in aero. TBH, I don't care about tabs-on-bottom
> mode, so if that seems okay to you, i'll leave the condition in.

I think we'd probably want a 1px or 2px padding in that case. The 4px were added because of the radius on the nav bar with tabs on top.

> > Margins on tabs cause weirdness with scrolling, last time I checked.
> > This change isn't really necessary, is it? I.e. the gap could remain part of
> > the border.
> 
> What sort of weirdness?

Like, the tab strip not scrolling completely to the end when selecting the last tab.

Comment 16

[Peter Henkel [:Terepin]]

(In reply to comment #10)
> Created attachment 516164 [details] [diff] [review]
> patch for cleaner tabs
> 
> Since implementing a proper connecting curve would require negative margins and
> other voodoo (including SVG), we're going with a more angular appearance that
> eschews lower concave corners for this release (Firefox 4). Screenshot coming
> up.

So Firefox on Mac was able to use this "voodoo", but on Windows not?

Comment 17

[Brandon Cheng]

(In reply to comment #16)
> So Firefox on Mac was able to use this "voodoo", but on Windows not?

Firefox on Mac has the tabs redone in SVG.

Comment 18

[imradyurrad]

(In reply to comment #17)
> (In reply to comment #16)
> > So Firefox on Mac was able to use this "voodoo", but on Windows not?
> 
> Firefox on Mac has the tabs redone in SVG.

I think that's what he was implying. So why can't the same be done for Windows?

Comment 19

[Frank Yan (:fryn)]

Attachment: simpler patch for cleaner tabs

I discussed with Stephen, and it turns out that we don't actually want the gap (at least for this release), so the patch is now just some CSS pixel pushing and an image drop.

Comment 20

[Frank Yan (:fryn)]

Attachment: screenshot of simpler patch

AIUI, Stephen already knows what this looks like, so it should be good to go.

Comment 21

[Frank Yan (:fryn)]

Attachment: patch (now gives app tabs space to breathe)

minor addition to the previous patch that gives app tabs space to breathe.

explanation of low risk:
no javascript.
no c++.
css only pushes pixels; no behavior change.
single image drop that is a non-animated PNG.

Comment 22

[Frank Yan (:fryn)]

Attachment: screenshot of above patch

Comment 23

[Frank Yan (:fryn)]

Attachment: screenshot of above patch in overflow mode

Comment 24

[Stephen Horlander [:shorlander]]

Comment on attachment 516484 [details]
screenshot of above patch

Looks great!

Comment 25

[Frank Yan (:fryn)]

Comment on attachment 516483 [details] [diff] [review]
patch (now gives app tabs space to breathe)

Explanation of patch for dolske:

>-  #main-window[sizemode="normal"] #TabsToolbar[tabsontop="true"]:not([inFullscreen="true"]):not(:-moz-lwtheme) {
>+  #main-window[sizemode=normal] #TabsToolbar[tabsontop=true]:not([inFullscreen]) {

Makes switching to a persona not cause the tabs toolbar to shift awkwardly.

>+  #main-window[sizemode=normal] #TabsToolbar[tabsontop=false]:not([inFullscreen]) {
>+    padding-left: 2px;
>+    padding-right: 2px;
>+  }

In tabs-on-bottom mode in areo, make the leftmost tab not awkwardly be flush with the left border of the content area.

> .tabbrowser-tab,
> .tabs-newtab-button {
...
>-  background-size: 100% -moz-calc(100% - 2px);
>+  background-size: -moz-calc(100% - 2px) -moz-calc(100% - 2px);
...
>-  -moz-border-image: url(tabbrowser/tab.png) 4 5 3 6 / 4px 5px 3px 6px repeat stretch;
>-  border-radius: 10px 8px 0 0;
>+  -moz-border-image: url(tabbrowser/tab.png) 6 3 4 / 6px 3px 4px repeat stretch;
>+  border-radius: 7px 7px 0 0;
...
> .tab-throbber,
> .tab-icon-image {
...
>+  -moz-margin-start: 2px;

Make the tabs symmetrical and adjust the background/width/padding/border values for the new tab.png dimensions.

> .tab-throbber[pinned],
> .tab-icon-image[pinned] {
>-  -moz-margin-start: 2px;
>-  -moz-margin-end: 2px;
>+  -moz-margin-start: 5px;
>+  -moz-margin-end: 5px;
> }

Give app tabs 1 pixel more padding on each side.
(It looks like 3 pixels, but 2 of them are for the new tab.png dimensions.)

> .tabs-newtab-button {
>-  width: 31px;
>+  width: 30px;
> }

Make the new tab button's icon be centered.

...
>GIT binary patch
...

Update tab.png! Thanks, Stephen!

Comment 26

[Jack]

So ugly!

Comment 27

[Justin Dolske [:Dolske]]

Comment on attachment 516483 [details] [diff] [review]
patch (now gives app tabs space to breathe)

Basically fine, although when we checked on XP the first tab looks a little too close to the window border now. Frank's updating for that case. Should be r+ with that fixed.

Comment 28

[Theodore]

I think it looks beautiful! Much cleaner and "lighter" feeling. Great work!

Comment 29

[Frank Yan (:fryn)]

Attachment: patch

Restores tabs toolbar padding for Windows XP non-classic.

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 516500 [details] [diff] [review]
patch

a=beltzner, let's get this in nightlies

Fryn: can you post (gulp) on MozillaZine asking people to hammer on the nightly and point out oddities in various Windows theme modes?

Comment 31

[Asa Dotzler [:asa]]

http://hg.mozilla.org/mozilla-central/rev/e633e7a4af4b

Comment 32

[LegNeato]

I want to point out that this will likely cause churn where we already have  screenshots (SUMO, marketing and promo materials, and MDN?) taken of FF4. This looks pretty different to me at first glance, though admittedly I don't live on Windows.

Comment 33

[Frank Yan (:fryn)]

(In reply to comment #32)
> I want to point out that this will likely cause churn where we already have 
> screenshots (SUMO, marketing and promo materials, and MDN?) taken of FF4. This
> looks pretty different to me at first glance, though admittedly I don't live on
> Windows.

Yeah, we'll need to update those screenshots. This is something we really wanted and planned to fix for the release. I guess there was a lack of communication about that. I'd be glad to help update any materials; do you know whom I should talk to?

Comment 34

[Zachary Northrup [MSFT]]

Sorry, I'm still a little unclear on the above question: why can't we just copy over the mac voodoo? Were you answering this when you mentioned not wanting the spacing above?

Comment 35

[Asa Dotzler [:asa]]

fryn, check with John Slater for product pages at mozilla.com and David Tenser for sumo.

Comment 36

[Frank Yan (:fryn)]

(In reply to comment #34)
> Sorry, I'm still a little unclear on the above question: why can't we just copy
> over the mac voodoo? Were you answering this when you mentioned not wanting the
> spacing above?

The border shapes are different, which require different vector paths/shapes when specifying SVG masks. You can't just copy and paste.

(In reply to comment #35)
> fryn, check with John Slater for product pages at mozilla.com and David Tenser
> for sumo.

Thanks. Will do.

Comment 37

[Siddhartha Dugar [:sdrocking]]

There is still this non-clickable area above tabs, which should have gone with this fix.

Comment 38

[Siddhartha Dugar [:sdrocking]]

Also tab focus with F6 looks bad.

Comment 39

[Edo Karabas]

Looks nice, but new tabs are a bit taller than previous version.

Comment 40

[Paul [pwd]]

I don't understand how a bug to give tabs more curvature becomes a bug to to make tabs into blocks but fair enough. That said, tabs are far far too tall.

Comment 41

[hjalte]

Yes, the tabs look much too tall.  For example, hover over the close button of a tab: the close button is closer to the right side of the tab than to the top or bottom by a few pixels.  The tabs ought to be of such a height that the close button border should be equidistant from the top, bottom and right-hand edges of the tab, in my opinion.

Comment 42

[Peter Henkel [:Terepin]]

On behalf MozillaZine community: They are ugly. Period.

Comment 43

[Paul [pwd]]

I've noticed some usability issues. At a glance before, you'd look for the curve from the tab-line base to the tab. Now such a thing doesn't exist, I'm finding it harder to find the active tab. Can we increase the contrast between foreground and background tabs?

Comment 44

[Benjamin Xiao]

Christ this looks absolutely terrible and adds more vertical pixels to the interface.

At least make the tabs a little bit thinner.

Comment 45

[Paul McAuley]

This latest change looks reasonable in a restored window under Windows 7 (as per mock-up), however, in a Windows 7 maximized window (the more usual state) the tabs just looks wrong and out of place with tabs in the title bar. The size and curvature of the tabs in beta 12 was more consistent with the curvature of the Firefox button and with the window caption buttons.

Perhaps the appearance/height could adjust depending upon whether window is maximized or restored? In a maximized window you don't need such a tall tab due to the infinite top screen edge.

Comment 46

[Adam Kowalczyk]

Tabs look like they came straight from Windows 98 now.

Comment 47

[Brandon Cheng]

(In reply to comment #42)
> On behalf MozillaZine community: They are ugly. Period.

What purpose was this comment suppose to serve? It's just plain rude.

Comment 48

[Tss]

Since you are going for a more squared look, couldn't you drop the tabs border-radius too?  If the cursor is on the top edge of the screen, the clickable area of the tabs is reduced because of this. For example, app tabs have 32px width, but the top edge clickable area is reduced 7px each side because of the border radius; you end with only 18px to click the tab.

Comment 49

[Peter Henkel [:Terepin]]

(In reply to comment #47)
> (In reply to comment #42)
> > On behalf MozillaZine community: They are ugly. Period.
> 
> What purpose was this comment suppose to serve? It's just plain rude.

Please, ignore that comment, it was a mistake.

Comment 50

[Paul McAuley]

(In reply to comment #45)
> This latest change looks reasonable in a restored window under Windows 7 (as
> per mock-up), however, in a Windows 7 maximized window (the more usual state)
> the tabs just looks wrong and out of place with tabs in the title bar. The size
> and curvature of the tabs in beta 12 was more consistent with the curvature of
> the Firefox button and with the window caption buttons.
> 
> Perhaps the appearance/height could adjust depending upon whether window is
> maximized or restored? In a maximized window you don't need such a tall tab due
> to the infinite top screen edge.

... as a clarification: although I said the restored window looks "reasonable" with squarer tabs, that doesn't mean that I think they look better. On the contrary - the smaller and rounder tabs in the original Windows mock-ups still look better IMO and more in-line with toolbars etc. I hope that the smaller and rounder tab style can be re-instated in a future release when the devs have time. I also hope that this is indeed a change for a technical reason and not trying to follow some daft fashion set by IE9! (where, unlike Firefox, everything in the interface is more square)

Comment 51

[Please Ignore This Troll (Account Disabled)]

Tab bar is now so ugly, so square and so tall. Thank you.

Comment 52

[SpewBoy]

Why not use the method that Mac uses, but make a few changes:

Use border images and masks to get the shape of the tab, same as Mac, but make .tab-background-middle have a top border radius and push .tab-background-start and -end outside the tab and apply a mask to them, give them a set height that doesn't stretch with the tab and position them at the bottom. This would allow the tab to be stretched vertically without the masks distorting (which is the problem on Mac). The other issue is the .new-tab-button. We can't apply a background-color to this because we have nothing to apply masks to. The solution? Add .tab-background to the new tab button as well.

Really, there is no reason why the tabs can't be curved. It is entirely doable.

Comment 53

[SpewBoy]

Oops, that should read '.tabs-newtab-button'.

Comment 54

[Tan Wei Lin Jason [:Ryuji]]

For some reason the tab bar look broken now...

Comment 55

[Brandon Cheng]

(In reply to comment #52)
> Why not use the method that Mac uses, but make a few changes:
> 
> Use border images and masks to get the shape of the tab, same as Mac, but make
> .tab-background-middle have a top border radius and push .tab-background-start
> and -end outside the tab and apply a mask to them, give them a set height that
> doesn't stretch with the tab and position them at the bottom. This would allow
> the tab to be stretched vertically without the masks distorting (which is the
> problem on Mac). The other issue is the .new-tab-button. We can't apply a
> background-color to this because we have nothing to apply masks to. The
> solution? Add .tab-background to the new tab button as well.
> 
> Really, there is no reason why the tabs can't be curved. It is entirely doable.

Hm.. I was just about to ask how the author of Strata40 managed to get this done.

Tabs right now look a lot better than the previous ones, but the mockups sill mock us :'(

Comment 56

[SpewBoy]

Strata40 (the theme, not the style found in Stratiform) used border images for the tabs, like Firefox 4 currently uses, but the difference is the tabs in Firefox 4 need to have editable background colours, so backgrounds and border images need to be used. It gets more complicated. In fact, this is one of the most complicated parts of the entire interface (if not the most).

Comment 57

[*I need to change my userid so it's less racist)]

(In reply to comment #56)
> Strata40 (the theme, not the style found in Stratiform) used border images for
> the tabs, like Firefox 4 currently uses, but the difference is the tabs in
> Firefox 4 need to have editable background colours, so backgrounds and border
> images need to be used. It gets more complicated. In fact, this is one of the
> most complicated parts of the entire interface (if not the most).

what?
where is the logical bond between the need to use border-images and the need to have editable background colors?

Comment 58

[SpewBoy]

Border images have to be used to get the curve on the bottom. Background colours need to be used to add colour to the tab (XP will need different coloured tabs compared to Windows 7, etc.). Sure, you could use a whole range of border images for every colour but then it isn't flexible. An add-on can't just change the background colour with CSS.

You can't have an irregular shaped background that fills the bottom curves so you have to use masks, but if you use masks you won't be able to scale the tab vertically. It will have a fixed height or else the masks will stretch.

Strata40 didn't bother with background colours but then it didn't need to bother with Personas and add-on compatibility (to the same extent).

Sure, Mozilla could just use border images but they will get complaints from add-on developers stating that they can't change the colour of the tabs and the file size would increase due to the vast number of tab images required. Mozilla is trying to get away from images as much as possible. In a perfect world we would be using SVGs for the glyphs and tabs and no images would be used. This is not yet possible.

Comment 59

[Brandon Cheng]

SpewBoy:

So the method you mentioned in Comment 52 can't be implanted since it will prevent developers from being able changing tab colors?

Is it even possible to redo the tabs in SVG for Windows, or is the problem the time frame that fix would take?

Comment 60

[Frank Yan (:fryn)]

(In reply to comment #58)

SpewBoy is correct. Personas are the primary compatibility issue for now. It's not easy to address. Even the tabs on OS X look a bit odd right now with Personas. We'll try to target implementing the SVG curves for Firefox 5, so the tabs on Windows look at least as smooth as the tabs on OS X.

Comment 61

[SpewBoy]

My method would allow the tabs to be coloured and would allow the tabs to be of any height. The main issue is the new tab button, which is just a button so applying masks to it is going to be a bit tricky. It would have to be converted to a tab that acts as a button when clicked.

The tabs can't be done effectivelly with SVGs. SVG border images don't work (which would have been the best solution by far) and for some reason stuff like:

#SVG-tab:hover {
  fill: brown;
}

Does not work in the UI. It will work as a standalone web page but not in a toolbar. This means SVG tabs would need separate SVGs for the hover and selected states, as the colour can't be changed by using selectors like :hover or .tabbrowser-tab[selected] > #SVG-tab. They can only be changed by referring to the SVG directly like #SVG-tab.

Comment 62

[Janie B]

I don't get this ugly change between beta 12 -> RC. The beta 12 tabs looked great, and don't see why they couldn't have been left alone. You could have left all the technical SVG etc. fiddling and poking until Firefox 5 rather than this last minute effort.

In fact, I would go further and say that in my opinion the beta 12 tabs looked even better than the original mockups, which had a lot of unnecessary little extra curves at the bottom edge. The beta 12 tabs instead resembled better almost an inverted version of the caption buttons and Firefox button with a curved upper edge and straight bottom edge - these blended in much better with the Windows UI!

Comment 63

[Dirkjan Ochtman (:djc)]

I should note I also found the b12 tabs more attractive (on Win XP) than the rc1 tabs, but I can live with the rc1 ones; especially if bug 640490 gets solved.

Comment 64

[Chris]

Whatever the UX team did to the tabs between the latest beta and the 
RC was fantastic. The tabs look a LOT better in Windows 7.  Prior to 
the RC the tabs looked very out of place, now they have a very 
"polished" feel to them and seem to fit better with the rest of the 
UI. I suppose the height of the tabs could be reduced a little, but the corners look great.

Comment 65

[Vlad [QA]]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre

Comment 66

[SpewBoy]

Attachment: Method for tab curves

I've come up with a way of adding the curve to the bottom of the tabs, and allowing them to be coloured. Uses SVGs and PNGs as background images, using -moz-calc() to position them. The tab can be of any height / width and of any colour. The attachment is a series of CSS hacks to demonstrate the idea behind this method. It will make your selected tab curve out at the bottom, based on the future Firefox mockups (http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html). Only real issue with this method is it requires 18 images (9 SVGs, 9 PNGs), but it is by far the most accurate and fool-proof way of adding those curves.

Comment 67

[a4010956]

(In reply to comment #66)
> Created attachment 527539 [details]
> Method for tab curves
> 
> I've come up with a way of adding the curve to the bottom of the tabs, and
> allowing them to be coloured. Uses SVGs and PNGs as background images, using
> -moz-calc() to position them. The tab can be of any height / width and of any
> colour. The attachment is a series of CSS hacks to demonstrate the idea behind
> this method. It will make your selected tab curve out at the bottom, based on
> the future Firefox mockups
> (http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html).
> Only real issue with this method is it requires 18 images (9 SVGs, 9 PNGs), but
> it is by far the most accurate and fool-proof way of adding those curves.

though it looks nice at first glance - it is sooo wrong: just try to add a nice slim border to that tab (using border:, not with svg).

I know a way easier solution: just add 2 small elements - one at left and one at right from tab[selected="true"] and apply a gradient for them with ~45 (and ~-45) degrees angle from transparent color to the fully opaque color.
It is also possible to place a middle color between them which would serve us as the border to those triangles (well, actually they might be not just triangles with choppy curves, but slime and rounded, since we can use radial, not linear gradients).

Comment 68

[a4010956]

Oh, and as these 2 side elements will have z-index higher than active tab's - then they will lay above (above in z-axis, not y-axis) active tab's borders, so there won't be the active tab's border between them (actually it will be there, but it will be hidden behind those elements).

Comment 69

[a4010956]

Or, actually, it can be even a single element, which will lay as a foreground to the active tab, but that will require some color adjust, so it would look like a single element with the active tab.

Comment 70

[SpewBoy]

The solution I posted works with any element in the tab bar, including the .tabs-newtab-button. I can probably simplify it further to either be just one SVG file or one SVG and one PNG, taking advantage of -moz-image-region. This method does not rely on gradients or anything to colour the tab. All you need to do is specify just one colour and it will colour it. Obviously the method would need to be simplified if it was going to be part of the theme, because the code I provided is overriding the default tab code - it's just a hack.

Would your method work for a tab of variable height, and would it work for non-tab elements like the new tab button?

Comment 71

[SpewBoy]

Also, how would you add the border to the curve? You can't use gradients for an outwards curve... Unless you use about 9 of them one after the other.

Also a small correction: -moz-image-region should be -moz-image-rect.

Comment 72

[a4010956]

(In reply to comment #70)
> The solution I posted works with any element in the tab bar, including the
> .tabs-newtab-button.

My solution would easily work with _any_ element you like.

> I can probably simplify it further to either be just one
> SVG file or one SVG and one PNG, taking advantage of -moz-image-region.

How much will it slow down CPU and RAM consumption?
Gradient is a function, and PNG/SVG is an image (in case of SVG it is usually image+function). That'd be nice to have a fair comparison.

> This
> method does not rely on gradients or anything to colour the tab. All you need
> to do is specify just one colour and it will colour it. Obviously the method
> would need to be simplified if it was going to be part of the theme, because

And you could actually code all the graphics into base64 to minimize disk read actions. But currently there is an open bug, that won't let you store SVG in the css style that way.

> the code I provided is overriding the default tab code - it's just a hack.

That's not a hack, since this is the basics of how CSS (CASCADING) works. That is just a style that overrides another one. That's ok.

> Would your method work for a tab of variable height,

Yes, since this element can be set as a child to the tab-bar's elements and will always have the same height.

> and would it work for non-tab elements like the new tab button?

Sure, why not? This would work actually for every button you like.

(In reply to comment #71)
> Also, how would you add the border to the curve? You can't use gradients for an
> outwards curve...

Once again: I suggested to have 3 colors as gradients. 1 should be transparent color - that would be the upper part of the squared element which would visually cut it to the triangle (with maybe even rounded lines).
2. would be a 1px height (or using em to draw the border's shadow effect) gradient which actually will serve us as the border. So in case you want to change the border's color/style - you should edit this value.
3. bottom part of the same color as our parental element (be it a tab, or a new-tab-button or whatever it is).

> Unless you use about 9 of them one after the other.

Way less then 9.

Comment 73

[SpewBoy]

:0 I'd like to see your method in action. I'm intrigued by this, it's not quite clear in my head exactly how you would do this.

I can think of ways to do it with gradients, but it would take far more than 3 of them, and you would need to change the colour in each one individually to colour the tab.

My rather more refined method (refined from the previous example) allows you to edit one tab PNG image, rather like a border image, to whatever style is necessary, while the SVGs take the role of the colouring. The SVGs and PNG come to a total of 1.54kb. Each SVG is only 3 short lines of code, and the result is 99% pixel perfect to the Firefox mockups.

Comment 74

[a4010956]

CSS doesn't allow to create elements, so I can't show you how it would look like.

Comment 75

[Josh Tumath]

(In reply to comment #74)
> CSS doesn't allow to create elements, so I can't show you how it would look
> like.

Create a prototype of the feature in a HTML document and attach it to this bug. :)

Comment 76

[SpewBoy]

(In reply to comment #74)
> CSS doesn't allow to create elements, so I can't show you how it would look
> like.

Wait, if you need to create elements, how could this be used with toolbar buttons in the tab bar (new tab button)? No one is going to want to add elements inside toolbar buttons.

You can add elements using DOM Inspector (just tell us what to add and where) or you could make a prototype

Comment 77

[a4010956]

(In reply to comment #75)
> (In reply to comment #74)
> > CSS doesn't allow to create elements, so I can't show you how it would look
> > like.
> 
> Create a prototype of the feature in a HTML document and attach it to this bug.
> :)

I would need to copy (In reply to comment #76)
> (In reply to comment #74)
> > CSS doesn't allow to create elements, so I can't show you how it would look
> > like.
> 
> Wait, if you need to create elements, how could this be used with toolbar
> buttons in the tab bar (new tab button)? No one is going to want to add
> elements inside toolbar buttons.
> 
> You can add elements using DOM Inspector (just tell us what to add and where)
> or you could make a prototype

Sorry, too lazy to do this. I just dropped an idea.
Will you (or anyone else who is to code it) use it or not - I don't care: none of the bugs I opened got fixed. None of the bugs I voted for (and that live for years) got fixed. None of the patches I suggested to my bugs got reviewed.
I'm not sure it won't be Sisyphean labour if I bother myself creating a prototype.

Comment 78

[Asa Dotzler [:asa]]

Going on and on in a Resolved Fixed bug is certainly not the right approach. If you want to propose a change to Firefox, please don't piggy-back that proposal on a fixed bug. Create a new bug or post a demo to a website or something.

Comment 79

[Nguyen Bat Hung]

Base on Spewboy's code and Spewboy's Stratiform, I created this style:
http://userstyles.org/styles/50806/firefox-4-8-curve-tabs

Comment 80

[rob64rock]

(In reply to Frank Yan [:fryn] from comment #60)
> (In reply to comment #58)
> 
We'll try to target implementing the SVG curves for Firefox
> 5, so the tabs on Windows look at least as smooth as the tabs on OS X.

If a new Bug# has been filled, Do you happen to know the Bug# ?

Comment 81

[rob64rock]

(In reply to Frank Yan [:fryn] from comment #60)
> (In reply to comment #58)
> 
We'll try to target implementing the SVG curves for Firefox
> 5, so the tabs on Windows look at least as smooth as the tabs on OS X.

If a new Bug# has been filed, Do you happen to know the Bug# ?

Comment 82

[Nguyen Bat Hung]

Spewboy figured out a new method of curve tab that doesn't require *.svg
It has less code than before and uses only a border image, very simple and easy: http://userstyles.org/styles/50806/firefox-curve-tabs

Comment 83

[SpewBoy]

(In reply to Asa Dotzler [:asa] from comment #78)
> Going on and on in a Resolved Fixed bug is certainly not the right approach.
> If you want to propose a change to Firefox, please don't piggy-back that
> proposal on a fixed bug. Create a new bug or post a demo to a website or
> something.

I'm still not sure how this bug can be fixed, when the purpose of it is to make the bottom of the selected tab curve into the nav bar. The solution provided basically does the opposite to the original intentions, and does not follow Horlander's mockups.

The above method is probably the simplest, and will use less code than the current method used in Windows. It is also much easier to change the tab's colour. Just change the background-color and border-bottom-color and you are good to go.

This can be adapted to unselected tabs, too.

I'm pretty new to Bugzilla. If I want this to actually go somewhere, even if it is very much to do with this bug, do I still need to make another bug just because someone marked this a fixed?