Category: Web Standards

My 2009 essay kinda-sorta about an Anarchist “Internet of Things”

I wrote an essay in 2009 about the Internet of Things, before people were calling it “the Internet of Things.” When I re-read it this afternoon, in 2017, I noticed something rather queer. It wasn’t actually about the Internet of Things at all. It was actually a personal manifesto advocating Anarchism, and condemning techno-capitalist fascism.

Yes, really.

In 2009, despite having barely turned 25 years old, I had already been working as a professional web developer for a little over a decade. (That arithmetic is correct, I assure you.) At the time, I had some embarrassingly naïve ideas about Silicon Valley, capitalism, and neoliberalism. I also had no idea that less than two years later, I’d be homeless and sleeping in Occupy encampments, and that I’d remain (mostly) happily houseless and jobless for the next six years, up to and including the time of this writing.

The story of my life during those two years is a story worth telling…someday. Today, though, I want to remind myself of who I was before. I was a different person when 2009 began in some very important ways. I was so different that by the time it ended I began referring to my prior experiences as “my past life,” and I’ve used the same turn of phrase ever since. But I was also not so different that, looking back on myself with older eyes, I can clearly see the seeds of my anti-capitalist convictions had already begun to germinate and root themselves somewhere inside me.

Among the many other things that I was in my past life, I was an author. I’ve always loved the art of the written word. My affinity for the creativity I saw in and the pleasure I derived from written scripts drew me to my appreciation for computer programming. That is its own story, as well, but the climax of that trajectory—at least by 2009—is that I was employed as a technical writer. I blogged on a freelance basis for an online Web development magazine about Web development. I had already co-authored and published significant portions of my first technical book. And, in 2009, I had just completed co-authoring a second.

That second book was called, plainly enough, Advanced CSS, and was about the front-end Web development topic more formally known as Cascading Style Sheets. But that’s not interesting. At least, no more interesting than any other fleeting excitement over a given technical detail. What’s arguably most revealing about that book is the essay I contributed, which for all intents and purposes is the book’s opening.

My essay follows in its entirety:

User agents: our eyes and ears in cyberspace

A user agent is nothing more than some entity that acts on behalf of users themselves.1 What this means is that it’s important to understand these users as well as their user agents. User agents are the tools we use to interact with the wealth of possibilities that exists on the Internet. They are like extensions of ourselves. Indeed, they are (increasingly literally) our eyes and ears in cyberspace.

Understanding users and their agents

Web developers are already familiar with many common user agents: web browsers! We’re even notorious for sometimes bemoaning the sheer number of them that already exist. Maybe we need to reexamine why we do that.

There are many different kinds of users out there, each with potentially radically different needs. Therefore, to understand why there are so many user agents in existence we need to understand what the needs of all these different users are. This isn’t merely a theoretical exercise, either. The fact is that figuring out a user’s needs helps us to present our content to that user in the best possible way.

Presenting content to users and, by extension, their user agents appropriately goes beyond the typical accessibility argument that asserts the importance of making your content available to everyone (though we’ll certainly be making that argument, too). The principles behind understanding a user’s needs are much more important than that.

You’ll recall that the Web poses two fundamental challenges. One challenge is that any given piece of content, a single document, needs to be presented in multiple ways. This is the problem that CSS was designed to solve. The other challenge is the inverse: many different kinds of content need to be made available, each kind requiring a similar presentation. This is what XML (and its own accompanying “style sheet” language, XSLT) was designed to solve. Therefore, combining the powerful capabilities of CSS and XML is the path we should take to understanding, technically, how to solve this problem and present content to users and their user agents.

Since a specific user agent is just a tool for a specific user, the form the user agent takes depends on what the needs of the user are. In formal use case semantics, these users are called actors, and we can describe their needs by determining the steps they must take to accomplish some goal. Similarly, in each use case, a certain tool or tools used to accomplish these goals defines what the user agent is in that particular scenario.2

A simple example of this is that when Joe goes online to read the latest technology news from Slashdot, he uses a web browser to do this. Joe (our actor) is the user, his web browser (whichever one he chooses to use) is the user agent, and reading the latest technology news is the goal. That’s a very traditional interaction, and in such a scenario we can make some pretty safe assumptions about how Joe, being a human and all, reads news.

Now let’s envision a more outlandish scenario to challenge our understanding of the principle. Joe needs to go shopping to refill his refrigerator and he prefers to buy the items he needs with the least amount of required driving due to rising gas prices. This is why he owns the (fictional) Frigerator2000, a network-capable refrigerator that keeps tabs on the inventory levels of nearby grocery stores and supermarkets and helps Joe plan his route. This helps him avoid driving to a store where he won’t be able to purchase the items he needs.

If this sounds too much like science fiction to you, think again. This is a different application of the same principle used by feed readers, only instead of aggregating news articles from web sites we’re aggregating inventory levels from grocery stores. All that would be required to make this a reality is an XML format for describing a store’s inventory levels, a bit of embedded software, a network interface card on a refrigerator, and some tech-savvy grocery stores to publish such content on the Internet.

In this scenario, however, our user agent is radically different from the traditional web browser. It’s a refrigerator! Of course, there aren’t (yet) any such user agents out crawling the Web today, but there are a lot of user agents that aren’t web browsers doing exactly that.

Search engines like Google, Yahoo!, and are probably the most famous examples of users that aren’t people. These companies all have automated programs, called spiders, which “crawl” the Web indexing all the content they can find. Unlike humans and very much like our hypothetical refrigerator-based user agent, these spiders can’t look at content with their eyes or listen to audio with their ears, so their needs are very different from someone like Joe’s.

There are still other systems of various sorts that exist to let us interact with web sites and these, too, can be considered user agents. For example, many web sites provide an API that exposes some functionality as web services. Microsoft Word 2008 is an example of a desktop application that you can use to create blog posts in blogging software such as WordPress and MovableType because both of these blogging tools support the MetaWeblog API, an XML-RPC3 specification. In this case, Microsoft Word can be considered a user agent.

As mentioned earlier, the many incarnations of news readers that exist are another form of user agent. Many web browsers and email applications, such as Mozilla Thunderbird and Apple Mail, do this, too.4 Feed readers provide a particularly interesting way to examine the concept of user agents because there are many popular feed reading web sites today, such as and Google Reader. If Joe opens his web browser and logs into his account at Bloglines, then Joe’s web browser is the user agent and Joe is the user. However, when Joe reads the news feeds he’s subscribed to in Bloglines, the Bloglines server goes to fetch the RSS- or Atom-formatted feed from the sourced site. What this means is that from the point of view of the sourced site, is the user, and the Bloglines server process is the user agent.

Coming to this realization means that, as developers, we can understand user agents as an abstraction for a particular actor’s goals as well as their capabilities. This is, of course, an intentionally vague definition because it’s technically impossible for you, as the developer, to predict the features or capabilities present in any particular user agent. This is a challenge we’ll be talking about a lot in the remainder of this book because it is one of the defining characteristics of the Web as a publishing medium.

Rather than this lack of clairvoyance being a problem, however, the constraint of not knowing who or what will be accessing our published content is actually a good thing. It turns out that well-designed markup is also markup that is blissfully ignorant of its user, because it is solely focused on describing itself. You might even call it narcissistic.

Why giving the user control is not giving up

Talking about self-describing markup is just another way of talking about semantic markup. In this paradigm, the content in the fetched document is strictly segregated from its ultimate presentation. Nevertheless, the content must eventually be presented to the user somehow. If information for how to do this isn’t provided by the markup, then where is it, and who decides what it is?

At first you’ll no doubt be tempted to say that this information is in the document’s style sheet and that it is the document’s developer who decides what that is. As you’ll examine in detail in the next chapter, this answer is only mostly correct. In every case, it is ultimately the user agent that determines what styles (in which style sheets) get applied to the markup it fetches. Furthermore, many user agents (especially modern web browsers) allow the users themselves to further modify the style rules that get applied to content. In the end, you can only influence—not control—the final presentation.

Though surprising to some, this model actually makes perfect sense. Allowing the users ultimate control of the content’s presentation helps to ensure that you meet every possible need of each user. By using CSS, content authors, publishers, and developers—that is, you—can provide author style sheets that easily accommodate, say, 80 percent of the needs of 90 percent of the users. Even in the most optimistic scenario, edge cases that you may not ever be aware of will still escape you no matter how hard you try to accommodate everyone’s every need.5 Moreover, even if you had those kinds of unlimited resources, you may not know how best to improve the situation for that user. Given this, who better to determine the presentation of a given XML document that needs to be presented in some very specific way than the users with that very specific need themselves?

A common real-life example of this situation might occur if Joe were colorblind. If he were and he wanted to visit some news site where the links in the article pullouts were too similar a color to the pullout’s background, he might not realize that those elements are actually links. Thankfully, because Joe’s browser allows him to set up a web site with his own user style sheet, he can change the color of these links to something that he can see more easily. If CSS were not designed with this in mind, it would be impossible for Joe to personalize the presentation of this news site so that it would be optimal for him.

To many designers coming from traditional industries such as print design, the fact that users can change the presentation of their content is an alarming concept. Nevertheless, this isn’t just the way the Web was made to work; this is the only way it could have worked. Philosophically, the Web is a technology that puts control into the hands of users. Therefore, our charge as web designers is to judge different people’s needs to be of equal importance, and we can’t do this if we treat every user exactly the same way.6

  1. This is purposefully a broad definition because we’re not just talking about web pages here, but rather all kinds of technology. The principles are universal. There are, however, more exacting definitions available. For instance, the W3C begins the HTML 4 specification with some formal definitions, including what a “user agent” is. See []
  2. In real use cases, technical jargon and specific tools like a web browser are omitted because such use cases are used to define a system’s requirements, not its implementation. Nevertheless, the notion of an actor and an actor’s goals are helpful in understanding the mysterious “user” and this user’s software. []
  3. XML-RPC is a term referring to the use of XML files describing method calls and data transmitted over HTTP, typically used by automated systems. It is thus a great example of a technology that takes advantage of XML’s data serialization capabilities, and is often thought of as a precursor to today’s Ajax techniques. []
  4. It was in fact the much older email technology from which the term user agent originated; an email client program is more technically called a mail user agent (MUA). []
  5. As it happens, this is the same argument open source software proponents make about why such open source software often succeeds in meeting the needs of more users than closed source, proprietary systems controlled solely by a single company with (by definition) relatively limited resources. []
  6. This philosophy is embodied in the formal study of ethics, which is a compelling topic for us as CSS developers, considering the vastness of the implications we describe here. []

Introducing “Subresource Integrity (SRI) Manager” for WordPress

Subresource Integrity (SRI) is a proposed W3C standard that Web developers can make use of to protect their websites from being used in JavaScript-based DDoS attacks, such as the one recently suffered by It’s not yet widely supported by browsers but is harmless to add to your pages for browsers that don’t support it.

Using SRI declarations is a simple matter of adding an integrity attribute to the HTML tag that points to an external resource (like a <script> tag) that contains a hash specifier (like sha256) and the proper hash of the content you expect to load. This indicates to the browser that the resource to which the element points should have the given hash. If the content that the browser receives from the remote server does not produce the specified hash, the browser ignores (refuses to load) the resource, and fires an error event at the element, instead:

<script src="//" integrity="sha256-ab3c54ef..998756"></script>

I wanted to make use of this immediately, but I didn’t want to manually hash all the libraries that my website calls to. These include stylesheets from content distribution networks like Bootstrap and JavaScript libraries such as jQuery DataTables. So I wrote a WordPress plugin that keeps track of the hashes for me.

With the Subresource Integrity (SRI) Manager plugin for WordPress (WP-SRI), each time a stylesheet or JavaScript is enqueued by a WordPress plugin or theme (using wp_enqueue_style() or wp_enqueue_script()), WP-SRI makes a note of the requested resource URL and adds it to a list of known resources. If WP-SRI has not seen the resource before, it grabs the resource content itself, produces a hash, and saves that alongside the resource URL in WordPress’s wp_options table. When HTML is printed to the screen, it adds the integrity attribute and the associated hash automatically.

Using this plugin can dramatically reduce the likelihood that visitors to your site will be strong-armed into participating in an HTTP DDoS attack. In future versions of this plugin, I also hope to provide an easy-to-use interface for site administrators so that they can maintain a customized list of resource hashes, and to trigger on-demand integrity checks of these resources.

Please submit feature requests and/or patches to the issue tracker on GitHub, and post support requests to the WordPress plugin support forum. Thanks. :)

My SVG is Bigger than Your Flash – Presentation Notes

A few weeks ago, right before the Christmas holidays, I gave a brief internal presentation about SVG, an XML-based web standard for interactive images, to my coworkers. Since I was told that the presentation was helpful, I thought I’d share my notes. Those notes follow:


First, credit where credit is due.

I learned almost everything I know about SVG from an acquaintance I met in Australia named Dmitry Baranovskiy. He is a superb client-side web developer who I helped add documentation for a brief time for one of his SVG-related projects called RaphaëlJS. I’ll show you that in a little bit.

Okay, so what is SVG?

What is SVG?

In a sentence, according to Adobe, the originators of the technology:

Scalable Vector Graphics (SVG) is a text-based graphics language that describes images with vector shapes, text, and embedded raster graphics.

What does that mean?

But wait, there’s ”more”.

Why use SVG?

  • It’s text-based, which means it’s highly searchable. Remember SEO in the heyday of the “Flash website”? Now Flash has all kinds of meta attributes to provide extra SEO oomph, but if we had just used SVG in the first place, we wouldn’t have had this problem.
  • Mobile support: SVG comes in a few flavors that are all interoperable with each other in order to define different levels of support. Whereas Flash is monolithic, SVG comes in profiles that support low-end devices with reasonable quality while still providing high-fidelity content. Just like the Web was designed to do.
  • Easy to learn: there isn’t much new here because it uses everything you already know about XML, CSS, and JavaScript to provide every feature it has. That’s right, you can use plain old HTML for your page content, add some CSS to style it and the SVG, and then JavaScript to script it. “The trifecta” just added another dimension.
  • And, if you care about such things, SVG has been an open standard well before Flash was.

Browser support

  • Opera has full support and has had some amount of support since Opera 8.
  • Gecko has had increasing support since 2005.
  • WebKit has had increasing support since 2006.
  • Internet Explorer (still) has no native support. We hate you, Internet Explorer. (That said, however, Microsoft has just recently joined the W3C’s SVG Working group, so there may yet be some hope.)

What can we do about IE today?

Here is the breakdown of options we have to deal with IE’s frustrating lack of support.

  • Rely on HTTP content negotiation to serve SVG to supporting browsers, and raster images to Internet Explorer. Works great, except now we’re still using raster images, so basically it feels like 1995 again. It’s also what Wikipedia does.
  • Use plugins. Adobe has had one forever called the Adobe SVG Viewer. It’s pretty good…but it’s a plugin. I’m not sure how Flash got away with also being a plugin, but whatever.
  • Relent and use Flash on the client-side, but revel in delicious SVG pureness for our source files: Using SVG Path Data in Flash.
  • Use a cross-browser API. Turns out, there are quite a few:
    • SVG in The Dojo Toolkit – Early and solid, but it uses Dojo (and we don’t).
    • svgweb – Google’s experimental library. It’s got the biggest hyperight now.
    • RaphaëlJS, written by my acquaintance Dmitry Baranovskiy and, of course, my favorite cross-browser SVG toolkit. Since it’s stand-alone, you can actually mix-and-match with your favorite JavaScript framework. In other words, you take your pick of jQuery, YUI, Prototype, or whatever, and layer RaphaëlJS on top for all your SVG-related work. Now that’s creamy.

How do SVG-writing JS frameworks work?

  1. Provides a cross-browser JavaScript API (think jQuery) for writing SVG commands.
  2. Writes to the DOM based on your Raphaël commands:
    • Writes SVG to supporting browsers.
    • Writes VML1 to Internet Explorer.
  3. Makes you coffee.

Hype it up

1 Minute Intro to (Google’s) SVG Web + Demos + rock and roll (because why not?)

Sources and additional resources

  1. VML is Microsoft’s proprietary, non-standard Vector Markup Language. It’s basically the exact same thing as SVG, but only works in Internet Explorer. Because whereas Apple only thinks differently, Microsoft has to do it differently. We hate you, Microsoft. []

Why CSS needs delegation capabilities and not “variables”

It’s been too long since I joined the fun, if amazingly heated, debates over the direction that Web standards are moving in. Recently, given the “free” time to do so, I decided to dive head first into what is (sadly) an almost 14 year old debate. The result is this blog post, which is mostly a response to Bert Bos’s essay Why “variables” in CSS are harmful and Matt Wilcox’s opposing response to that essay, Why CSS needs to borrow from programming languages. Their articles are each worthy of a read, possibly before this one.

Here’s the summary of my argument.

Adding many “programmatic” features to the CSS language such as variables, macros, or flow control is a mistake. However, CSS’s failure to simply encode visual relationships (instead of merely typographic properties)—a severe deficiency in the core language itself—requires the addition of delegation features. With the additional capability to reference an arbitrary element’s computed value regardless of its hierarchical context, CSS will be more accessible to both amateur and professional web designers, more capable, and will more forcefully promote the semantic Web and its ideals.

In this corner: CSS variables are harmful

Bert does a great job of summarizing the conclusion of his argument himself. In his essay, Bert says:

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

As we all know, one of the wonderful things about CSS is that the core language itself is remarkably simple. (What’s not simple is the spectacular way browser manufacturers have destroyed everyone’s hope that implementing CSS-based designs in the real world will ever be easy, but that’s a whole different can of worms.) Fundamentally, CSS’s syntax can be explained with a mere three major components: property/value pairs, declaration blocks, and rule sets.

What this means is that CSS as a language is stupidly easy to learn. I think everyone would agree that it’s certainly easier to learn than, say, JavaScript or XSL. Now, that’s important because, without putting too fine a point on it, Bert mentions multiple times that CSS’s “intended audience” are the diverse and likely relatively technically ignorant content authors that are responsible for the overwhelming majority of web pages on the public Internet today.

He makes the very good point that The value of the semantic Web isn’t defined by how well structured the best documents are, but by how well structured the vast majority of documents are. In other words, CSS needs to remain instantly useable and reusable to these untrained, amateur web content publishers for the benefits of self-describing documents (i.e., the semantic Web) to see mass adoption.

To wit:

reusing other people’s style sheets is more difficult if those style sheets contain user-defined names. Class names are an example. Their names may suggest why the author created them (assuming they are in a language you understand), but typically you will have to look at the document to see where they occur and why. Symbolic constants make that problem worse.

And, later:

For many people, style sheets with constants will thus simply not be usable. It is too difficult to look in two places at once, the place where a value is used and the place where it is defined, if you don’t know why the rule is split in this way. Many people are confused by indirection anyway and adding an extra one, in addition to the element and class names, has the same effect as obfuscating the style sheet.

Whether or not you believe Bert Bos is underestimating the average web designer, it’s pretty clear that these are really good points. Nobody wants CSS to be obfuscated, hard to learn, or hard to reuse. That’d just be crazy talk.

In the other corner: CSS variables are a real-world requirement

The more features you add to an application, a programming language, or indeed any software, the more difficult it becomes to grok it. As the Python people would say, the larger a language gets the more difficult it is to hold all of it in your head. Nevertheless, adding “features” is sometimes the only way to add capabilities, and I don’t think anyone in their right mind would argue that, once written, software should never change. (That’d just be crazy talk, too.)

In his opposing arguments, Matt Wilcox recognizes this when he says, Yes, the syntax should be simple, but the capabilities of CSS should not. What he’s alluding to without verbalizing it is the balance between adding necessary capabilities without unnecessarily growing the “size of the language.”

However, Matt says that modern web design methodologies (e.g., separation of concerns between structure, presentation, and behavior) dictate that CSS needs more capabilities than it currently has:

CSS lacks capabilities to allow truly flexible design, requiring layer upon layer of ‘tricks’ to accomplish certain objectives, requiring content to be structured ‘just so’ to achieve a display objective, or in the case of some designs proving instead to be completely incapable.


CSS’s positioning is a cludge. It’s a cludge because you can only position relative to the last positioned parent container. Well, that limitation in itself dictates that all positioning relies upon how the content is structured. And that means the presentation and the content are not truly separable.

To align CSS’s capabilities with the requirements of real-world web design objectives, he says, CSS needs to be capable of describing relationships between semantically and structurally arbitrary but visually related elements.

Visual design is fundamentally about relationships between elements. For all of the artistic flourishes and creativity, it’s about relationships. ‘That yellow’ only grabs your attention because of its contrasting relationship with ‘that blue’. ‘This heading’ only works as a heading because of it’s exaggerated relationship to the size of the body text. […] CSS has no clue about relationships, period. And that’s why CSS as it stands right now, is not good enough. That’s why CSS without variables (true variables), without basic logic, without maths, can never be as flexible as we need it to be.

This is what web designers have been complaining about for (what feels like hundreds of) years. The fact that CSS has no capability to describe presentational relationships between elements in addition to directly describing an individual element’s presentational properties is a gaping hole that sorely degrades its ability to be a media-agnostic styling language. Every single web designer I’ve worked with has gasped at this omission, and though at first I didn’t understand why, the more I understood the principles behind graphic design the more I came to realize how fundamentally problematic this omission really is.

Adding delegation makes CSS easier for designers

As Matt eloquently stated, design is all about relationships. Good web designers create designs by constructing visual elements that have strong, often exacting relationships with other visual elements. There are many names and examples for this: visual language, visual hierarchy, the golden ratio, the grid, visual balance, the typographer’s scale, and so on.

What happens when the designer tries to define a relationship between elements? “How do I say that the whitespace between element A and element B should always be the same? How do I define element A’s height as half of element B’s?” These definitions, which are natural and necessary to the way designers work in both their mind and their mediums, are impossible to encode in CSS.

The closest you can get is declaring the same values to each element’s properties, not describing the relationship itself. This suffices only so long as these values are known ahead of time and are the same as one another, which severely limits the design possibilities we are capable of (without resorting to what Matt calls “tricks”). That’s why achieving simple visual effects are actually very complex and so, sadly, that’s where you’ll find the majority of indirection and obfuscation in CSS today. (I’m looking at you, faux columns.)

So who wins?

Both Bert Bos and Matt Wilcox have made some great points. Bert rightfully wishes to keep CSS lean and simple, even at the expense of some arguably beneficial styling power. Matt, on the other hand, argues that our needs as web designers have evolved faster than the technology to the point where CSS is too limited, fundamentally so.

The truth is, they’re both right. And they’re both wrong. Or rather, they are each taking a position that is too extreme. Bert’s absolutely correct when says that many of these proposed extensions are redundant and harmful, and yet Matt’s also correct that CSS lacks some fundamental capabilities that designers expect to be present.

Bert says that the CSS capabilities everyone’s asking for can be implemented using techniques that don’t rely on CSS whatsoever. These techniques, he says, make things like true CSS variables “redundant.”

There are examples of CSS with constants to satisfy all styles of programming, e.g.: David Walsh (in PHP), Tedd Sperling (in PHP), Digital Web Magazine (in PHP), Eco Consulting (in SSI), and Christian Heilmann (SSI and PHP).

Quite simply, he’s correct in stating that programmatic features need not be added to CSS proper to achieve desired results, but he’s incorrect in his apparent thinking that designers will be able to use these other tools to leverage CSS. Take, for instance, the probably more familiar (though not linked above) notion of using JavaScript to manipulate CSS values.

var x = document.getElementById('SideBar'); // get #SideBar element
var y = document.getElementById('MainColumn'); // get #MainColumn
var z = document.defaultView.getComputedStyle(y, '').getPropertyValue('height'); // get computed height of #MainColumn = ( parseInt(z) / 2 ) + 'px'; // set #SideBar's height 1/2 of #MainColumn's

This is an example of programmatic code that uses variables and expressions. It sets the element with the ID of SideBar to half the pixel height of the element with the ID of MainColumn. It does this by obtaining the MainColumn‘s height (at the time this code runs) and saving it in a variable, then performs some trivial math to half the value and use the result as the pixel height of the SideBar.

Doing this is currently impossible with CSS alone, yet it’s something that clearly belongs with whatever other “presentational” code exists and not in “programmatic” scripts that would otherwise be charged with defining “functionality.” As Matt states, using JavaScript to “script” solutions to CSS’s shortcomings like this is not an acceptable answer.

CSS doesn’t have [basic logic or maths]. Nor is it the job of JavaScript to make up for this lack of abilities. JavaScript is about interaction behaviour, and what we are talking about here is pure display logic. Not interaction logic.

Moreover, the place designers expect to put code like this is, of course, into a CSS style sheet. The way designers expect to put code like this into CSS is by adding delegation features. Requiring designers to learn JavaScript (or any other programming language) to encode such design relationships is nothing short of ridiculous. In what world is that easier for untrained laymen to understand than CSS?

Adding delegation to CSS is worth the effort

One of Bert’s arguments against such additions to CSS is that implementations would become harder to create, and that we’ll (almost certainly) see more bugs.

extending CSS makes implementing more difficult and programs bigger, which leads to fewer implementations and more bugs. That has to be balanced against the usefulness of the extension.

Although I do agree with his statement that an extension’s usefulness has to be balanced against its potential costs, I think something so fundamental to design methodology as delegation greatly overcompensates for the cost of such implementation efforts. Moreover, if I understand Bert correctly and as he also discusses, the majority of implementations that would need to implement such delegation already have relatively complex internal structures to make the implementation effort somewhat easier:

There is no scoping [in proposals that only define global constants]. That means that an implementation needs a symbol table, but no stack. A stack would require a little bit more memory, but mostly it would make implementations more complex. (Although every programmer has, one hopes, learnt to program a symbol table with lexical scope during his training.) Constants in CSS are thus easier than, e.g., XML Namespaces, which are lexically scoped.

It is different for those CSS implementations that provide a CSS Object Model (an API for manipulating a style sheet in memory). Those implementations do need to keep track of scope in some way, because adding or removing a line of the style sheet can make a previously redundant definition become meaningful.

In order to use JavaScript to solve many of the shortcomings of CSS, as huge numbers of professional web developers do routinely, we use the very CSS Object Model whose prior implementation already exists for us to build upon.

CSS delegation doesn’t grow the size of the language

For the sake of argument, let’s simplify our requirement somewhat so that our somewhat contrived example of design intent is to create a relationship between the MainColumn and the SideBar elements such that they are of equal height. This is more informally known as “making columns.”

Here’s what a natural, hypothetical snippet of CSS would look like if the language supported delegation features such that it could encode visual relationships.

#SideBar { height: #MainColumn; }

This code theoretically says almost the exact same thing as the JavaScript shown earlier (save for the division, of course); it takes the computed value of the MainColumn element’s height property and applies that value to the SideBar element’s height property. In other words, “The SideBar’s (element B’s) height is always the same as the MainColumn’s (element A’s).” (Of course, this is a parse error in reality today.)

This extremely trivial example has some remarkably far-reaching implications, and yet there is really nothing radical about its syntax. Making this a reality significantly expands the capabilities of CSS without dramatically increasing the size of the language. This capability would not only beat the pants offCSS tables,” it also potentially obsoletes the arguably misguided efforts of the CSS3 Advanced Layout and Grid Positioning modules, too.

We’ve long since abandoned table layouts because they force us to use presentational markup. That’s still what “CSS tables” force us to do, too. In other words, with display: table, the SideBar needs to be a child of the MainColumn element or, maybe worse and more likely, a child of a semantically meaningless wrapper element.

CSS positioning was introduced with the promise of freeing us from source-order-dependent styling, without which there is no hope of efficiently abstracting presentation away from structure. Moreover, abstracting presentation away from structure is the single most important prerequisite needed to improve document reusability and strengthen the semantic Web. Absolute positioning works, but limitations elsewhere in CSS mean its use is problematic for many designs, so in practice it doesn’t gain widespread adoption.

Here’s a theoretical solution to a two-column and a footer layout using CSS delegation with this semantic HTML:

    <div id="MainColumn">I'm the main column.</div>
    <div id="SideBar">I'm the right-hand sidebar.</div>
    <div id="Legalese">No one will read me.</div>

The CSS would look extremely familiar, possibly like this:

#MainColumn { margin: 0 25% 1em 0; float: left; }
#SideBar { width: 25%; min-height: #MainColumn; }

Using the same HTML, the same solution using the CSS3 Advanced Layout module would look something more like this, although to be frank I’m not certain I fully understand this syntax even after staring at it for months:

body {
    display: "a  b"
             ".  ." /1em
             "c  c"
             75% 25%
#MainColumn { position: a; }
#SideBar { position: b; }
#Legalese { position: c; }

Not only does there seem to me to be far more indirection in this method than there would be using CSS delegation, there is also an enormous increase to the size of the CSS language: a new (ASCII-art?!) value to the display property whose syntax is clunky at best. A similar story can be said of the CSS3 Grid Positioning module, which does lots more than just add a new (already complex) gr CSS unit.

The upshot is that the Advanced Layout and the Grid Positioning modules are doing some of the right things in many of the wrong ways. Both those modules add unnecessary complexity to CSS without giving designers a natural way to say what they mean. They do more to introduce obfuscation and indirection than simple delegation would, and they aren’t as broadly capable. Both of them try to solve a specific problem instead of dealing with fundamental deficiencies in the toolset designer’s have to work with.

Designers want relationships via delegation, not variables

Adding delegation such as that I’ve just shown is a natural, necessary addition to CSS because it is how designers create visual components—such as grids—in their designs. Variables (and constants, and macros, etc.), which simply reuse and modify pre-defined statements aren’t what designers care about. Adding them will bloat CSS without adding useful functionality.

“Okay,” you may be saying to yourself, “but delegation is itself a kind of variable, isn’t it?” Technically yes, however adding delegation resolves the core deficiency in the CSS language that designers need to use every day. Yes, it’s technically a form of variable, but that’s not how designers think of it. To say that one element’s visual properties is like another makes a variable only by creating a logical and visually appropriate mapping from the first element’s property to the second independent of markup, thereby avoiding indirection in the form of a variable name or other unfamiliar symbol.

Delegation like this doesn’t require the addition of anything other than what already exists in CSS. Class names and ID values are identifiers whose indirection people already have to deal with. Using them for delegation (to reference another element’s style) doesn’t increase the cognitive load any more than using them to reference HTML elements does. Though untested, the cognitive load might actually be even less since the CSS delegation’s references could be in the same (style sheet) file.

Moreover, delegation will increase the likelihood of document reusability by enabling style sheets to be more self-describing, more self-referential, in a similar way as good markup is. It satisfies a very fundamental need that designers have to define graphical relationships between elements. At the same time, it does so in a way that is natural to both their way of thinking and beneficial to the separation of concerns principle on which the “web stack” (the trifecta of HTML, CSS, and JavaScript) is based.

WP-Oomph: Add the Oomph Microformat Overlay to your WordPress blog

I’ve just developed a completely idiotic (by which I mean brain-dead simple) plugin for WordPress that will add the Oomph Microformat Toolkit to all WordPress-generated pages. If you use a WordPress template that encodes your data with valid microformats anywhere on your page, this means when you install the plugin your users will see the Oomph microformat overlay and will be able to instantly export this encoded data.

This page is a live example, so if you’re using a JavaScript-enabled browser you should see a microformat icon on the top-left of the viewport that is pulling data from (at least) my “The bio” section in my sidebar. Go ahead, click it. I’ll wait.

Pretty nifty, isn’t it? Naturally, all of the credit for this functionality belongs to the Oomph team, not me. If you want to learn how to add microformats to your blog, I’d recommend Emily Lewis’s latest series of blog posts, Getting Semantic with Microformats. If you want to learn how to easily add the Oomph microformat overlay to your WordPress blog, read on.

The backstory

After’s announcement that they are adding semantic search capabilities to their search engine, there’s little doubt in anyone’s mind that the semantic web is the future’s web. As far as I know, Google has yet to reveal similar initiatives but they are clearly in the know as well. Mark Birbeck, one of the smart folks who devised RDFa, recently gave a Google Tech Talk that made the point that semantics are the next big thing in the Internet search engine game.

However, for semantic web stuff to really take hold, two things need to happen first. I think these things need to look like this:

  1. Developers must create tools, plugins, and other software that makes it possible for the wider community to create compelling, interoperable applications that support semantic encoding. Thankfully, we are already at this point, with toolkits like the Oomph Microformat toolkit coming out of MixLabs.
  2. Armed with these software tools, CMS and other publishing platforms need to adopt semantics as first-class features of their platforms, and build interfaces that end-users can make immediate use of. This is where we still need to go, though some platforms like Drupal have begun to pave the way for this.

Drupal 7 will be fantastic, I’m sure, but we live in the here and now. I saw the Oomph microformat overlay on Emily Lewis’s blog and was more convinced than ever that if everyone—programmers and laymen alike—had easy access to these tools, they’d simply be pounding down the doors to use them. So that’s why I sat down and wrote a completely idiotic plugin for WordPress that makes it completely, utterly, brain-dead simple for anyone with a microformats-enabled WordPress theme to add the overlay to their site.

WP-Oomph: Download the plugin

My request to add the plugin to the Plugin Directory has not yet been completed, so in the mean time I’m hosting the plugin right here. (When/if it’s accepted it’ll end up being The plugin is hosted on that site permanently.)

The latest version is: 0.1.1.

Download the latest version of the WP-Oomph plugin.

Thanks to the Oomph team’s work, the plugin is a ridiculous 1-liner (for now) that uses WordPress’s wp_enqueue_script() function to call both its included jQuery library and the Oomph library itself. And, well, that’s it. I told you it was idiotic, but at least now the whole process of microformat-enabling a WordPress blog is 100% point-and-click.

WP-Oomph: Frequently Asked Questions

I installed and activated the plugin, but nothing is different. How come?

First, view the source of your WordPres-generated page and make sure you see a line similar to the following near the top:

<script type='text/javascript' src=''></script>

If you see that but there’s still nothing different about your page, then you probably don’t have any (valid) microformats. You might consider switching to a WordPress theme with built-in microformat support, or modifying your theme’s code to add some of your own. You can learn more about the support WordPress offers for microformats in the Microformat wiki.

The plugin does let me do X thing that I want to do! Why not?

Most likely because I haven’t taken X thing into account. Sorry, I’m not a psychic (as much as I wish I were). However, you’re encouraged to leave a comment on this post or to contact me elsewhere to request that I add capabilities to the plugin. Better yet, if you’re comfortable doing so, send me a patch.

How web designers can do their own HTML/CSS: Read Foundation Website Creation

Last month, 37signals published a short but sweet post about why web designers should do the HTML/CSS implementations for their own designs. The bottom line is, as we’ve all been saying for a long time now, that the Web is not the same kind of medium as other mediums like print. It is a fundamentally different kind of canvas than most web designers are used to using. As a result, if you as a web designer are not intimately familiar with it, you’re not going to do great work.

designing for the web is a lot less about making something dazzle and a lot more about making it work. The design decisions that matter pertain directly to the constraints of the materials. What form elements to use. What font sizes. What composition. What flow. Those decisions are poorly made at an arm’s length.

I’ve worked with many web designers in the past who only did abstractions and then handed over pictures to be chopped and implemented by “HTML monkeys”. It never really gelled well. The things that got strong attention were all the things that Photoshop did well. Imagery, curvy lines, and the frame. All the around stuff, never the it stuff.

In other words, to do great web design you have to design in the Web, not in some other medium for the Web. I mean, serious magazine firm employs designers who don’t understand how to work with page layout programs like InDesign. Why, then, do so many web design agencies employ designers who don’t know how to work with web technologies, or even how to use programs like Dreamweaver? It doesn’t really make any sense, and it’s no wonder that the resulting implementation is rarely top-notch work.

But if you’re a graphic designer who doesn’t know much about Web technologies, what are you to do? Well, as a first step, I think you should pick up my new book, Foundation Website Creation. It’s available from all good booksellers (and probably some crappy ones) as of today. The book is targeted towards all manner of web professionals, including graphic designers and website producers, who want to learn more about what it takes to actually implement a site.

If I do say so myself, the chapters on XHTML and CSS are exceptionally thorough. The book doesn’t try to turn you into an exceptional programmer. Instead, it will explain the foundational concepts you need to know to understand how XHTML and CSS actually work, and in so doing will enable you to use the tools you already know to solve problems and get things done.

I think this book will be an excellent starting point for lots of designers and other web professionals. However, it is not going to take you from zero to hero—no book can. That’s why I recommend that, after you read Foundation Website Creation and have a solid grasp of what the technology can do for you and how it actually does it, you next take a look at these excellent books:

  • DOM Scripting by Jeremy Keith — if you’re a designer that needs to add a behavioral layer with JavaScript and Ajax to your pages, you need to read this book next.
  • Mastering CSS with Dreamweaver CS3 – if you’re familiar with Dreamweaver and want to keep using it to create standards-based web sites, then I recommend you follow Foundation Website Creation with this book by Stephanie Sullivan and Greg Rewis to take your Dreamweaver skills to the next level.

As always, most of all, have fun. Because if you’re not having fun, you’re not going to make good web sites no matter what you know.

Note: As of this writing, the book listing on Amazon still publishes the wrong author list, which is very frustrating but out of my hands. At least the image of our book’s front cover lists the correct authors.

I’m getting a book published and it’s called Foundation Website Creation

For those who have been wondering what is keeping me so busy these days, the answer is that I’m working on the final stages of a book that is getting published as one of three co-authors. Not only am contributing three chapters (the technical chapters on (X)HTML and CSS, specifically), but I am also technically reviewing the entire book.

My co-authors on the book, called Foundation Web Standards Foundation Website Creation (you can pre-order now) and published by Friends of ED, an Apress company, are Jonathan Lane of Industry Interactive, Inc. and Joe Lewis, who blogs at I’m not going to say much more until after the book is released in late July.

For the eager, here’s the description of the book posted on the Friends of ED website:

Foundation Website Creation explores the process of constructing a web site from start to finish. There is more to the process than just knowing HTML! Designers and developers must follow a proper process to flush out goals and objectives and determine requirements both prior to, and during project development.

Large Web projects are rarely completed by a single person. Producers, project managers, designers, developers, writers, and editors all play critical parts in a project’s evolution. This book provides an overview of the entire process, and also shows project development from the perspective of these different roles. It introduces the key concepts and duties performed by every member of such a team, and gives you the skills necessary to tackle projects like a professional.

It’s quite exciting getting a book out, and it’s quite a bit more work than I’d have ever originally thought. That being said, it’s extremely rewarding. There’s a lot more work I need to do on it between now and the time it gets released to publishing, so, well…back to work I go.

Now you all know where I’ve been spending my time writing.

Browser Developer Insight and Nightmares

Dave Hyatt, a developer of Apple’s Safari web browser offered some amazingly enlightening insight into the nightmares of browser developers the other day. The only thing I can think to say is: Dave, thanks for trying.

This is a great example of how IE’s inconsistent rendering behavior has long-lasting negative effects on the adoption of CSS not only by web page authors, but web browser authors. As Dave himself says,

So now I really have no choice. This is an example of where the CSS2 standard simply can’t be followed because buggy layout engines have set a bad precedent that the rest of us have no choice but to follow.

It’s a shame that Gecko does not do the right thing in strict mode at least, but I suppose they had no choice in the matter either.

This is reminiscent of back when Opera was beginning to look more and more like Internet Explorer, but at least it’s not a bug this time.

Observations on the CSS3 Box-Sizing Property and How Designers Use Style Sheets

Recently, I became aware of CSS3’s box-sizing property. This property can have two values, content-box and border-box. The content-box value is what we’re all used to. It causes the selected box’s dimensions to be sized by setting the specified width of the box equal to the width of the content area of the box. Any horizontal borders or padding that the box has is then added to the content area’s width. The border-box value sets the selected box’s width equal to the content area and any horizontal borders and padding, effectively subtracting the width of the padding and border from the declared width in order to calculate the content area’s width.

In other words, the border-box value to the box-sizing property makes the selected box use Internet Explorer’s non-standard box model. At least, it was non-standard until it became part of the CSS3 spec. The spec even notes this itself, saying “This is the behavior of width and height as commonly implemented by legacy HTML user agents for replaced elements and input elements.”

This is somewhat annoying, because this means that rather than fix their “Web browser,” Microsoft can now say that their browser supports this property of CSS. In the end however, I do see the necessity of the property for compatibility reasons, as much as that necessity (caused by one browser vendor’s lack of support for Web standards) bothers me.

The most direct application of this technique comes in the form of making two child elements who have borders and/or padding fit precisely within one larger parent element whose width is flexible. For example, making floated, columnar layouts.

So while taking all this in I took some time to familiarize myself as best I could with Firefox’s implementation, the -moz-box-sizing property, and its effects. Some of my observations:

  1. Most interesting uses for three column liquid layouts (or more). Two column layouts can use a (more complicated) balancing of float: left and float: right to achieve a similar effect in a liquid layout, though a small, variable amount of space between columns is nearly unavoidable.

    Also, experienced designers usually keep a certain degree of whitespace in their layouts, making such tightly fitted floats largely unnecessary and/or impractical implementations for certain designs. (I.e., positioning would be a more appropriate solution.)

  2. Border-boxes offer no help for linking the height of a box to the height of its neighbor. Considering this is the biggest failing of CSS-based columnar layouts to date, I would stick with an accessible table where absolutely necessary, which can be and often is sized just like a border-box.

  3. When confronted with left-floated boxes such as in the case of a columnar layout, IE/Win versions that use the border-box method of calculating width and height will drop a tightly-fitted floated box below its neighbor on a window resize. This creates either a trippy experience or cause for frustration depending on your mood. Considering this property is at least partially intended to help IE/Win, that’s quite an embarassing thing to have happen, methinks.

  4. All in all, I’m still not convinced of the necessity of this property, except to support IE. While it can certainly be a useful “option” when attempting to create (arguably simplistic) column layouts using strictly semantic markup and CSS, tables are still going to be necessary in some designs. In the situations where they are not, a combination of existing techniques can still be used to achieve any desired effect.

Furthermore, this certainly doesn’t help make CSS a more approachable topic for Web designers who are new to the technology. The single largest obstacle to CSS’s widespread adoption are the many various and often extreme browser bugs and quirks present in the majority of browsers. When a CSS newbie begins writing some stylesheets, they are greeted with horrendous results thanks to these misbehaving browsers. I know of several Web design projects that have begun using stylehseets, only to abandon all but their most basic capability due to frustration on the designer’s part. Some CSS concepts are not easy to grasp for beginners, the box model being one of them, and I am not fond of the idea of presenting designers with yet more differences in the way their pages can be rendered.

Moreover, most CSS beginners I have encountered use a GUI such as Dreamweaver or GoLive to create their stylesheets. In this case, a question arises for the developers of these interfaces: how do I visually show which kind of box-sizing is being used for this particular box on the screen? Do I show a little icon in the corner of the box’s display? Do I hide it in a dialog box?

In my opinion, these interfaces are not very good for creating style sheets. There is currently no application whith which you can actually draw, with your mouse, a rectangle of padding onto an element. You have to type a number into the “Padding” input box and then select the unit you’d like to use from a drop down menu. Designers do not think this way. Coders and programmers do. But coders and programmers aren’t the ones who really need CSS. Designers do. And they need their tools and their web browsers to speak their own language to them.