David Scotson

There's a readme file in the folder, which should be displayed when you switch to the theme. It says (amongst other things):

customising the header image

The blue header is designed to be easily customisable. To replace it with another image you can either:

• upload an image named personalheader.jpg to your Moodle's Site Files.
• upload an image named personalheader.jpg to the root of the theme directory.
• replace the kubrickheader.jpg in the theme directory with one of your own creation.

The first method will take precedence over the second if both are used at the same time. The third method requires extra effort to ensure that the image matches exactly with it's surroundings.

if you need any more help let me know. I'm supposed to be prepping an update to Kubrick, but my development server is suffering from a power cut. I'll probably kill time by making a start on moving the documentation to the Wiki so now's a good time to ask questions.

Is this to be a short-term change intended for 1.6 or for the longer term?

You mention concerns so I suppose I should mention that I'm always concerned about accessibility changes that see removing tables as a primary goal rather than a side-effect of larger changes. Much like 'table-free web designs' that were in vogue a few years ago, it seems like a strangely focussed technical accomplishment to trumpet in the context of a big, fuzzy, ongoing user-experience challenge.

The fabulous, though slightly dated, dive into accessibility by Mark Pilgrim makes basically no mention of layout tables amongst its many recommendations, suggesting only that they be made to linearize properly and are given empty table summaries (see day 19: Using real table headers in particular the A very important note about layout tables section, and day 20: Providing a summary for tables, the layout tables: how to do it section).

Joe Clark's Building Accessible Websites, especially Chapter 10, Tables and Frames, comes out strongly against the demonisation of layout tables with comments such as:

Theyre not per se inaccessible. Theres a misconception that adaptive technology cannot read and understand tables. In fact, all major screen readers (on Windows, at least: OutSpoken on Macintosh is an exception) have specific commands for navigation inside tables. Since screen readers can also drive Braille displays, table-based layouts are accessible even to deaf-blind visitors. Layout tables pose surprisingly few access barriers.

I realize that the web has moved on since these things were written, and that CSS layouts have always been able to do some amazing things that Internet Explorer has finally caught up with, but I have to confess to some surprise at the focus on removing tables for accessibility reasons when there's so many other things to be done.

I think the original typo might actually be better (if it's not the cause of these crashes). Having looked into it, there's code within style_sheet_setup which looks like it compares the lastmodified time with the lastmodified time of each of the .css files it reads in from the theme.

Therefore an incorrect but old time (e.g. 0) is better than an incorrect but newer time (e.g. right now) as it will get overwritten with a newer, and more correct time anyway.

But, having said that, it appears that that code isn't working as it should. I've just looked at a site that was set up on the 24th of last month, with a new .css file created and added to the theme a few days later. I can see my new CSS when I access styles.php and yet the last modified time is still the 24th. So something odd is going on.

Maybe I'm missing something, but according to that code snippet, the file 'styles.php' is asking for the time of the last change to the file called 'styles.php' (that is, itself). But that file also has at the top a comment saying:

THERE SHOULD BE NO NEED TO MODIFY THIS FILE!! USE CONFIG.PHP INSTEAD

So even if it's not causing the crashing, surely that's a bug as the lastmodified time of the stylesheet will always be wrong.