Talk:Theme changes in 2.0
I think this is a great system. Some comments on specific issues:
1. Browser-specific stylesheets - is it time to move away from these?
The OU system for this is a lot better. We add special classes to body (in addition to whatever's normally there), so you have
<body class="ie ie7">
or
<body class="gecko gecko19">
Classes indicate the browser engine and version so that we can specify a generic engine if a problem affects all versions, or a specific version.
This means you can put the IE exceptions right next to the standard rules and they can be included in all stylesheets for any module. So you do
#mypage .whatever {
/** normal rules */
}
.ie6#mypage .whatever {
/** broken rules */
}
Note that we don't just need exceptions for IE. Over time we've needed rare (single) exceptions for Firefox (hence 'gecko' stuff above; the issue was actually only in gecko18 I think) and WebKit too.
IMO this system should be adopted in core Moodle. It's very simple and is far preferable to either CSS hacks (appalling) or separate stylesheets (unmaintainable).
2. Debugging mode
Maybe developer debug mode should send a special revision number (rev=debug) in order to regenerate the css every time, and send it without the expires header etc. That would probably make it pretty slow though.
Alternatively, this could be an additional option in the debugging page so that you can turn on 'CSS debugging' which would sent the rev=debug on every page, and turn it off when debugging other stuff that isn't css.
having to manually update the number every single time you change css would be a huge annoyance when debugging css problems imo so I think one of these solutions is better.
3. Removing comments
Removing comments would be great.
It's not only a performance issue, but:
a. Because of the performance concern developers (including me) tend to not include comments at all, this is really bad for maintainability.
b. If a student looks into our code and it says something 'unprofessional' like 'only needed because IE sucks' they might in theory complain - yes I have genuinely had a student complaint for using the word 'sucks' in public - so this is another discouragement for developers to comment properly.
4. Performance
If these are served for lifetime (ie expires 10 years in future) as they should be, I think this would actually improve performance for most sites (that see a lot of repeat visits), even if it takes 50x longer to serve the css itself...
That's it, everything else is awesome. :)
2. from sam's suggestions is already done.--Tim Hunt 17:00, 21 August 2009 (UTC)
