The main thrust here is to develop a series of classes which do very common things and make them non-specific enough to be extended by another class. I looked through the designs and got an idea for what things were common and how they differed from section to section.
A pretty good example was that we had a few lists with background images, a header, some content text and a link. The header and link colours might change depending on what the list was, as might the size of the background images.
At this point, you need to make a judgement call on the level of granularity you need. Is there a need for separate colour styles and sizing? Obviously the more granular you go, the more class names you have to add to an element, which never feels bomb proof to me. In this case, I felt 2 classes would suffice.
I created a base background image list class, which set the most common properties I would need, such as no-repeat on the background, some padding and a margin. This class was given to all of the lists and then extended with another class that gave the list specific left padding, minimum height and heading colour.
Once those basics were done, I found I actually had quite a good tool set to create future interface objects without further css. Instead of the standard square border, 1 on top of the other list I already had, I could create a list of discrete lozenges by adding rounded corner and margin classes. These new interface objects all look correct, because the reflect the basic design elements of the page. Thus developers can create perfectly acceptable demo's and mock-ups without front-end intervention.
No comments:
Post a Comment