Hi all,
This is an interesting one, and I bet every developer & designer has his or her own opinions and preferences.
Myself I heavily favour classes over ID's, and I prefer to use a dual classing system.
Before you ask I'll explain it all here.
First up the easy part, avoid ID's except where the generated content needs to be 100% specific, normally this is only required when
JavaScript is on the scene.
Thanks to JS libraries such as YUI navigating the DOM using classes is more accessible but it can still be a nightmare and it's hell of performance hole.
The backup to that is that Moodle is huge, and contrib doubly so. There have been some nasty ID clashes in the past which of course breaks
XHTML and sometimes JavaScript as well. If we went with an ID solution we would need to create some sort of structure for creating ID's so that people create unique id's and don't create id's such as 'dock' ;)
The dual classing system I prefer; Lets say I want to print a list of a forum posts on a new page I am creating within the forum module. So to start with I have a ul + n*li. The first thing I am going to do is wrap it in a div because a list is structure not design.
I want the list to look like a normal container on the page, so I add the class 'generalbox'. But I don't stop there because generalbox tells me nothing about the container just that it is one (duh!) so I add a second class 'forum-user-posts' which describes the element.
The next step is to add content descriptive classes, an example for this scenario is 'noposts' which could be added to the container if the user has not made any posts.
At the end I have added three classes of classes:
- A class to give the element the most basic of general looks.
- A class to describe the nature of the element.
- 0..n classes that describe the content or state of the element.
Next for styling, I try to never add styles to the generic classes (generalbox) I always try to style on the specific class ('forumposts').
The general class needs to be kept that, styling it can be dangerous as you can never be sure what the future for the page holds, and it's likely at some point or another more generalboxs are going to be added to the content, perhaps even by JS and your CSS is going to need to tidied up by an enraged designer or developer.
The only thing to keep in mind with this system is good old IE6 (if you still care about that) because when processing a chain of classes in CSS IE6 only processes the first two classes in the chain. Because of this I try to avoid using cumulative descriptive classes, usually I can get around this through wrapping the element in additional descriptive structure or through restructuring the plan I had for classes.
The final thing I try to do (although I forget to often) is to describe the id and class structure in the CSS comments or in a doc somewhere so that designers can get an instant feel for what is going on rather than having to try to generate all possible states for a system, or worse yet refer to code.
This is probably one of the biggest things we could do for designers, as a developer I have no problem with reviewing code to work out the structure of a system but I bet that's not how most people feel.
Anyway enough about what I do, what could be done to create an overall better system.
Well I think asking all developers to become designers as well is about as silly as asking all designers to become developers. Because of this the structure that gets created around the place is likely never right the first time ( I realise of course right is the wrong word to use ).
I think the biggest problems we have at the moment are that we have no guidelines for coming up with class names and id's, and second that the structure we as developers create is often lost the moment we commit it with only the creator of the code actually knowing what's there and/or possible.
It's such an important part of design and I think often we don't give it any prior thought or spec it in proposals.
So to combat that:
- Come up with some guidelines/conventions for naming and look to improve sections starting probably with the 2.1 push on plugins.
- Start promoting the ideas of outlining UI in proposals... yes often it changes but we can update and continue documenting and it does give us a chance to gather feedback from the designers well before we get entrenched in the code we are creating.
- Come up with a system of documenting the structure we develop! I don't really know where it would be best to organise this information? In the code as comments or CSS files, or within the docs? Either way somewhere where it can be reviewed and commented on.
As for theme maintainability, that's a whole other barrel of fish!
I think/hope using the general classes to create only the general look aids that, if the theme styles them liberally things should look OK in most cases.
Then making sure that the CSS for the base theme (or the plugins styles.css file) contains liberal CSS as well helps ensure that the general look is maintained.
As for canvas, it is already used everywhere, but it does extend base. So provided you don't try to do anything more than basic you shouldn't need to specifically add anything to canvas. It should be covering you with it's general styles.
But then, who is responsible for the 20 theme's that are/will be in core and making sure that they look right? The developer in me instantly says the theme designer/creator. Why, because I've seen the hideous mess developers who aren't designers can create! A couple of bad lines of CSS can cause a lot of chaos.
The designer in me argues that I have no clue what has changed, what the new structure is, and that there is no way to even know things have changed.
The reality is no one wants to, developers would need to skill up, designers don't really have support systems for it.
Of course once 2.0 comes out things won't change quite so often hopefully.
Anyway thats my thoughts on the matter.
Cheers
Sam
