The profile sub-tabs seem to be confusing the .r0 and .r1 styles. Everywhere else (including the same row of tabs, where there are no subtabs):
.r0 = 1st row
.r1 = 2nd row
but for the profile sub tabs this is reversed.
Ah got it. I was looking at the second row of tabs in Quizzes.
I like the more straightforward implementation of the tab metaphor. The way the color of the highlighted tab joins with the background color of the main content, and the 'shadow' that is cast over the unselected tabs. Maybe something like that could be used to tie the second row of tabs to the first, like the different colored section tabs in Amazon?
I've uploaded a slightly modified version which uses display: block on the a tag and increases the size of the clickable region to be the entire tab. This means that :hover effects can be applied in IE and Firefox without the use of .htc stuff.
The Outline Custom Elements... feature of Firefox's Developer extension is a good way to see the relative coverage of the a and the .tablink.
At the moment my modified CSS file has no hover effects as I removed the one's that used td:hover but you can add them back to the a tag. The slight drawbacks of this approach are a) that you only have a single image within the clickable area though a very thin image would be acceptable in the non-clickable div or td background (with appropriate padding/margin/widths set) but that image wouldn't be able to change on mouseover, whereas text effects and borders would and b) you can't do hover effects on the inactive tabs because they don't have a tags. I don't think this last one is a problem as such, as the animation should be a hint that something is clickable.
Do you know any way to stop the two rows of tabs being the same size? The first row formats the way I tell it to and then the second row seems to expand to fill the same width. Can I override that in CSS or is it an HTML thing? I always get confused about what's possible when styling tables with CSS.
Is this in a really recent version of the Moodle code? I thought I was fairly up to date with cvs but I don't seem to have the .activetwo class in my HTML (though I can see it in your theme CSS).
I'm actually quite interested in in the accessability side of web design, though I'd put myself in the real world accessibility camp with people like Joe Clark, so I'd probably quibble with broad statements like 'x is not accessible' (for who? in what way? why?) and would hate for people to think they can't use this theme for accessability reasons when the real world impact would be probably (in my humble opinion) be a net positive for usability and accessibility.
As far as I can tell, only those with a need for the largest of print and who also own rather large screens but don't use a browser (or an OS) with an adequate zoom function are likely to have any trouble with this theme's fixed width, and even then it's not an insurmountable barrier, like for example web pages that break completely if you don't have javascript enabled or text that is embedded in images (like many moodle theme's logos) that can't be read by the non-sighted unless you remember to add appropriate alt tags.
On the other hand, forcing all blocks to the right makes life a lot easier for those with audio browsers and phone/pda browsers as they get to the main content faster without having to scroll past/listen to various blocks each time. The thinner reading columns makes it easier for everyone but may be particularly useful for those with reading difficulties and the re-implementation of tabs makes it easier for those with poor motor skills to hit the target links.
So I would encourage anyone planning to use this theme to weigh the pros and cons and consider their audience.
The sizes are probably there because web pages take longer to load (and jump about in a disturbing manner as they progress) if the browser has to wait for each image to download before it knows what size space the image will fill.
The way forward is probably to specify all images in the CSS, this is better for custom themes, accessibility, small screen rendering code size etc.
Which reminds me, I was going to post about how exactly we should progress in that direction.