I released a BRS Lab named CuttySSark some months ago. It operated under an experimental idea that fundamentally changes how a front-end developer could approach interaction design. The library generated some buzz on Twitter when Chris Coyier of CSS-Tricks.com tweeted about it favorably. Amongst a humbling number of appreciative tweets, re-tweets, pre-tweets, and un-tweets, there they were, gorgeous as ever: the haters. Now, I can deal with haters — in fact, I really love them for the sake of provoking thoughtful conversation.

Twitter isn’t a great place for thoughtful conversation, so here I am on the “Internet,” responding to tweets in web log format (a silly thing, but alas). See y’all in the comments! Dukes up (just kidding).

For those of you who are curious to know: the purpose of CuttySSark is to augment CSS by exposing to it user interaction, similarly to the useful and stateful CSS1/2 :hover, :active, and :focus pseudo-selectors. The JavaScript event model is the vehicle for this, but nothing more than that. You can mess things up with CuttySSark. However, you can also turn your front-end developer life into butter. We hope native user interaction design may follow a similar, but improved model in the future. For now, this is what I have.

Let me back up a tad bit to explain the idea behind CuttySSark, and why I believe it scares some people, including several of my co-workers. CuttySSark allows one to write CSS that interacts directly with the JavaScript event model. Here’s a simple example:

#big[on~="click|toggle"] #little {
  background: transparent;

Cutty reads my stylesheet and finds this rule that causes the background transparency on #little to toggle when #big is clicked. Cutty is responsible for setting up JS events so that the CSS2-compliant selector written in the stylesheet, #big[on~="click|toggle"] #little, is actually matched at the correct time.

The crucial distinction here: The CSS you write is directly responsible for the style changes, as opposed to JavaScript manipulating styles via the DOM style object.

This approach has the same benefit as class-swapping via JS. I expect we can all agree that it’s useful for styles to live solely in stylesheets and not in JS.

Ah, you’ve got me! I don’t want styles to live in JS, but I do want JS-driven events to live in CSS. In all earnestness, yes! Well, I don’t want all events to live in CSS, but I do want the ones related to style-specific changes. I just want my stylesheets to reflect the statefulness of the styles described. It works wonderfully for :hover, :focus, and :active, does it not? I’ve never heard anyone complain about them, and nobody should! They are incredibly convenient because I can simultaneously understand both what style will appear, and also when and where it will appear. Class-swapping via JS obfuscates that very action.

Well, interaction design has pushed beyond these “dynamic/interactive” pseudo-selectors: two simple examples of revolutions in interaction being HTML5’s draggable and CSS3’s animations, both of which are backed by a suite of JS-driven events. CuttySSark is a polyfill bringing CSS2’s stateful-mindedness into the present.

I do agree that there is one idea floating around with CuttySSark that has not been properly addressed. It’s possible that on the Labs demo page I stressed the usage of “event”-driven styles too much. Here I’m stressing the usage of “stateful” style, and events are not states — they’re typically transitions into states. For example, the Cutty selector [on~=mouseover] would match the moment the cursor moves on top of an element, but it would still match when the cursor leaves the element. Thus, it’s matching a relatively meaningless state of the element of “having been moused-over.” That’s why I implemented the state, clear, toggle, and once options within Cutty.

These options allow us to implement well-defined states using events as transitions. I’m thinking a little state-machiney right now. Even though the events represent the transitions (denoted by --> in a moment), CuttySSark’s options do support the idea of actual statefulness:

  • once implements the states of “on” and “off” in the machine [off]-->[on]
  • toggle implements the states of “on”, “off”, and “default” in several machines, one of which being [default]-->[on]<==>[off]
  • clear allows for a sort of “return to statefulness” by reverting non-stateful style blocks.
  • state implements statefulness by forcing elements to assume exactly one stated style block at a time.

I genuinely had this in mind! It’s easy to deviate from it, and I understand that you can shoot yourself in the foot by allowing an element to have too many disparate Cutty-induced styles applied to it at once. Of course, any flexible system can be used for evil.

Hmm…I sense an elephant in the room. There is a somewhat ugly corner of Cutty that won’t need to be used most of the time: the support of a rather ugly syntax that allows an event on one set of elements to trigger a different event on another set of elements. It looks like this:

selector1[on~="event1|trigger|event2(selector2)"] {

That actually reads somewhat reasonably (“for elements in selector1, on event1 trigger event2 on elements in selector2”), but I concede it’s an abuse of CSS because it’s a meaningless style block that interacts directly with the event model, and not with any styles.

That said, it can be incredibly useful for simple UI elements. I was thinking about all the different UI elements that could be created simply by manipulating styles without reference to any sort of programming logic once a user’s interaction with the DOM were exposed to CSS.

The last step in exposing user interaction to CSS was to allow interaction with one element to affect the state/styles of a separate, non-child element. Thus, that’s precisely why this feature exists. Again, the purpose here is not to mindlessly force a random piece of JS into CSS, and of course I do not support extending JS functionality into CSS. Rather, my purpose is to expose user interaction to CSS beyond CuttySSark’s grandparents, :focus and :hover. JS is merely the vehicle for that.

The bottom line here is that CuttySSark is a simple tool loaded with implications. I like to think with Cutty we’re one step closer to a non-Frankensteined incarnation of CSS, which has kept up with user interaction beyond mousing over and out.

Cutty Shark
Cutty Shark!

Share this post

Hire Us

We’d love to work with you. Head over to the contact page and say hello today!