David Scotson

I think I've had this exact conversation before, but putting my sense of deja vu to one side:

I originally thought you were talking about the Calendar Block sticking out more than other blocks in the same column as itself, which I believe is an IE-only problem. But now I think I've clicked that you are talking about the fact that whichever side of the screen you put the Calendar block on, that entire column of blocks will be pushed wider than the other column, a problem which affects both Safari and Firefox.

The two problems probably have a related root cause but I think the first problem is more jarring visually and that's the one I've always meant to track down as it kind of bugs me whenever I see it. The second is only really a major problem if you're building background images to exact pixel dimensions, which I don't think is advisable in any case e.g. if a user increases their text size you end up in the same situation. So if you want/need the blue triangle to be fixed with regard to the top-right hand side then background-position is probably the 'correct' way to do it while retaining some level of fluidity.

The only time it gets complicated is when you want to position something at both ends of the block heading, though that's doable too, with a bit of finagling.

I've noticed this before and always meant to track it down, but the fact that it doesn't affect either Mozilla/Firefox or Safari means I'm only intermittently reminded of it.

If you want a solution for your particular theme then you could extend the image to the left, and use background-position: top right to anchor the background to the right, where the blue triangle is. Probably the quickest fix for you, and also helps when people increase their text size. Remember also that longer titles can spill over onto a second line so you probably want a slightly deeper image.

Will that actually work? I've not tried it but thought, from a brief poke around, that the gradients were defined in multiple places with various levels of specificity (e.g. there's three references to gradient.jpg in styles_layout.css)

But it wasn't the amount of work for someone who knows what they are doing that bothered me (though I'll come back to that), it was more the surprise of someone who knows a bit of CSS and is savvy enough to duplicate and rename the folder and then starts to explore by changing things--finds that doing so works as expected--and then gets confused when deleting things from the CSS doesn't appear to have any effect.

Splitting it into two says clearly: here are the things you can and should change, and here are the things that you shouldn't (unless you really know what you are doing) and allows both deleting and changing of a line in the CSS of a duplicate of the standard theme to have an instant and obvious effect.

The other thing that I thought would be a roadbump for HTML/CSS hackers is the styles.php. I looked at the function in weblib but I'm still not sure what it's doing. Perhaps there is a way to do it with standard HTML/CSS techniques, in a way that would make sense to CSS jockeys.

Returning to the issue of effort to override, the one thing that did seem a lot of effort to get rid of was the Mozilla specific rounded corners. I was trying to duplicate the look of my University's front page (which doesn't use rounded corners) in a 1.5 theme, and eventually had to delete the styles_moz.css from standard theme as the thought of going through and neutralising each one in turn made my heart sink. (It also doesn't help that styles_moz.css prevents you from validating your CSS files as it uses non-standard CSS rules.)

Sorry, this turned into a bit of a mad ramble, I should really start threads as these ideas come to me.

Re: the table headers

I was just about to 'fix' this problem too, though I'm coming at things from a different position from Gustav's.

I'd noticed that just using th in the CSS to style table headers, affected all table header cells in the entirety of a Moodle site including those in user entered content.

I thought this was a bug because the style applied made the tabular content look like part of the Moodle interface (gradient background etc.) rather than part of the user entered content.

And talking of table headers, in the current style sheet system, the standard theme plays a dual role as a scaffolding for other themes and the default (and much nicer on the eye, imho) theme. Will these roles diverge into two sepearate themes, one with the basics and sensible default values designed to be overriden and another with the niceties, 'personality', and elements that require a bit of work to create and change (e.g. gradient backgrounds) of the standard theme?

At the moment you have to undo a lot of things before you can add your own styles e.g. changing the color of the table headers doesn't work because there is a background image over it. You need to both change the color and set background-image: none. It's also confusing, if you base your new theme on the default one nad start modifying it, that deleting styles has no effect as they are all duplicated.

Linking in a frame may be the best solution overall, because otherwise you are relying on the end users to have a fairly sophisticated grasp of CSS. It seems likely that if people think they can cut and paste text and styles from external pages they will end up with various strange errors introduced by their own changes to the themes CSS, even if the Moodle provided CSS is smart enough to avoid this problem.