I'm not quite sure whether I like that direction.
CSS like the following, using "Descendant selectors" aka "Contextual selectors" (http://css.maxdesign.com.au/selectutorial/selectors_descendant.htm) leverages the full power of CSS an is a recommended best practice:
"Descendant selectors are an elegant way to apply styles to specific areas of your page while reducing the need to embed classes within elements." (http://www.websiteoptimization.com/speed/tweak/descendant/)
body.onsale .sidebar {
background-color: #FFA500;
}
"In OOCSS, instead of a single class applied to the body of your page, you would create a new class for each type of element that you wanted to change for the sale. Here's what the sale style for the sidebar might look like:"
.onsalesidebar { /* extends .sidebar */
background-color: #FFA500;
}
IMO this paves the way to the CSS disease called "Classitis" (see Avoid "divitis" and "classitis") which won't make for better maintainable code at all.
Frank
CSS like the following, using "Descendant selectors" aka "Contextual selectors" (http://css.maxdesign.com.au/selectutorial/selectors_descendant.htm) leverages the full power of CSS an is a recommended best practice:
"Descendant selectors are an elegant way to apply styles to specific areas of your page while reducing the need to embed classes within elements." (http://www.websiteoptimization.com/speed/tweak/descendant/)
body.onsale .sidebar {
background-color: #FFA500;
}
"In OOCSS, instead of a single class applied to the body of your page, you would create a new class for each type of element that you wanted to change for the sale. Here's what the sale style for the sidebar might look like:"
.onsalesidebar { /* extends .sidebar */
background-color: #FFA500;
}
IMO this paves the way to the CSS disease called "Classitis" (see Avoid "divitis" and "classitis") which won't make for better maintainable code at all.
Frank
Thanks to following another of your links, Frank, I found http://natbat.net/2008/Sep/28/css-systems/ (via http://moodle.org/mod/forum/discuss.php?d=108771#p477940).
(Actually, I read the PDF version http://clearleft.s3.amazonaws.com/2008/cssSystems_notes_small.pdf)
It thought that was very good. The author clearly knows what she is talking about, and has numerous good ideas.
Just one quote I want to pull out (of context):
"phrase your selectors based on WHAT it is rather than WHERE it is"
I think that is the good point that OOCSS was trying to make. I did not agree with everything in the OOCSS article.
I think Moodle could usefully learn a lot from the CSS Systems article.
(Actually, I read the PDF version http://clearleft.s3.amazonaws.com/2008/cssSystems_notes_small.pdf)
It thought that was very good. The author clearly knows what she is talking about, and has numerous good ideas.
Just one quote I want to pull out (of context):
"phrase your selectors based on WHAT it is rather than WHERE it is"
I think that is the good point that OOCSS was trying to make. I did not agree with everything in the OOCSS article.
I think Moodle could usefully learn a lot from the CSS Systems article.
I would probably stick it under Development:Developer_notes in the first instance. The article was good, but it is not the sort of thing that gives you a simple recipe for what to do in your system.
It is the sort of thing where it will take a lot of discussion and a lot of input from lots of different people to get it right. We have had some really great examples of that for some of the things on the Moodle 2.0 roadmap. Lots of arguments to finally get to a specification that everyone is happy with, and which is better than any one person could have come up with on their own. Look at the page history for the Community hub and Development:Web services / Development:Web services security pages as examples.
It is the sort of thing where it will take a lot of discussion and a lot of input from lots of different people to get it right. We have had some really great examples of that for some of the things on the Moodle 2.0 roadmap. Lots of arguments to finally get to a specification that everyone is happy with, and which is better than any one person could have come up with on their own. Look at the page history for the Community hub and Development:Web services / Development:Web services security pages as examples.
Created a new section as you suggested: Markup & Theming as a reminder.
Here are some related articles to the one mentioned by Natalie Downe:
"What's so bad about CSS frameworks?"
by Raena Jackson Armitage
http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=228&format=html#5
"CSS Frameworks and Semantic Class Names"
by Kevin Yank
http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=260#5
"What's so bad about CSS frameworks?"
by Raena Jackson Armitage
http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=228&format=html#5
"CSS Frameworks and Semantic Class Names"
by Kevin Yank
http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=260#5