

Ignore your users’ needs. Call them stupid instead. - glyphobet
http://glyphobet.net/blog/essay/587

======
tptacek
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.

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 _is_ in fact on the advocates of extending CSS to
explain why this feature is so important browsers should be required to
implement it.

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.

~~~
Confusion
If their response is 'why', then the blogger is completely right and the
standards body has no clue how the technology that the standard prescribes is
used. The 'why' is simple, even if we only look at colors: every stylesheet
contains the same colorcode over and over again, because good design requires
coherent use of colors. Now you could make a style class called 'green', but I
don't think I should have to go into the reasons why you just do not _ever_
bloody want that. A proper stylesheet is bound to repeat a colorcode. A second
solution is generating your CSS, but then you need a new standard defining a
proper way to tell your CSS generator which elements should have the same
color, which pretty much ends up being CSS _with variables_.

If they, and Bos, have any clue about what they are doing, they should tell us
how to solve this problem, instead if asking the inane question you put in
their mouths. What Bos comes up with in his essay is basically 'search-and-
replace' and other 'tooling'. Well, why don't we just drop variables in our
programming languages as well? We can just 'search-and-replace', can't we?

~~~
tptacek
Because your programming language is a programming language, and CSS isn't?
There's no part of this feature that couldn't be accomplished using a CSS
templating system. You might as well ask why HTML5 doesn't include all the
features of Cheetah or Erb.

~~~
Confusion
A CSS templating system, that is just CSS extended with the possibility of
symbolic constants, adding an extra step to the build process. One
implementation I've seen used is using ant to replace the constants by their
values. It's not hard, but that's exactly the point: it's also simple for
Microsoft, the Mozilla Foundation, the KDE project, Apple, etc. to implement.
I agree you shouldn't start adding real variables whose value can change
halfway the CSS, variable scoping or, god forbid, if-then constructs. That
doesn't mean simple constants should also be ruled out. I think that's
throwing out the baby with the bathwater.

~~~
tptacek
I'm not sure I see why:

 _"adding another step to the build process"_

is worse than

 _"permanently standardizing one group's notion of what variables should look
like when less than 1% of all web applications use any form of CSS templates"_

I don't have to agree with Bos that high-level stylesheets are a bad idea (I
don't; I think they're a great idea) to agree with him that we shouldn't be
inflicting them on everything that renders or interprets styled HTML.

And hey --- for what it's worth --- I can see how Bos didn't do his argument a
big favor by writing an essay-length rant about why variables are a bad idea.
I think he raises some good points. For instance, have these proposals really
thought scoping through, and have we really thought about how this will impact
authorship tools? But these aren't the reasons we shouldn't be in the business
of standardizing the idea.

On the other hand, Matt's argument is just as wrongheaded. It is absolutely
_not_ the case that standards groups should be rushing to alleviate web
developer pain. Like I said, if they took that approach, we'd be stuck with
QuickSilver templates, baked permanently into the HTML standard.

------
tjic
> Difficulty of implementation should never be a deciding factor in whether or
> not to address the needs of the users.

Really?

 _Never_ ?

I've got to disagree with this.

All possible changes that one might make to a codebase should be evaluated in
terms or ROI (return on investment).

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.

To ignore the amount of work that a task takes is to blind oneself and discard
rationality.

~~~
stevejohnson
Sure, the generalized statement is a bit iffy, but in this case, the number of
users, ease of implementation, and utility of the feature make the lack of
constants inexcusable. Bon's argument sounds pretty silly.

~~~
tptacek
Explain to me why we should be stuck with one standards group's idea of how to
organize style information, when an app-layer implementation of the same idea
imposes no cost to end users, adds flexibility, and doesn't force the whole
web to rush to standardize an idea that sees less than 1% adoption among all
web apps today?

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

~~~
tptacek
Stylesheet variables are a very good idea, but just as a reminder, the
validity of the idea isn't _really_ the question here, even if Bos makes some
good points (particularly regarding the fact that the extension will break a
whole constellation of authorship tools).

The question isn't whether to implement higher-level stylesheets. It's _where_
to implement them.

------
derefr
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
&(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:
&(document.variables.foo + 1). You could also avoid document.variables
altogether, if you wish, and just set use &(1 + 1); or
&(document.body.style.background-color); or anything else you like. Let's,
therefore, call them _JS Entities_.)

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.)

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 _need_ a
separate variables.json document, because you could just dynamically create
all the JS entities _in_ JS (which is probably how it should be.) However, you
could create one on top of JS entities, if you wished, using a library.

