The BDFL has already weighed in on anonymous blocks in Python:

If you want anonymous blocks, by all means use Ruby. Python has first-class callables,¹ Ruby has anonymous blocks. Pick your favorite, but don’t whine that neither language has both. It ain’t gonna happen.

This seems to imply that first-class callables and anonymous blocks are mutually exclusive language features, but that’s wrong: JavaScript has the ability to pass callables around like anything else, and it has anonymous functions, which can be used just like Ruby’s anonymous blocks. Does that mean JavaScript is better than Python or Ruby? My feelings about Ruby are indifferent with a chance of rain, but I love Python, so I’ve got to ask: are you going to take this lying down, Python?

I’m not sure Python needs full-blown, Ruby-style anonymous blocks. But it might be good enough to be able to use function definitions as r-values, like JavaScript can. (If you’re not already wearing your tinfoil hat, now might be a good time to put it on.)

This would allow asynchronous code to be written in conceptual order (just like in JavaScript):

do_something_asynchronous(param1, param2, (def callback(result):
    do_something_with_result(result)
))

And it would allow encapsulation of lexical scope inside specific iterations of a loop to be used later when an asynchronous call returns (just like in JavaScript):

for item in results:
    (def single_iteration():
        do_something_asynchronous(param1, item, (def callback(result):
            do_something_with_result_and_item(item, result)
        ))
    )(item)

I’ve even had occasion to want that other Python namespace, class, to operate as an r-value:

class MyConverterClass(BaseConverterClass):
    my_converter_type = (class MyConverterType(float):
        def __str__(self): # a custom __str__ method
            return '%0.2f' % self
    )

In these examples I’ve wrapped their inline definitions in Python’s great syntactical equalizer, the parenthesis. It would be even nicer to be able to leave them off, but I’m sure that this syntax would run headlong into Python’s whitespace-based block definitions, and it would be even more of a train-wreck without parentheses.

I’ve also named the defs and classes. It would also be nice to be able to omit the function or class names if they were unneeded (just like in JavaScript). But anonymous functions, a.k.a. lambdas, are the electric third rail of Python syntax, so anonymous classes would be… I dunno, the nuclear fourth rail?

1. Thanks to Steve for explaining that by “first-class callable,” GvR means functions that can be passed around and assigned to other variables without being executed. He also pointed out that the reason Ruby’s callables aren’t first-class is because optional parentheses in function calls leave no way to refer to a function without calling it, not because of the existence of anonymous blocks.

But also with this periodic table of periodic tables¹ by keaggy.com:

Before the Periodic Table of the Elements, elements were a chaotic collection of substances with seemingly random and unpredictable masses, melting and boiling points, electrical, chemical, and material properties, and so on. Not only did the periodic table organize the known elements in a way that explained these properties, but it correctly predicted the existence and the properties of undiscovered elements.

All these parodies of periodic tables² are only funny because this tendency towards scientific organization has totally permeated popular culture. And that’s pretty encouraging.

1. For those of you who hate your web browser and want it to crash, there’s also a version of the Periodic Table of Periodic Tables that uses an off-the-shelf Flash app and 217% of your CPU to make a zoomable interface that could be done in about ten lines of CSS & JavaScript, and 0% of your CPU.
2. My very own Periodic Table of the Europeans is at “Eu,” (number 63), smack dab in the middle of the “Awesomeoids” (the green row). Thanks, keaggy.

FlakeNot keeps track of all your invitations in a single place. To sign up, forward pretty much any email with a date and a time in it to new-event@flakenot.com. FlakeNot will create an account for you and remember all the events you send it.

Once you’ve forwarded some events, send email to calendar@flakenot.com and you’ll get an email with your upcoming events. And visit flakenot.com to see your calendar on the web.

That’s it. No fancy logo. No social network, no profile photo. No Flash applet. No Google Maps mash-up. No video chatting with random strangers. Just a quick, simple way to keep track of all your invitations, so you can get out there in the real world and spend time with your real friends.

Yes, it works with Evites and Facebook invites. Yes, there’s a version of the site optimized for your Android/iPhone/Palm Pre. Yes, we plan to support Google calendar, write a Facebook application, and integrate with iCal. Yes, yes, yes.

You will be very surprised how you interact with the new tablet.

What could this mean? There are not many interfaces that would be “very surprising.”

A virtual laser keyboard would be surprising. But like a real keyboard, those keyboards aren’t very mobile; they require a flat surface, which you normally don’t have on the move. And a virtual keyboard doesn’t really seem like Apple’s style.

Voice control, or at least good speech recognition to complement keyboard input, is also a serious possibility. It’s something Apple has been interested in for a long time (via DF). A world where airports, subways and coffee shops are filled with people dictating emails and blog posts to their mobile devices is a little terrifying, but then again we already live in a world where people are have intimate personal conversations on their mobile phones in public.

A significantly expanded set of multi-touch gestures is the most likely. Taking advantage of the larger surface of a tablet screen to allow two-handed gestures seems like a natural choice. And handwriting detection would actually not be that much of a surprise from the company that brought us the Newton. Both of these are hinted at in recent patent filings.

While the article I link to in the previous paragraph compares Apple’s patent to the interface in Minority Report, the interface that article talks about requires the user’s fingers to be touching a surface, not in the air. A true Minority Report-style interface, where you gesture in the air to control the device, would be quite surprising. Being able to control a device without actually touching the screen (and getting finger marks on it) would make the tablet more attractive for full-screen uses like watching movies and playing games. This interface is a ways off still, though.

Feel free to let me know what you think, good or bad. I’m also looking for a name, if anyone has any suggestions.

Here are ten quick tips for achieving maximum unmaintainability in your web application. Following them will ensure that, in thirty years, a web programmer like you will be as valuable as a fifty-eight year old COBOL programmer contracting at $200/hr for a Fortune 500 company that still hasn’t migrated off of PL/1. You too will be able to live on a dairy farm in Pennsylvania, grow a beard down to your navel, and work in your underwear. And you’ll never have to learn anything new, work with anyone else, or start another new project.

1. Mix it up. Put some JavaScript into external files, but be sure to intersperse JavaScript into your HTML, some of it in <script> tags. Cram multiple JavaScript statements into onclick and other event attributes — the longer, the better. Do the same with CSS; put some into external files, some in <style> tags, and also put some critical CSS into complex style attributes. And remember to put most of your <script> and <style> tags in the middle of the page content, instead of in the <head>, so that they will be difficult to find.
2. Make everything dynamic. Generate JavaScript and CSS in your HTML templates. Think of it as another type of eval. Generate HTML server-side using templates and browser-side using JavaScript. What’s harder than working around a obscure IE layout bug with weird markup tweaks? Making sure both your server templates and your JavaScript HTML generation work around the same bug with the same HTML black magic.
3. Abstraction, Shmabstraction. Pass lots of data from the server to the browser, store it in hidden form fields in the page, and then pass it back, unchanged, when submitting the form. That way, when the back-end data model changes, you get to rewrite part of the interface too. Allow data-model or server implementation details to creep into the interface implementation. Is the database sharded? Is the cache dirty? Does this row use a composite key? No need to have the server abstract these details, just pass that information to the JavaScript and let it sort everything out. That way, a sysadmin or a DBA can break the UI just as easily as a web designer can.
4. Keep your data unstructured. Make sure all communication between the browser and the server is just a flat list of key/value parameters. Some of your parameters will be data to store, others will be modes or flags that affect the behavior of the service you’re hitting, and still others will be modifiers to display messages or affect the behavior of the UI. Keeping your data unstructured ensures these different types of parameters will collide. Often.
5. Commit to a platform. Don’t waste your time checking to see if your pages work in all browsers (at least not until you’re totally done). Better yet, develop only in a single browser and don’t even bother to find out whether the features you’re relying on even exist in other browsers. Nothing is more fragile than an application that’s tightly tied to a single platform.
6. Trust the browser. Rely soley on JavaScript input checking for some data — don’t check input on the server-side. Store sensitive data in hidden form fields. Put authorization checks in the JavaScript rather than on the server. Parameters like authorized=1 just scream out for URL hacking, and storing them in hidden form fields is only slightly harder to hack.
7. Trust the server. Rely soley on the server to check, store, and generate only valid data in some places. That way, a DBA can change a single column constraint or data-type, and parts of the UI start to fail.
8. Don’t use DOCTYPEs. That way you’ll never be sure what rendering mode different browsers are going to use to render your content.
9. Ignore the cascade. Don’t bother to understand what the C in CSS stands for.  Just keep overriding styles until a page element looks the way you want. That way, your styles will be fragile and will break unexpectedly when an intern changes something a reasonable person would expect to be unrelated.
10. Don’t use classes or ids. Instead, always write JavaScript and CSS that finds nodes based on tag name, name, alt or title attributes, or by their position in the DOM. That way when anything in the page changes, the hierarchy, the attributes, or when the site is translated into another language, things break. If you do end up using class or id, be sure to make a separate class for every node in your document and assign the same id to several different nodes.

If, however, you want to write flexible code that can react to and evolve with the ever-changing needs of its users, even after you have left the project in the hands of a clever but inexperienced hacker, you should probably avoid these techniques, and read up on some of those lame new design fads instead.

Special thanks to all the programmers whose code has illuminated these techniques over the years. My job may not be as secure as yours, but at least my code, and my conscience, are clear.

Shapeways, a Netherlands-based website, offers high-quality, relatively cheap rapid prototyping, and a place to host your own selection of models. As a website, Shapeways is no RedBubble — the interface and marketplace tools leave much to be desired. The ratings and sorting can be gamed, it’s trivial to figure out the markup on another user’s model from its price, there’s no way to replace a published model with an improved one, and the site has encoding and markup issues. But what’s a few flaws when you own the category?

The free version of Google SketchUp has been satisfactory for rendering thus far, and its user interface is leaps and bounds ahead of the bizarre interface of Blender. I’m sure Blender has a superior feature set, but what good is power when you can’t figure out how to use it? Meshlab and AccuTrans3d have both come in handy for checking surfaces and converting between formats.

On to the models! Click on the pictures to see more views of each.

Trapped Outside

Trapped Outside is a model of Boy’s Surface with a sphere trapped in the space cut out by the one-sided surface. Boy’s Surface an immersion of the projective plane, which means it is a Möbius strip with a disk glued to its edge. It is a non-orientable surface with no edges and no pinch points.

Trapped Outside was fairly easy to create using Google SketchUp. It’s just a few circles extruded along each other here and there.

Hollow Knotted Gear

The Hollow Knotted Gear, inspired by Oskar van Deventer’s Knotted Gear, consists of two interlinked knots; a trefoil knot (in green) and its dual, a 3,2 torus knot. The green trefoil forms a rectangular cross section and a triangular hole. The blue knot forms a triangular cross section and a rectangular hole. The two knots gear perfectly together, and can move around each other, but only if they are both moved simultaneously.

After many failed attempts at getting various applications to render this complex extrusion properly, I wrote a small Python program to calculate the surface for me and output VRML. Then, after much more trial and error, I used AccuTrans3d via Wine to convert the VRML surface to a DAE file for uploading to Shapeways, and to a 3DS file for examining in Google Sketchup (and to take screenshots).

There are a few more of my designs on Shapeways right now, and even more rattling around in my head just waiting to be prototyped.

Here’s the patch:

@@ -20,7 +23,7 @@
       $win = $(window);

     function remove() {
-      if ($input.val() === title && $input.hasClass(blurClass)) {
+      if ($input.realval() === title && $input.hasClass(blurClass)) {
         $input.val('').removeClass(blurClass);
       }
     }
@@ -41,4 +44,17 @@
   });
 };

+
+$.fn.realval = $.fn.val;
+
+$.fn.val = function (value) {
+  var i = $(this);
+  if (value === undefined) {
+    return (i.realval() === i.attr('title')) ? '' : i.realval();
+  } else {
+    return i.realval(value);
+  }
+}
+
+
 })(jQuery);

And here’s the full plugin with the patch applied:

/**
* @author Remy Sharp
* @url http://remysharp.com/2007/01/25/jquery-tutorial-text-box-hints/
*
* better val() method added by Matt Chisholm, 2009/07/27
* http://glyphobet.net/blog/essay/878
*/

(function ($) {

$.fn.hint = function (blurClass) {
  if (!blurClass) {
    blurClass = 'blur';
  }

  return this.each(function () {
    // get jQuery version of 'this'
    var $input = $(this),

    // capture the rest of the variable to allow for reuse
      title = $input.attr('title'),
      $form = $(this.form),
      $win = $(window);

    function remove() {
      if ($input.realval() === title && $input.hasClass(blurClass)) {
        $input.val('').removeClass(blurClass);
      }
    }

    // only apply logic if the element has the attribute
    if (title) {
      // on blur, set value to title attr if text is blank
      $input.blur(function () {
        if (this.value === '') {
          $input.val(title).addClass(blurClass);
        }
      }).focus(remove).blur(); // now change all inputs to title

      // clear the pre-defined text when form is submitted
      $form.submit(remove);
      $win.unload(remove); // handles Firefox's autocomplete
    }
  });
};

$.fn.realval = $.fn.val;

$.fn.val = function (value) {
  var i = $(this);
  if (value === undefined) {
    return (i.realval() === i.attr('title')) ? '' : i.realval();
  } else {
    return i.realval(value);
  }
}

})(jQuery);

This was from the unauthenticated view of my (now-disabled) OkCupid profile. The black text in the bottom half of this screen-shot was my somewhat snide response to OkCupid’s seventh-grade reading level getting-to-know-you question. And at the top is a plug for a different user and an ad for a book that has absolutely nothing to do with me or my tastes¹.

The last thing that any OkCupid user should want is for readers to be distracted from their profile like this. And I really didn’t want some site co-opting my identity and interspersing advertisements and links to generate more page views into the middle of it. Even if it was to support a free site. So, OkCupid, you have joined the ranks of other online dating sites that just don’t cut it. Thanks, but no thanks.

1. A Summer Affair’s plot summary on Amazon makes it sound like an upscale romance novel with a helping of East Coast affluence-porn thrown in.

• What the datetime module (introduced to replace mx.DateTime and fix shortcomings with the time module) is missing? It’s always handled everything I’ve thrown at it.
• What is wrong with optparse? Usage? Functionality? Implementation?

I also just plain don’t understand his complaint about del versus remove. I think mystuff.remove(mything) and del mystuff[4] do exactly the same thing, so what’s the problem? That del exists?

His promise to provide patches will be an interesting test of the Python community’s ability to judge patches on their objective merit, not by their contributor, since Shaw seems to have a tendency to ruffle feathers¹.

And a “WSGI for templating,” and efficient state machines with generators? Sounds exciting.

1. This is the pot calling the kettle black here.

This winner-takes-all system of allocating electoral votes also has the side effect of making a few “battleground” states the primary focus of election campaigns. Candidates descend on these states, funneling money and advertising into them, and tailoring their campaigns to win over voters there. Voters, of either party, in the remaining “spectator” states are effectively disenfranchised, and the small percentage of voters in the battleground states elect the president.

This isn’t even how the electoral college was intended to work. The framers intended that the electoral college would usually fail to choose a clear winner, instead nominating the most popular candidates for election by Congress. This hasn’t happened in over two hundred years.

Programmers have a term for something that’s neither operating as originally intended nor guaranteed to do what their users ask it to do. The Constitution is buggy.

Yet the Constitution is notoriously hard to change. A programmer might use the term legacy.

How would a programmer fix this? Find a way to hack¹ a bug fix into the legacy system.

What should the goal of the fix be? We should elect the president in the same way that every governor, mayor, senator, representative, city council member and dog-catcher² is; by popular vote. If popular vote is good enough for every single other elected office in this country and in many other democratic countries around the world, it should be good enough for the President of the United States of America.

How do we change the Constitution? Turns out we don’t have to. The founders left the allocation of electoral votes up to the states:

Each State shall appoint, in such Manner as the Legislature thereof may direct, a Number of Electors…
-U.S. Constitution

The appointment, and mode of appointment, of electors belong exclusively to the states
-U.S. Supreme Court

And the fix? The National Popular Vote Plan allocates all of a state’s electoral votes to the national popular vote winner. It only goes into effect once enough states pass it to command a majority of electoral votes. The electoral college won’t go away, but it will become obsolete. In programming terms, this plan ensures a buggy legacy system will never (again) get fed the kind of data that triggers the bug.

The National Popular Vote plan has been making its way through state legislatures for the last few years. I’ve brought it up in conversation a few times recently (because of my Visualizing the National Popular Vote plan project), and I’m surprised how many people don’t know about it. There should be a huge grass-roots movement behind this plan to re-enfranchise the electorate, but even smart, well-informed, thinking people haven’t heard of it. So please, if you agree with me and think the National Popular Vote Plan is a good idea, forward this page or NPV’s website to your friends, bring it up at parties, or support it with a donation. And if you don’t agree with me, forward this page or NPV’s website to your friends, bring it up at parties, or… well I guess I can’t expect you to support it with a donation.

Let’s get rid of this obsolete, broken, idiotic electoral college system once and for all.

1. Note to non-technical readers: Among programmers, hack generally means a quick, clever, “outside-of-the-box” solution to a difficult or intractable problem. That is the sense in which I am using the term hack here. If you think the National Popular Vote plan is about subverting or circumventing the constitution, you have misunderstood it.
2. My thanks to Hendrik Hertzberg, National Popular Vote’s bulldog, in whose writings in the New Yorker I first heard about this clever plan. I believe the inclusion of dog-catcher in this list is due to him but I cannot find the exact quote.

The existing visualization on National Popular Vote’s website was flawed enough to inspire this attempt at fixing it. They use a national map with states colored according to the plan’s progress. Using geographical visualization conflicts with the plan’s intention to make the states as entities less influential, and with the plan’s success depending on the number of electoral votes, not the geographical size or population of the states¹. And even though the steps in passing the plan suggest a spectrum, the colors are seemingly random.

Plus NPV is a good cause that deserves more attention. And as a vocal Flash critic, I should put my money where my mouth is and implement a cross-browser, scalable, interactive, vector graphic to show that it can be done without Flash.

Visualizing complex data well is challenging, and this is no exception. The plan will likely be adopted slowly over many years, so the graphic must be designed to expand. The technology must also be future-proof; I don’t want to have to re-implement the graphic, convert it to a different format, or get access to future versions of software, or the operating systems that software must run on, just to keep supporting it. This pretty much rules out Flash and Sliverlight.

These constraints make SVG² and JavaScript a good choice. SVG support is still nascent in Gecko and WebKit³ (and even Opera supports it), but the standard is pretty usable and I expect it to gain more adoption over time. All of the rendering code is in JavaScript. I’d put money on JavaScript interpreters remaining readily available ten years from now. I unfortunately have no ability (or desire, for that matter) to test this in IE with Adobe’s SVG plugin; if you try it, email me the results.

There are many different entities involved in the process: fifty states, each with two legislative bodies and a governor, and a total of 538 electoral votes; and many different events: passing the first body of a legislature, passing the second, bills passing the same body subsequent times, being signed into law, being vetoed, vetoes being overridden, and (hopefully never) laws being repealed.

The data comes from disparate sources; most comes from NPV’s website, but I had to search for the vetoes. The data is not just linear; it overlaps and interacts. A veto affects two of the charts but not the third, and a repeal would affect all three. The three charts have an order; a bill cannot pass both houses before it passes one, and cannot be signed into law before it passes both.

To include all this data, a visualization would either have to be interactive or poster-sized. This one is interactive; you can mouse over vertexes in the charts and get more information about the events they represent. You can quickly and easily find out:

• The exact progress of NPV at any time since its introduction.
• Who, what and where for any NPV-related event.
• All NPV-related events that have occurred in any particular state.
• How significant each state’s contribution to the electoral vote tally has been.
• Firsts, lasts, largests and smallests.

As with many real-world data visualizations, unexpected patterns emerge. Most activity is clustered in the winter, spring and early summer, when legislative bodies are in session. The only things that happen between August and December are vetoes. This cycle will likely become much more obvious once the graphic spans a few more years.

Hawaii’s legislature overrode their governor’s second veto, and The Governator has twice robbed the plan of California’s 55 electoral votes. Neither of these facts is obvious from the current graphic. If the plan is ever repealed, the graphic would need to show that too.

As I said in Hacking the Constitution, the the National Popular Vote plan deserves a lot more attention and support, so forward this page or NPV’s website to your friends, bring it up at parties, support it with a donation, or include the graphic on your web page.

1. If a geographical design were used on a visualization of the progress of this plan, it should at least be a cartogram.
2. The HTML <canvas> element might also have been a viable option, but I already knew SVG.
3. For a good time, try resizing the font in Safari 3.

Sebastien, your comment seems to imply that Launchpad bug reports are a waste of time. Is this really what you meant? I had been under the impression that Launchpad was intended to be a gateway/portal for bug reporting. If Launchpad reports do not get forwarded upstream automatically once triaged then what purpose does it have? -Russel Winder

and:

With all due respect Sebastien — I can hardly believe that
I’m reading this: “ubuntu only distribute it”.

(why even have a bug reporting system in the first place,
one wonders, btw.). -bjd

(That’s right, those are in response to the same Sebastien Bacher I took to task for unhelpful comments on other bugs last year.)

The bug itself isn’t Ubuntu’s fault, but the fact that the menu item survived intact in the default Ubuntu configuration despite being non-functional for (at least) the last four months speaks volumes about what passed for testing on Jaunty Jackalope¹.

Temporary workaround, until Gnome fixes this regression and Ubuntu inherits it: change the menu item to gnome-terminal -e 'sudo -i'. It took me longer to write this paragraph than to change that.

1. I’m not even going to get into how the “upgrade” process left my system unable to find the root filesystem and therefore unbootable. My memory, and a judicious application of grub-fu, saved the day, and since I’m unwilling to downgrade to Intrepid and then re-upgrade to Jaunty, this bug must remain un-duplicable and un-reported.

It begins:

Constants have been regularly proposed and rejected over the long history of CSS…

Proposals for a feature indicate that a technology (whether it be a specification or an application) has pain points that are going un-addressed. When those requests are frequent, they indicate that the person (or organization, in this case, the W3C) in charge of the technology is out of touch with its users.

…so there is no reason why constants should be useful now when they weren’t before.

This claim that constants are not useful underlies the entire essay, but Bos fails to ever really justify it. Here he wanders around in pseudo-mathematical jargon instead:

[An implementation of costants in CSS written in PHP] proves that it is not necessary to add constants to CSS…. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.

It sounds like Bos refuses to consider an implementation of variables¹ in CSS unless someone provides him with a mathematical proof of their utility. But utility is an opinion, not something that can be proven, like Turing-completeness or the irrationality of √2.

The existence of the PHP implementation Bos mentions, and of other implementations like the wonderful CleverCSS or Reddit’s vaporous C55, argues strongly that variables are useful — so useful that many people have implemented them on top of CSS. Of course, this does not prove usefulness any more than any other opinion can be proven.

Implementation effort

Next Bos considers implementation effort:

…extending CSS makes implementing more difficult and programs bigger, which leads to fewer implementations and more bugs.

Difficulty of implementation should never be a deciding factor in whether or not to address the needs of the users. This point is important enough that it bears repeating: implementation effort is not relevant when deciding what your users need.

Why not?

Technology exists to make users’ lives easier. As a technology evolves and matures, users express needs and the authors of the technology develop features to address those needs. It is the user’s needs, not easily implemented features, that drive development of a technology.

If two features serve the same need, then picking the easier-to-implement one is perfectly reasonable. And if the only way to address the users’ needs is with a feature that’s extremely difficult or impossible to implement, then a project might find itself considering whether some or all of it is still viable. But a difficult implementation is never a justification in itself for not addressing the users’ needs.

In the case of CSS, the users ask for variables because they need some way to stop repeating themselves when they encode colors, lengths, and other values in CSS.

Refusing to serve the users’ needs because the requested feature may be difficult to implement shows a lack of understanding of those users’ needs as well as poor judgment about how to handle feature requests in general.

There’s another subtle fallacy here too. When Bos worries about ease of implementation, it sounds like he’s trying to make browser authors‘ lives easier, as if they were the users that the W3C are working for. But browser authors aren’t the real users of CSS any more than, for example, the authors of a C compiler are the ultimate users of C. Web designers are the real users of CSS. They are the target audience whose needs should be considered.

Arguing from implementation effort, and talking about browser implementors instead of CSS authors illustrates how far out of touch Bos is with real web designers, doing real work.

It’s also questionable how truly difficult implementing global, un-scoped variables (or un-changing constants) in CSS would be, especially compared to other complex aspects of CSS like the cascade. But that’s a discussion for browser authors.

Maintenance of stylesheets

Next Bos argues that variables would make CSS less maintainable, not more. Bos presents two reasons that code is encapsulated behind a function in programming languages:

Dividing up a problem into smaller ones is only one reason for defining functions. Just as important is the fact that a function that fits on one screen is easier to write than one that needs scrolling.

Because CSS variables wouldn’t help divide up a problem into smaller ones or help CSS stanzas fit on the screen more easily, Bos argues, they aren’t helpful:

[Constants] would add a cost (remembering user-defined names) without a benefit (avoiding problems that are longer than one screenful).

Experienced programmers know that there’s a third benefit to encapsulating code or data behind a function, variable, or constant: not repeating yourself. This is why users keep asking for variables in CSS.  Bos goes on to say that variables would be detrimental to CSS because they would increase the length of stylesheets. However, not repeating yourself is much more important than just keeping your code short², so this point too is moot.

This section concludes:

What remains is the cost of remembering and understanding user-defined names.

Of course, stylesheets are full of user-defined class names, and CSS authors seem to have no problem using and remembering those, so it’s hard to see how user defined variable names are going to be any more intellectually challenging for CSS authors than class names.

Reusing style sheets and Learning CSS

The next two sections, “Reusing style sheets,” and “Learning CSS” continue to conjecture that user-defined variable names would be a great hindrance to using and learning CSS. But the frequency of proposals to add variables to CSS suggests they are not difficult to understand, and including them would not significantly hinder learning CSS.

But there’s not much point in arguing over such conjectures. Arguing from the point of view of a theoretical group of users who have, and lack, certain skills, is a dangerous distraction. If you have data about your users, use it. If not, collect some before making your decisions, or base your decisions on what you know your users can already do.

For the sake of argument, assume Bos’ hypothetical group of users exists. Assume there is a subset of the CSS authoring population that can comprehend the CSS cascade, relative sizes defined in ems, hexadecimal RGB color codes, and user-defined class names, but are unable to grasp the concept of a user-defined variable in CSS. (It sounds bizarre, but that’s what he’s claiming.)

These hypothetical users could just refrain from using variables in their stylesheets whatsoever. Unlike hexadecimal colors, em units, and many other aspects of CSS, nothing about variables would force CSS authors to use them. Variables could be added to the CSS standard without increasing its complexity or the effort required to learn it.

Bos also claims that user-defined variables would break easy reusability of CSS:

CSS is fairly easy to learn to read, even if some of its effects can be quite subtle. When there is a page you like, you can look at its style sheet and see how it’s done.

Anyone who has tried to copy a CSS effect from one site to another knows how difficult it truly is.  To copy the visual appearance of a single element, you must understand not only the computed style of that element, but the computed style of all of its parent elements. You need at least a rudimentary understanding of both the CSS cascade and the structure of the HTML of the page.  To copy the look of an entire page, you have to copy all of the CSS files for that page and mimic the structure of the HTML exactly, or reverse engineer the entire thing from the ground up.

Beyond the issue of whether copying CSS effects is easy or not, however, the question is whether CSS variables would make the job more difficult.

Bos points out that in-browser debugging tools help you to copy CSS by showing you the computed style. Presumably if CSS contained variables, those debugging tools would show you the values computed using those variables, not the just the variable names.

And if you were just copying a site’s HTML structure and CSS wholesale, then there’s no reason why you would even need to read the CSS or figure out what the variables mean.

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

Of course, when reverse-engineering the CSS for a site, a designer already needs to look in multiple “places at once” — they look in multiple CSS files, match class names in the CSS to names in the HTML, and consider the effects of the cascade. Is Bos really suggesting that a person capable of doing that will be incapable of finding a variable definition in the same file where that variable is used?

Rather than showing us that CSS variables would make re-using CSS more difficult, Bos asserts that a difficult, complex process is simple, and that CSS authors already performing this task are too stupid to handle a much simpler one.

Bos also claims that figuring out what variable names mean will be difficult for CSS authors — even when debugging their own code. Most CSS authors use generally descriptive class names like green-button, huge, and floatleft³. High traffic sites run their CSS (and their HTML and JavaScript) through compressors/obfuscators, but most of those sites use descriptive names internally too. It’s hard to see how CSS variables would be named any differently than CSS classes, so it’s hard to see how CSS variables would be any more difficult for CSS authors to reverse engineer or remember.

Summary

None of Bos’s arguments against variables in CSS hold up. He claims CSS doesn’t need variables, but fails to recognize  CSS authors’ true need to avoid repeating themselves. He argues CSS variables would be too difficult to implement, but implementation difficulties are invalid grounds to justify leaving users’ needs unaddressed. He argues that CSS variables would add too much complexity to CSS and no benefit whatsoever, but overlooks a key benefit that CSS variables would provide. All his arguments about the complexity variables would allegedly add to CSS are difficult to accept given the current complexity of CSS.

A feature request is a need in disguise, and multiple, persistent feature requests indicate a serious need behind a very thin disguise. Rather than arguing against a feature, you should endeavor to understand the underlying need. Rather than arguing from implementation complexity, you should decide whether that need must be addressed. Rather than arguing from hypothetical, invented users, and speculating about complexity, you should collect real user data or look at the kinds of tasks your users already handle.

This entire article⁴ calls into question Bos’ ability (and, by association, the W3C’s) to identify and address the needs of real CSS users and choose features to solve real shortcomings of CSS. I hope my analysis of this article helps other technologists learn to understand and address their users’ real needs better, and avoid poor reasoning when arguing against, or for, a specific feature.

For more on problems with CSS, see CSS Considered Unstylish.

1. For brevity I’ve chosen use just the term variable throughout this article, even though all the points I make apply equally well to constants.
2. Bos’ point about the “computer screen becoming an extension of the programmer’s memory” is bizarre in the extreme. Even the best programmers or web designers will quickly end up with a program or stylesheet that’s bigger than will fit on a screeen, when working on anything but the most simple projects, if for no other reason than the project being split up into multiple files.
3. Perhaps Bos does not always use descriptive class names; The stylesheet for his article uses the class names yves and coralie.
4. The very end of the article has a clever suggestion: that constants be implemented as an external module. I’m not sure how this would work, but if it meant that a single set of constants for a site would be accessible in the HTML, and all of the site’s stylesheets, and maybe in the JavaScript too, well, that would be pretty cool.

The relational database is an extremely powerful tool. But sometimes data isn’t very relational, and sometimes transactional, relational, integrity is not as important as it is for, say, a bank. This is one reason why so many sites can get away with mySQL backed by myISAM tables — they’re fine if you’re read-heavy and data integrity is not mission-critical.

Some new projects have sprung up which provide key-value stores or simpler kinds of databases without all the overhead and inflexibility of a relational database.

On the other hand, sometimes data is way more interrelated than a traditional relational database is prepared to handle. Sometimes different kinds of items (i.e. rows) in a database can be related to many other kinds of items in that database, and sometimes end users can create not just new items or new relationships, but new kinds of relationships between items. This type of database is called a graph database, and there are also projects pushing the boundaries of relational in this completely opposite direction.

Pretty much everywhere I interviewed back in February 2008 was either building their own graph database, working on an existing one, or repurposing a relational database (or, in one case, a search backend), to kinda, sorta behave like one. The w3c, not one to be left behind when there’s a specification to be written, is even working on a SQL-inspired query language intended to search them¹.

Most applications have some combination of totally un-relational data that can go in a key-value store, some strictly relational data that belongs in a SQL database, and some flexible, highly relational data that belongs in a graph database.

What will happen when these alternative databases start giving traditional relational databases a run for their money? Well, sharding, caching, and normalization all start to sound a lot more complex when the data is in a few different kinds of databases — but then again, maybe optimization won’t be as necessary if a single SQL database isn’t doing all the heavy lifting. Object-relational mappers (and the web frameworks that use them) might need to talk to, and abstract away from, different kinds of databases².

And the different types of data won’t always be easily separated along table boundaries. Maybe these different types of databases will talk to each other, or maybe they will mature into über-databases that understand lots of different types of data relationships.

But the monolithic, strictly relational, master SQL database is eventually going to go the way of Cobol³.

1. Of course, if it’s anything like other technologies designed by the w3c, it’s a steaming pile.
2. Some can already handle talking to multiple SQL databases, and of course there’s two-phase commit.
3. Or Kobol.