AWK as the syntactic basis of CSS?

Published 2011-04-29, by John

Ever notice how much CSS code looks like AWK code? No? Well, let me explain my thoughts on this.

Basically, CSS’ language follows a similar parsing pattern to AWK’s, with:

For your review… AWK’s basic language pattern is:

    <pattern>; { <actions> }

where is a UNIXy regular expression (regex), and are a sequence of C-style statements executed when the pattern is matched.

CSS’ basic language is:

    <pattern> { <style assignments> }

where <pattern> is CSS’ specific DOM node-selection schema, and <style assignments> are the limited assignment expressions I mentioned above (e.g. border: none) for the matched node.

One could then conceive that CSS’ basic language is syntactic-sugar (if AWK had with-statements) for:

    <pattern> { with $0 { <assignment expressions> } }

where $0 is AWK’s reference for the completely matched pattern, which I’m treating like an object or structured datatype here.

Interesting, no?

Personally I find this interesting because I’ve struggled to understand how Bos, Lie, and team settled on the syntactic structure (and semantic limitations) of CSS. CSS has a very different language pattern than either the markup it enhances ([X]HTML and even XML), or the scripting language with which it’s usually paired (javascript).

From AWK to CSS… to Javascript/CBS?

One of the questions I’ve been working on for some time is: could we use some of the structural markup best practices commonly used with CSS with javascript as well?

That is, could we find a bridge between the language structures of CSS and javascript so that we could tie behaviors to markup as easily as we do with presentation?

Why don’t we have cascading behavior sheets (CBS) like cascading style sheets (CSS), that follow a similar match-application idiom?

For instance, say I wanted to change the behavior of an anchor tag that’s being used as an action invoker, while keeping the markup meaningful:

    a.action {
                onclick: function() {
                /* do stuff, but don't activate
                   or follow the href on the anchor... */;
                /* ...stuff... */
                return false; }

By having a more AWKish behavior definition like CSS, we could also use syntax structures like AWK’s BEGIN, END, and global/anonymous action blocks to move behavior completely out of markup and have a more modular behavior definition. Plus javascript is an Algol-derived language like AWK, so one could argue that mashing it up with AWK is more appropriate than what CSS has done.

NOTE: Using CSS-style matching and application isn’t a new idea. There existed a javascript library called behaviour.js by Ben Nolan that did something just like this. However, it itself seems to have been obscure enough that not many used it, and it’s since become difficult to find (though its approach has been applied to more common javascript libraries like jQuery). It was a total-javascript solution, encapsulating its own CSS-style parser written in javascript (con: requiring ongoing maintenance and development), and requiring the usual javascript code triggering/loading instead of being able to have the browser load by reference as in CSS (con: with the usual concerns and complications with keying into window.onload).

So is there a chance of creating a new “standard” around behaviors like what we have for presentation? Why not start bringing some of these disparate language patterns (HTML/XML, CSS, javascript) together in some way?

There are already efforts to put behavior into an XML style (XML Events) but that doesn’t feel right to me. Using XPath as the CSS pattern-match language rather than CSS’ own seems like a better fit and improvement to me; although that won’t address larger conceptual variances. One could also argue that using XSL[T] instead of CSS would at least put presentation within the XML-consistency space; but XSL[T] is complex and overkill for most people and site purposes.

Wrapping up for now, there are many different directions this discussion can go. Improvements to CSS, following through on the CBS idea, … Let’s save those for subsequent discussions 🙂