Modify layout to support RTL and Fluid width in all browsers (except IE6)

Even though this has been committed I'm marking as needs review - the patch was pretty big change and even though the layout used is extremely well tested in real live sites (over 3000 sites use it) we should still be testing this in all major browsers and getting feedback, esp in RTL.

Need to account for page width in the overlay, here's the patch I want to commit:

http://drupal.org/cvs?commit=369516

Horrors of horrors I made a mistake during the implementation, I just double checked against my core layout and I made an error, so when screen is resized the sidebars can jump out of alignment in IE, this is hasLayout issue, no biggie!

Yes, I have fixed it, I am just cleaning up the code now and will commit it, it also solves the whole issue with IE6 tabs (a side effect of reworking zoom as it applies to anchors).

I have committed it.

The main issue took quite some time to track down - it was not the layout per-se, but rather the header height - IE6/7 were loosing hasLayout on the header (my assumption that is was in fact hasLayout), I needed to set a height on the header, for which I used min-height and a min-height workaround for IE. This solved most of the issues with the sidebars and main-content loosing their layout and jumping out of the main-columns DIV.

Seconding I reworked how zoom: 1 applies to anchors and specific it to only apply to region anchors (and .region itself to prevent a jump bug where on focus links jumped to the left). This solved the horrible tabs issue in IE6 since zoom: 1; messed terribly with them.

Third, I ran into another issue with the floating logo and site-name, again this was messing up IE6/7 in RTL, so I wrapped the logo in its own DIV and did a few other things I cant quite recall right now and again the issues were resolved.

So this is quite a big update and needs further testing, everything appears to be working fine. The acid test is to resize the viewport when in RTL mode (for IE6/7 only, all other browsers are fine).

I've tested the changes in IE6, 7, 8, Firefox 3.6, Chrome and Opera 10. Will continue with more testing in more scenarios throughout the day but I'm pretty confident we've cracked it. Part of the problem are the new wrapper divs that come in D7 that my original layout does not have (its more lightweight), so accounting for the differences was the major task.

http://drupal.org/cvs?commit=369876

Looking at that screenshot the main column looks too wide and the browser is not less than 960px, so its a strange one indeed and not one I can reproduce (but I have both sidebars enabled), which sidebar do you have enabled and what blocks are in there.

At this stage Jarek you should be trying for an RTBC and working with the community to fix minor issues - this must be a very minor issue because in extensive testing I cannot reproduce any problems what-so-ever.

I have no idea why you keep steam rolling over the work of others, it just disenfranchises the community and makes them far less willing to back the project, evidenced by the sheer lack of people in your issue queue compared to Bartik.

If this theme doesnt get an RTBC by mid to late June its out, period, forget it. We need stable code and wide user testing.

I'd be more than happy to show you how it works, adjusting the gutter is actually quite easy. Maybe you over-thinking it, the layout is actually cunningly simple.

At the end of the day the underlying layout is not a major concern to me, what we can't afford is to go back into long winded testing and development, you can't RTBC this stuff really, it has to go through major testing if its a new layout, which is why we punted for one thats been around for 3 years and has 3000 sites using it.

#22 - no support for RTL, the sidebars don't flip - this is basic requirement for RTL.

Looks like we've gone back to this changing widths *feature*. I call this a bug because its very disconcerting when surfing around my site, it seems to jump around and is imo is kinda weird, and probably too radical for core.

Also the the admin section does not fit into 1024px, this is bad. It makes an assumption that /admin means User1 access, but this is not always so - often sites give limited access to some admin pages to site maintainers, that may work just fine without this extra width, such as the blocks page. I might use Theme Key to set Seven as my admin theme (based on role) and give my site authors access to moderation pages that uses the front end theme. Again, I think Corolla is trying too hard here, doing to much.

#24 - zoom:1; was required in our layout for sidebar links (because it uses negative margins) - its pretty easy to make a fixed width layout work in IE6 RTL. We had it working identically to every other browser - flexible width, RTL, sidebars flipping, the whole works, and well tested.

#24 - inline-block is not working in IE6/7, in both the site name is sitting below the logo.

So, at the end of the day this is as a regression - its going to take a full round of review, testing and approval before we can even think about re-rolling the core patch (we need to -1 the current core patch immediately, if this gets committed).

I'm not quite sure we have the resources to do that at this late stage - the way I see it the theme was meant to be ready by the 17th, we blew that and asked webchick for some more days which were granted. In the end we made it, but now I think we may be abusing our windfall of a delayed beta, by regressing the theme and working forward again, when we should be in full blown user testing, not going back to basics.

Like I said, I dont really care about the underlying methodology or code (not-with-standing tables...) but more about supporting all requirements (flipping sidebars is a basic requirement of RTL, something much discussed in many other issue queues, and something that was fixed in D7 for Garland), and having the time to review, test and approve such a major change.

eigentor, I haven't found this to be the case - given good documentation users find this easy to work with, once they "get it". Zen used to get the same criticism, but time has shown this to be wrong, users do get it and do change it.

I can't see that its any easier to change the layout using the implementation in #22, look at how many places you need to edit values.

Well good luck with those issues. I'll leave my final review for the core patch which I assume will be coming in the next few days. We really need it ASAP if you plan on committing these changes so it can be reviewed and tested which will take some time.

BTW, zips are fun but no way to work seriously, patches against Corolla HEAD are much better for testers.

This is not critical.

I am deprecating the core patch as out of date since you have regressed the theme and introduced a large number of new layout issues that must be fixed before you can roll a new patch.

One reviews patches Jarek, this has already been committed.

I've already been through a long process of posting issues, screen-shots and patches. I have no intention of doing it again. In any case there's not much point, most of the issues are known to you, raised as far back as March 15th, which you are still ignoring.
So really, what the point in raising them again, you're just going to ignore them.

- I will note though there in the latest Head there are some very odd new issues with this theme, they need to be fixed.

@36 - and you just think we should take your word for it and RTBC this and roll a new core patch? I must have seen you post "I'll have it all fixed tomorrow" half a dozen times over the past 5 months and not once has this transpired to be the case.

What you're not understanding is that any time you make a major change there will be a new crop of issues, and these take time to FIND, let alone generate the fixes for them.

You need a team of people to do this testing, if its not tested (really really put through the ringer by a large number of contributors) then how do we know its OK? We don't. This is the primary reason why over those 5 months developers far more experienced in Drupal core DEV than yourself have implored you not to run off an rewrite the code base - because it needs to be stable over time for incremental fixes. The theme we inherited around the due date was so borked in IE we were forced to do something drastic and fast. It caused issues (of course it will cause issues - we knew that), but instead of working through those issues incrementally you have decided to go it alone.

FWIW the theme is borked out of HEAD. I cant even test a large portion of it because it doesn't work in overlay. Garland does so its not my installation (HEAD).

Most of what you posted in #31 is a complete cobblers and needed minor revisions or are because you are probably running an outdated version of D7 (theres been some changes to theme_field which I was running before it even got committed, since I wrote the initial patch for core).

I think its a bit on the nose the way you posted that in this fashion, we worked really hard in a very tight time frame and of course we missed small things, but it did not discount the huge number of things we did fix and improve, including the really big hard issues.