Bartik Tabs broken in Firefox

I have refactored the tabs to use a different technique for most browsers (floats) which works much better in standards compliant browsers and solves the IE8 and Opera RTL issues. For IE 6, 7 we take the floats off and use display:inline;.

I'm getting a lot of big horizontal scroll-bars under different conditions in different browsers although I do not think they're tied directly to this patch (needs testing).

#1: bartik-refactor-tabs-for-rtl.patch queued for re-testing.

The horizontal scroll bars were due to the skip link CSS, which has been fixed. I'm going to re-roll this shortly, it needs to go in because IE is the most popular browser in RTL speaking countries (I mean by miles, like 90% dominant), we really must support it properly.

tagging

Updated patch, didn't have to as much this time around as some other patches have been committed.

It would be very good if this did not get committed until after #660614: Remove #block-system-main dependency, fix font sizes, remove crufty CSS, in which case this will need to be re-rolled.

Good for testing now and discussing the approach - this is how I normally build tabs - one of the main differences is that I do not rely on padding to set the height of the tab because this is fragile across browser (different browsers can render padding differently) so we get issues like #844456: Main menu is off by one pixel in Opera for Linux cropping up from time to time. What we do instead is rely on the font size and line-height which I have found to be much more robust - if you set line-height and font-size the same it will center align the text vertically.

Hmmm...

1) rgba is still in the patch
2) patch in #8 will not work correctly in IE6 or 7 in RTL mode

Citing "your patch changes many lines" is totally irrelevant. What is somewhat relevant is the amount of code - the patch in #8 simply adds more CSS, whereas the patch in #6 removes many lines.

Back to #6 please, if you have a review that would be good.

OK, I'll get to this, feel free to beat me to it :)

Hmmm, ok well I made a series of screenshots to show:

1) the patch from #14 and how it fails in RTL in IE and with text resizing.
2) comparisons for bartik-refactor-tabs-for-rtl_3.patch

You will see what I mean about your approach not working with IE and text resizing - there are several issues not accounted for. I would very much appreciated if you would work on the actual issue and stop spreading FUD about the patch in #6.

Please do not assign yourself to these issues - we want to keep them open to everyone, if you assign yourself others may not take up the challenge.

This new patch accounts for the 1px margin (#10) and takes account of the featured active tab which I forgot about in #6 (ops...).

This screenshot shows the patch from #14 and how it fails badly in IE8 - the first two images are with bartik-refactor-tabs-for-rtl_3.patch, the 3rd and 4th shots are of the patch from #14

This is bartik-refactor-tabs-for-rtl_3.patch screenshot comparisons, IE6 looks the same as IE7 - note the small difference in the gap between the tabs in IE7 in RTL mode - this is pretty hard to solve and probably easier when #923928: theme_links adds a new line ('\n') after <li> - leads to space between horizontally aligned list elements lands

@munzirtaha - I would also like the point out that I am not playing some sort of "my patch is better than yours" game - that is actually pretty insulting, given the thousands of hours I have contributed to D7 over the past 18 months or so, and the thousands of lines of code I have written, and hundreds and hundreds of issues worked on with many many other contributors.

LET ME BE CLEAR: I only look at the techniques used - I know in one glance that the approach currently used in Bartik has some fundamental issues - its fine in LTR and if you don't intend to support text resizing - however it simply not robust enough for the harsh reality of a core theme. What you are criticizing as "unnecessary lines" are in fact a full-proof backstop to the kind of failures Bartik is currently experiencing.

You cannot make a silk purse from a sows ear - its as simple as that. You can dress up and make-over the current approach all you want, but at the end of the day the approach is flawed - that you cannot fix that without changing the approach.

What version of Firefox are you running - the patch is developed in Firefox 3.6.x - when you make a browser report its very handy to have screenshots to visually show the error, for example I have no understanding what you mean by "opacity disappearing". I can't fix an issue that I cannot see after testing this in every major browser on my system.

Wow, crazy - lets see if we can get some feedback from the others, what OS are you using?

Also - could you check the markup and see that they are not all getting the active classes for some reason? If each link is active they will be all white. Outside chance but worth checking.

Embedding the image from #20

Yes, we really must leave the design as faithful to Jens vision as possible, we should not be changing the design at this stage, just fixing bugs.

The patch in 15 needs a reroll since the big font sizing patch landed

Re-roll chasing HEAD, also fixes a regression for IE6/7 tabs that stemmed from a typo in the Fix the Header patch that just got committed, my apologies for that.

OK, getting tired...

This screeny is still relevant (its the same code): http://drupal.org/files/issues/bartik-tabs.png

Also did a quick test in IE9, attaching screenshot.

Retitling to reflect the issue better - in short the tabs are not working correctly in IE6, IE7, or Opera RTL. The patch basically changes the how they are positioned, by using good old fashioned floats instead of display: inline. This is the only way I have found to reliable ensure RTL works accross browser, there are probably other good methods, but this is one I have used for years so I have big faith in it.