Ignore your users’ needs. Call them stupid instead.(glyphobet.net)
glyphobet.net
Ignore your users’ needs. Call them stupid instead.
http://glyphobet.net/blog/essay/587
4 comments
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?
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?
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.
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.
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.
"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.
It's a lot easier to implement this on the server side than to try to get compatibility between the various browsers (especially Internet Explorer). A server-side implementation is also compatible with older browsers, which is a concern that would prevent CSS variables from coming into common use for a long time.
It's not just about the effort for browser developers. It's also about the effort of getting all the browsers in use to be more-or-less compatible with the standard.
It's not just about the effort for browser developers. It's also about the effort of getting all the browsers in use to be more-or-less compatible with the standard.
> 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.
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.
That may be true for a particular solution. If a solution doesn't make sense in ROI, then the solution should be rejected.
However, if the customers have a specific pain point, our jobs are to alleviate that pain, not sit around and say, "It's too hard."
However, if the customers have a specific pain point, our jobs are to alleviate that pain, not sit around and say, "It's too hard."
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.
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?
In your example you are deciding between delivering two different valuable improvements, which is fine. Bos' is deciding to do nothing just because the one solution presented to him might be hard. That's inexcusable.
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".
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.
The question isn't whether to implement higher-level stylesheets. It's where to implement them.
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.
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.
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.