Forum Moderators: not2easy
I recently watched Nicole Sullivan's presentation on Object Oriented CSS [developer.yahoo.net]. Intrigued by the title I have since searched more to find out the buzz.
The idea as far as I can tell is to add to the HTML in order to keep the stylesheet clean, readable and reusable. i.e.
You build basic "blocks" or I presume that's what is meant by "Object" (for the record, I don't like the term Object Oriented as applied to CSS and I just know it will upset a lot of the real OOP Language users around here.. so I'll stick to blocks ;))
Inside your grid/template/layout structure you have requirement to use many blocks, these blocks may be part of the site design, like sidebar lists, or they might be pulled in by a plugin or module, facebook, twitter feeds etc. some of them may not even be known at the outset.
The idea is that you wrap all these blocks in an element e.g. div and give that div a classname of "block". In the CSS the basic structure of all blocks is set on this classname, e.g. font, heading, background, borders, but NO widths or heights, the basic block should fill the space allowed for it in whatever region of the page it's in.
e.g.
<div class="block">
<p>content<p>
</div>.block {
color: #000;
border: 1px solid #eee;
background: #eee url(mydefault.png) 0% 0%;
}
and then if you want to extend the basic block code e.g. to add red borders to a particular module's block, instead of the default grey, you go into the HTML and add another class name into the attributes for the block then use the extra class to extend the basic block module
e.g.
<div class="block notice"><p>content</p></div>.block {
color: #000;
border: 1px solid #eee;
background: #eee url(mydefault.png) 0% 0%;
}.block.notice {
border: 1px solid #f00;
}
So now I have questions & I'm really not sure I get "it"
My example is obviously very basic, and there's more buzz out there in blogosphere, do root around if you've time and share your take on it all.. I'd love to hear your thoughts
Block has the problem of pushing us back into table if you don't watch out.
I feel the technique is very risky to cause even more divitis and classitis than we already have out there.
Multiple classes: we're ruling out IE6 support! (Which has a good side, but not every webmaster is ready for that)
But I fully agree we under-use the power of CSS in many - if not the vast majority of examples I see out here.
For large sites that need to grow over time we indeed have a few challenges like said in the intro.
But I'm not yet convinced going this far with it is a solution (and it won't help you to only have to work around the IE bugs and features).
Finding the generic stuff for a site is hard.
Many of the examples she uses in her presentation like rounded corners are fixed in modern browsers (discounting IE, guess it's not modern anyway) and CSS3.
My idea:
- Build it modular, taking into account growth etc: absolutely!
- Use CSS3 where possible to help you, and well old browsers get some fallback (like square corners).
- Focus on this OO thing: I'm not sure.
It might be needed to get to this is you have a large team working on a single site. As you need better and more flexible agreements between teams/team members.
[edit]grammar[/edit]
[edited by: swa66 at 3:28 am (utc) on Nov. 26, 2009]
re: lack of support for chained classes, sorry I could've done it without the chaining - you can of course simply use the second class without chaining them as long as the second one appears after the first in the cascade. Nicole actually adds to her wishlist that she would like it if the nearest class (to the element content) IN THE HTML could trump the first one no matter the order of the Cascade (i.e. allow it to disregard specificity), and this was one of the parts which got me to think that this method is a bit like trying to re-invent the wheel. The Cascade and inheritance already exists and works (in a separate layer) so why the request to change it to bring responsibility back to the markup layer?
I think the "large team" benefit is probably the best use of a framework like this, but it is then nothing more than said team leaders writing best practices to apply to their own internal development strategies? It's easy for the larger organisations to put things like this forward, they probably already have the fastest servers on earth, but CSS will get a bad time again if practices like this actually slow sites down.
I too fear it will confuse beginners and encourage divitis and classitis. The entire theory behind it all could possibly produce smaller stylesheets but more of them (per module) so instead this would then be a bigger hit on the # of HTTP requests speed "rule" which is infinitely more important than the # bytes in a CSS file when it comes to the Page Loading Speed, for most sites anyway
I'm not averse to adding some useful hooks to the HTML, because the trade off between slightly more HTML to enable reusable CSS is probably worth it even if it has no particular advantage/disadvantage over performance either way.
WP & Drupal generated code already adds lots of classes by default to enable a standard for the coding practice of their Modules/Plugins/Widgets. They do this to enable themes/skins to be created that are already modular. This works fine in theory but most large sites I'm aware of that use Drupal have developed their own CSS in order to get rid of/streamline the extra bits as the multiple sheets and scripts that come as default does slow down average sites.
Interesting presentation though, I see the benefit to modularisation of some page components, especially ones that do not appear on all pages, (and you have a way to only call the extra sheets on pages that are required) however I still think that for many just a well thought out identified structure enables the same, and that this all encompassing framework [github.com] idea is overkill for many webmasters.
