I played with the calendar month block to no avail. But, I am really just sort of shooting in the dark. You can see the problem in action at www.classroomrevolution.com/moodle15/moodle/
I am creating a new theme and I noticed the block problem there.
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.
I have the image longer on the left, I will have to play with the position css to try and make it work on either side correctly.
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 like the xxx-Nuke way of theming which breaks the sideblocks in such a way as to allow more detailed graphics which do not break when a window is resized.
Something like this:
Those would be the table cells. I remember Martin mentioning this before... its probably set for 2.0.
Thanks for the advice David, I am going to alter the graphic I think.
@Jeffery, you wrote: I like the xxx-Nuke way of theming which breaks the sideblocks in such a way as to allow more detailed graphics which do not break when a window is resized.
Your proposal sounds great and fascinating. This approach makes advanced decoration of the blocks much easier.
But it will be reached by somehow triple the number of cells for each block - and this makes me fear about the load increase Moodle pages will produce.
And wouldn't those extra "border cells" make simple looking blocks much more difficult to design?
I don't see so much advantage to assist the proposal to change the way the sideblocks are built.
@David - How is your work on table less sideblocks going?
An example PostNuke block using the AutoTheme system, which is a third party application for PN, allows pretty extreme customization without touching the core code.
Example: (White lines represent cells)
Most PostNuke sites I have load pretty fast.... but PN is a much different animal than Moodle, and I agree that this type of table cells/graphic theme model might be a huge problem for many.
We should probably just leave things as they are... it works, there are plenty of customization options, and it works.
The Calendar block is bigger than the others, by 20 pixels. This is done through the preferred_width() mechanism; it just wants to be a little wider (but all other blocks on the same side will become wider as well).
The reason for this is that it's really not very nice aesthetically with 180px width; there's no space to cram all the colored borders and table columns and whatnot in there. So I figured that since we already have this mechanism in place, why not use it?
Now, what to do if we don't like the result? One thing could be to edit the block file and simply remove the function preferred_width(), end of story. Or you could edit your course format files to apply stricter restrictions to sideblock width (currently allowing 180 <= width <= 210). Or we could make a visual setting somewhere that forces all preferred_widths to be ignored (admin/visual settings or something).
I have to say though, that for cases such as this (put background image behind title), the best way seems to be anchoring the image at one corner and making it larger than necessary in size so that it can accomodate a widened title. This is basically standard procedure in every CSS styling technique, because there is no way to make sure that a box will have known dimensions beforehand if its contents are dynamic. It doesn't matter if it's a table cell or a div, you just cannot take it for granted. (Unless you size it explicitly and give it overflow: hidden, but that's not applicable to many cases).
Your screenshot shows styling which cannot be accomodated in a fluid-width design without table cells at first glance, but I 'm not sure that this is the end of it. Consider one of the lines where we have 3 columns side by side, and the center one is fluid to accomodate growth.
I believe you can do that just fine without tables as well. The technique is described in Douglas Bowman's superb Sliding Doors of CSS article, but the principle is this:
- The whole row is of course a DIV. Your main background image will be the left-hand starting graphic plus a "long" stretch of the center graphic, so as to be fluid. The right-hand graphic will be a separate image.
- Position your background at the top left of the div (top left of 1st column in your case), making sure it's longer than absolutely necessary to accomodate growth.
- Give horizontal padding to the div so that any text it might contain (it doesn't in this case, but just to be complete) doesn't get over the two nice side images (in effect, give it padding of as much as your two side cells are wide).
- Give the div position: relative, but do not otherwise mess with its positioning. This is required for the next step.
- Put another div inside this first one. This div will contain the right-hand graphic. Give this div position: absolute; top: 0px; right: 0px; and size it explicitly (you can do that, you know the exact dimensions of the right-hand graphic).
- That's all, you now have a flexible layout as the doctor prescribed without any tables.