Stubbornella you have captivated me. I am now watching Nicole Sullivan‘s Object Oriented CSS talk for the second time. The OOCSS framework is a terse but ambitious thing in the tradition of YUI Grids CSS and Blueprint but with opinions that reach beyond grids, resets and typography.

While I have certainly not mastered the OOCSS concepts I do have some early observations I’d like to share nevertheless. This of course is dangerous territory since I risk having to eat my words later. So be it. Feel free to feed ’em to me as appropriate…

It strikes me from looking at the UML diagram for OOCSS that something is missing, or more accurately, some things are being conflated which shouldn’t be. If we’re thinking about objects and classes here the first question should be: what are we modeling? Well the semantic HTML folks might say we need to model things like paragraphs and headings, or at another level contacts and phone numbers, or at another level sidebars and navigation. These are all semantics.

When we think about modeling these things in HTML in such as way that CSS can be profitably applied, we use HTML element types to directly model semantics where we can (p element for paragraph, h1 element for top-level heading) and we use class attributes to express the rest (‘top-nav’, ‘address’, ‘phone’). If you have a look at the OOCSS UML diagram you will see in the “page layout” section a set of classes that fall into the former category ( ‘doc’, ‘hd’ for header, ‘bd’ for body, ‘ft’ for footer).

So far so good. But now how do we actually extend a class? The approach suggested in OOCSS is to change the (HTML) markup. One example from the talk is to specialize the media block class ‘media’ so that the fixed-size media is on the right instead of on the left. The suggestion is to define a new class ‘media_ext’ along with a new set of CSS rules. Then the idea is to change our HTML so that the element of interest carries two classes: ‘media’ and ‘media_ext’. And then we define some CSS for the new media_ext module, something like this:

.media_ext .fixedMedia { float:right }

This is the fundamental approach in OOCSS, so fundamental that it is on the short list of 10 Best Practices from slide 19 of the talk:

9. Extend objects by applying multiple classes to an element

The library defines a small set of base classes and a few core extensions to those. Users are invited to extend these further and we change our HTML to carry the full set of classes expressing semantics, layout and skinning too, all as separate classes.

The value in this approach is it certainly brings order to chaos. The downside is twofold: first we must pollute our HTML with layout and skinning choices and second, we must rely solely on coding conventions to ensure that each HTML element carries a self-consistent and complete set of classes.

aside: To me this feels much more akin to structured programming or maybe at best “abstract data types” than it does OO. I don’t really see language-level inheritance here, nor do I see polymorphism. But that’s just a terminological nit.

The first problem we need to solve is to get rid of the superfluous classes (on our elements). How could we make a media block (“fixed-width media object on the left with an open editable zone on the right”) into a right-handed media block without changing our HTML? Well the classic way in CSS is to use context to distinguish this situation. So let’s imagine that every odd media block ought to be right-handed. A classic approach is to have an ‘odd’ class on the element (or to use nth-child pseudo class). Perhaps something like this:

.media.odd .fixedMedia { float:right }

Where target is the fixed-width object we’d like to be on the right-hand side instead of the left. You get the idea. The problem with this approach is that we’ve just coded up some potentially reusable stuff (the {float:right} part) and we’ve got no way to reuse it in other circumstances. Also we are now guilty of committing pitfall #1 from the talk:

1. Location dependent styles

So you can see that we are definitely violating a key tennet of OOCSS. If you’re already an OOCSS dogmatist you may want to stop reading now. Still with me? OK, what if we want a right-hand media block for even rows next time? We’d have to edit that last CSS rule to look something like this:

.media.even .fixedMedia { float:right }

Yuck. What’s going on here? The problem is that CSS has no named/reusable/callable construct. No macro. No function. No Class. OOCSS does the best it can with plain old CSS by requiring us to define a new HTML class name. That lets us define a reusable set of CSS rules for it, but at the cost of polluting our HTML at each use.

I think a good way out of this is to break out of plain old CSS into a higher realm. Both SASS and CSS-SSC have a macro concept. SASS has its mixins and CSS-SSC has its base and based-on. What these actually add to CSS is named abstractions and reuse. So I could define a SASS mixin like this:

=right-hand-media
  .fixedMedia
    float: right

Now that is a reusable module. In my application I can apply that module to an element:

.media.odd
  +right-hand-media

Yay. Now I have the best of both worlds. If we have another app that wants even media items to be right-handed then we just define this:

.media.even
  +right-hand-media

The value of this is that I didn’t have to change my HTML markup in order to change the layout. There are examples of using the same approach to define a clearfix module. To those who say this approach is going to generate a lot of CSS I say, “well maybe, but I think our first priority needs to be making our source code manageable and this approach may just help us do that.”

As I already pointed out, this proposal (using SASS mix-ins or CSS-SSC macros to implement reusable modules, and then using contextual CSS Rules to apply those modules) violates a core principle of OOCSS. On the upside it solves one of the wish list items from the talk (on slide 60):

1. Extending objects—possible to make “sale module” inherit from “module”

.module{}
.saleModule{extends: module}

Now that approach is a bit different from the one I described for right-hand-media. But it is clear that mix-ins or macros could easily be used to reuse .module in .saleModule right? SASS mix-ins, for instance can be used (as in my first example) as straight-up mix-ins, or to implement inheritance. The choice is yours.

To close, I highly recommend watching the Stubbornella’s presentation. Twice. There is just a ton of gold in there. Meanwhile, I’ll go experiment with SASS mix-ins and let you know how it works in practice and how it can be combined with some of the other principles highlighted in the talk.

Crockford takes us through a brief history of computing reminding us, as we’ve been reminded before, that the Web interaction model is practically the same as the mainframe 3270 interaction model circa 1972.

The most potent moment in the talk however, is when he shows a shot of a mermaid rendered via a run of the mill nvidia subsystem and dryly points out “look, rounded corners”. The upshot: the 1984 Macintosh had rounded corners — browsers were obsolete from the git go and there is a huge and widening gap between what you do in a web app and what you do in a non-web one.

Oh and I’m making Crockford my Personal Hero of the Month for pointing out that not only are our web technologies based on eight-year-old standards (HTML 4.0.1, ECMAscript ed. 3, CSS 3) started in ’98 and still under development but that of those, CSS is the worst of the lot and should be replaced with urgent haste. Refreshing respite from the usual CSS love.

“Don’t take any crap.”

update: watch this space for my growing list of web standards revolutionaries:

    1 page.insert_html :bottom, page.literal( "$$( '#contact_#{@contact.id} .email-category ul').first" ), :partial => 'show', :locals => { :show => @email_address}

In Fight id Proliferation I highlighted the prevalent misunderstanding of the prototype API’s insert_html, replace_html and friends that is evident both in the Prototype documentation and in Rails. Due to that misunderstanding, many of us are polluting our HTML with many more id attributes than would otherwise be necessary. In the original post I proposed a fix to Rails to remedy the situation and allow us to use CSS selectors to identify a target HTML element for the various calls. In this post I provide a workaround you can use now, while waiting for a cleaner fix.

Previously, I pointed out that we’d really like to use page.select and more generally, any expression that produces an element, as e.g. the second parameter to page.insert_html.  So it would be really nice if this worked:

    1 page.insert_html :bottom, page.select( "#contact_#{@contact.id} .email-category ul").first, :partial => 'show', :locals => { :show => @email_address}

If that worked, we wouldn’t need an id on each element representing the email address for a contact.  Instead we’d just put an id on the contact (at the outer level) and we’d tag the parts of the contact (email address, phone number, etc) with appropriate classes. Much more microformatty.

Well, as you know, you can’t do that just now in Rails. But there is a workaround.  It’s a bit ugly but it works. And the ugliness is in the RJS, not in the HTML. So your markup is smaller and cleaner, even if you’re generating an extra line of JavaScript.

The workaround is to use the each method on the result of calling page.select. This lets you iterate (in the browser) over the elements returned from evaluating the CSS selector. Within that iteration, you have available the element of interest. Now that you’ve got an element, you can call the various page methods that require an element or id such as page.insert position, element. You can also call methods directly on the element itself such as element.reset. Here’s the previous example recast in this way:

    1               page.select( "#contact_#{@contact.id} .email-category ul").each do |element|
    2                 page.insert_html :bottom, element, :partial => 'show', :locals => { :show => @email_address}
    3               end

This works great in Rails 1.2 even if it is a little bit ugly. By ugly I mean that the code doesn’t exactly express what we want. Notice that the original code was selecting the first element matched by the CSS selector whereas the workaround code is iterating over all elements matched. So long as you’re careful to construct CSS selectors that match exactly the number of elements you’re really after though, you should be ok.

Here’s a similar snippet but this one calls the Prototype reset method on the element:

    1               page.select( "#contact_#{@contact.id} .email-category form").each do |element|
    2                 element.reset
    3               end

By tagging only top-level elements with id’s and using classes to tag internal components you end up with cleaner HTML. This is valuable anywhere you present a list of complex, editable objects. For example, here is one contact of many displayed in a list:

Each contact has a set of email addresses, blog URL’s and phone numbers. We don’t want to have to assign id’s to every single phone number, blog URL and email address on the page. Instead we assign id’s only to the top-level elements. Here is a contact list with contact_19 expanded. Under contact-details we’ve got email addresses under an element with classes contact-category and email-category. That element contains both the unordered list of email addresses and a form to add new ones:

    1 <ul class="contacts-list editable">
    2     <li id="contact_25" class="contact-summary">
    3     </li>
    4     <li id="contact_19" class="contact-summary">
    5         <div class="name">support@thought-propulsion.com</div>
    6         <div class="contact-details" style="">
    7             <div class="contact-category email-category">
    8                 <h2>Email Addresses</h2>
    9                 <ul>
   10                     <li>support@thought-propulsion.com</li>
   11                 </ul>
   12             </div>
   13             <div class="contact-category blog-category">
   14             </div>
   15             <div class="contact-category phone-category">
   16             </div>
   17         </div>
   18     </li>
   19     <li id="contact_22" class="contact-summary">
   20     </li>
   21 </ul>

So if you want to use Simply Helpful to generate your top-level id’s have at it, but you needn’t use it to generate id’s for all the internal parts just because of a little misunderstanding :)

What is a little surprising is the page’s departure from the common practice of using anchor tags within the list items. Instead of each list item containing a hyperlink, it contains plain old text. Since there is no hyperlink, the browser won’t provide a visual cue that the item is navigable/clickable. That’s kind of ok since most designers go to pains to undo some of the cue anyway — I’m talking about eliminating underlining. The other cue — changing the cursor to the pointer image when mousing over the “active” list item, is implemented via a CSS rule. Then all that’s left is to catch the click events in JavaScript code.  Here’s the markup:

It’s a pretty design and it works really nice. On the other hand it is not an example of “unobtrusive JavaScript” or of “graceful degradation”. I am pointing this out not to be dogmatic about these things, rather to cite it as evidence of the difficulty of applying the aforementioned philosophies.  Here you have a lovely page, built by the best designers money can buy. It doesn’t get much more high profile than this. And these guys went ahead and built a page that requires JavaScript. Made me think. I hope it makes you think too.

This feels like it’s going to be a bit of a recurring theme here (see the recent Tableful Grace post). Graceful degradation with respect to JavaScript, CSS, heck even background images; separation of behavior from content; table-less layout — these are great philosophies. But the practice is riddled with subtlety and compromise. And you wouldn’t really know it from reading the short “gee look what I can do” type articles.

I’m curious to know how you feel about these new sacred cows now that we’ve had a little experience with them. For example, are you implementing whole applications with graceful degradation or only pieces of your application? If it’s the latter, are you getting any real benefit? Does graceful degradation double your testing effort?

So what’s my first thought when encountering such a site (well maybe my second thought — right after “can I preorder my copy of Harry Potter #7“)? Why it’s: “let’s see what Firebug can tell us about the site’s construction” of course! Here’s what I found interesting in about three minutes:

1. the site pretty much uses table-less layout — yippee! divs and floats my friends
2. elastic layout
3. font resizing works pretty well in content areas but not in navigation controls

Something I’m particularly interested in these days is that old chestnut of web design: the rounded corner. The approach on the Powells site was so, well, heinous, that it prompted me to inaugurate what I hope will become a regular feature here. Without further ado, I give you:

Heinous Corner-Rounding of the Day Award (HCROD) #1: Powells Books (div per image)

Got some content you’d like to render in a rounded box? Well then, simply wrap it in six divs — one each for: right, bottom, and each of the corners. That way you can hang CSS rules on each of those divs to apply your rounded/shadowed images. Semantic HTML my foot. Dig: