At this point, I’m investing some time to improve my technical skill on (X)HTML, CSS, page layouts and different skins for applications mostly based on CSS.
Of course I’m not a designer, and probably never will be. But I know for sure, every developer must know “the minimum” at least, or we will be in the #yerdoinitwrong category.
Studding a few Rails applications and how they implement different css skins for the same page, I get shocked.
There is no guide line to follow, pattern to apply, base layout to use, and most important: no naming convention at all.
So, I have searched the web for all these items just to get even more chocked.
Why? The only thing people agree is to disagree. They don’t even agree if it is fair to use a reset css or not.
So, I need to start making my own decisions and establish some rules by myself.
Let me start by the reset css subject. I will not argue about that. There is a lot of discussions over the internet: people considering pros, other considering cons about using the reset css.
After reading most of the discussions, evaluated and tested all the “reset.css” files listed in this collection.
I took the decision to use a “reset.css” file. But the one I have chosen was the W3C proposal.
It is a bit longer if compared with others, but it considers the phrase “a default style sheet must show an HTML page content into a readable and useful way”, seriously.
If you want to make your own tests, I have created and published a basic HTML test page.
In my tests most of the available “reset.css” files (including the popular YUI), turns the HTML content into an unreadable and useless format. That is my reasoning about using the standard W3C reset option.
Next topic, the page layout and element names, in this topic we have a few statistics and agreement about.
You can see a few statistics naming conventions.
Words I think we should consider when naming are: meaning, brevity, clarity, semantic, generic (thanks to Nicole Sullivan).
So, taking my own site as an example:
The main area proposal:
Words like “wrapper” and “main” are not so clear in my opinion. Inside the body, we simply have our desired “page”, that is it.
In our page we have three main areas we can consider a practical standard. The popular: header, content and footer.
And finally each of these areas will be divided into sections:
The left, the center and the right sections, are nothing more then columns.
That points to the last topic: the oocss proposal, which can be used to put it all together.
You can find associated links from the oocss home, or go to the project itself.
And it is very easy to define and combine columns using the oocss Grids “sizeXofY” classes.
I am a fan of the oocss way; despite disagreeing on some points and need to change it a bit for my specific needs, most of my class names and current css style came from there.
OOCSS has some key points:
• use modular components
• be consistent
• use grids
• minimize use of css selectors
• use multiple classes per element to extend behaviour
• separate container and content
• new pages should not need new css
and key points to avoid
• avoid location dependent styles
• avoid styling by id
• avoid specifying the tag a class applies to
• avoid drop shadows and rounded corners over image backgrounds
According to Nicole Sullivan: “OOCSS isn’t really a framework … but a way of writing scalable, sane, maintainable CSS”.
You can have a First Look on Object Oriented CSS.
And a live sample (my own version) of OOCSS.
It is not even a final draft; it is a work in progress.
Any suggestions are welcome.