So I’ve been working on branding meeting workspaces and looking at some of the issues within them. I took a look at the branding I’d been building on a meeting workspace:
Yup, lots of nice rounded corners, but you can see that the meeting workspace tabs are currently unstyled. I decided I’d try to make them look just like the ones at the top, and replace that pale blue bar with the green one, like the one at the top.
To do this, I’d need to increase the height of that bar. I broke open the IE Developer toolbar to take a look:
What?! The height and vertical alignment are inline CSS! I couldn’t believe that! I checked the HTML:
I can’t override that – I’ll have to change the Master Page to remove that style. That happens sometimes, and I’m creating a custom master page for this anyway. I took a look in the code:
So the inline CSS is actually generated by a WebPart?! What fool wrote this? Well, clearly someone who figured that nobody would ever want tabs that weren’t exactly 23 pixels high. I mean, using an inline, hard coded CSS class would be poor, but I could live with. But inline styles themselves? Idiots!
Okay, so I can’t readily change the height of the tabs. I’ll squeeze my design a little (well, a lot) to fit. Now, can I get rounded corners? Nope! There’s no anchor tag on the selected tab. Nor is there an element on the right. And the tabs aren’t fixed width. And I can’t readily change the code that is generated. Without that, I can’t do rounded corners (or at least, I couldn’t find a way).
I suppose I could write a control adaptor, maybe, but that seems overkill. Square tabs (23 pixels high) it is then.
What is is about meeting workspaces that they’re so badly built? There’s no good reason for them to have their own master page. There’s no reason to put the styles in CSS. And why did they break (for once) from the usual tables within tables within tables approach of the rest of SharePoint? Not that I’m advocating that, but I’d’ve been able to get my rounded corners then.
Andy Burns' Blog 
Hello,
I think you can change width and height of the bar to change what was specified in the inline code.
Use the class .ms-tabselected{} and put “!important”
example:
.ms-tabselected{width:XXpx!important;height:YYpx!important;}
Hope it can help you…
Sorry for my bad english!
Truelle
Hmm. Good thought – I’d had a blank moment and forgotten the !important marker. I don’t like using that though – the point is that the user should be able to override my CSS classes in case they have certain needs regarding colour, size, etc..
Not that that seems to be how CSS is used in practice, but anyway…
Andy,
I feel your pain on the inline CSS peppered throughout the MOSS application. Given the absolute enormous size of the core.css, a few more selectors couldn’t hurt!
The !important marker would serve as a work around but again, is not the standard way of doing things. The inline css should be removed.
The same could be said about the blatant disregard for using semantic xhtml or HTML. If you dig deeper throughout the source, you will notice more html elements used in places in which they are not to be used. This all makes for an interesting experience when customizing the MOSS UI.
Well what really seems bizarre is that application.master is very similar to default.master, and meeting workspaces have their own master that is very similar to default.master – so why don’t we just have one master page!?
But yes, the MOSS dev team should check source control and if anyone checks in any inline styles, they have to bring doughnuts. Baked in inline styles or image references are an absolute killer.