Ignore your users’ needs. Call them stupid instead.

This is an ass-backwards blog post. Web standards aren't simply a "product" used by web developers. Every feature added to a popular standard is a tax on every compliant implementation. It is absolutely a valid engineering question to consider whether something is best accomplished in the standard, or in application layers built over the standard.<p>Indeed, instead of Bos ignoring this guy's argument, it seems to me it's the other way around. The standards body's response to "add variables to CSS" is "why? that's an application-layer concern, easily handled by any web development framework, which has nothing to do how browsers actually process style information". The onus <i>is</i> in fact on the advocates of extending CSS to explain why this feature is so important browsers should be required to implement it.<p>It's also just bad engineering to add features at lower layers that are just as effectively handled at higher layers. The end to end argument in systems design doesn't just apply to network protocols.

&#62; Difficulty of implementation should never be a deciding factor in whether or not to address the needs of the users.<p>Really?<p><i>Never</i> ?<p>I've got to disagree with this.<p>All possible changes that one might make to a codebase should be evaluated in terms or ROI (return on investment).<p>If a 1 day project creates X value, and a 3 day project creates 5 X value, then the latter project delivers more bang for the buck, and that's where resources should be allocated.<p>To ignore the amount of work that a task takes is to blind oneself and discard rationality.

Variable/constant names aren't just used to keep DRY, and to encapsulate functionality. They're also used to express <i></i>intent<i></i>. To me, this is one of the most important reasons for using variables, instead of "magic numbers".

The author's postscript was the most interesting part of the article for me. If there were some extra kind of document (defined in JSON, perhaps) that could be attached to an HTML document to supply definitions that would be entered into the DOM, it could be accessed natively from Javascript, and also inserted into the HTML and CSS standards with much less tweaking than a whole separate variable standard just for CSS. For example, it would be possible to simply extend the concept of HTML entities into "DOM entities", which could then be copied wholesale by CSS for a nice symmetry: you'd be able to use &#38;(document.variables.foo); in both mark-up languages and have be replaced with the value of the DOM node document.variables.foo. (Actually, you could extend this even further, and just allow arbitrary inline JS in these DOM entities, which gets parsed as the value after their evaluation: &#38;(document.variables.foo + 1). You could also avoid document.variables altogether, if you wish, and just set use &#38;(1 + 1); or &#38;(document.body.style.background-color); or anything else you like. Let's, therefore, call them <i>JS Entities</i>.)<p>The only big design decision would be whether to allow writing to document.variables from JS (or, to rephrase, whether to parse the JS entities permanently upon recognition into their textual values before parsing can continue, or to have them continue to exist as a special kind of DOM node—though rendered as their current textual equivalent—that will reflow the document if their dependent values are altered.)<p>If JS entities aren't parsed away, it would change the way we interact with the DOM entirely—we probably wouldn't bother defining any constants in CSS itself any more; we'd just inject them. It would reverse the data-flow between Javascript and mark-up, even beyond how much AJAX already has: we wouldn't need to set specific things in the DOM, but instead just have those DOM nodes be an observer of our actual, working value. For example, "document.body.styles.background-color = document.createVariableElement(spinner.color);" as a line of Javascript would make the background-color of the page "watch" the current value of the spinner. In fact, if this method were used, you technically wouldn't <i>need</i> a separate variables.json document, because you could just dynamically create all the JS entities <i>in</i> JS (which is probably how it should be.) However, you could create one on top of JS entities, if you wished, using a library.