I'm really afraid of CSS having too much logic and driving designers away. I don't want to go back to the days when designers mocked up in Photoshop and had devs (inferior designers) do the CSS.
I'm a designer and I just finished moving our product form CSS to Less.js (server-side preprocessed). This allowed me to define variables such as @baseColor, @buttonColor etc. so that the developers working on the project can use those instead of copy/pasting colours from other places and making a huge mess.
Variables are not logic. Once CSS seizes being declarative and starts becoming a programming language, I think we might start seeing problems, but the author is not suggesting adding an if-statement to CSS (one might argue that media queries are already conditional enough).
You make a good point, but real designers know how to code (at the very least HTML/CSS). I'd consider any veteran designer who tells you they're "frightened by code" to not be worth it. Perhaps new concepts like variables will just be natural selection for the front-end.
1) is able to write valid cross-browser CSS ready for deployment without developer tweaking
2) would not understand basic logical constructs such as CSS Constants.
does not, in fact, exist. At least, I have never met one.
Think of it like this, imagine there is a sort of spectrum for capability of abstract logical/mathematical related thought. Roughly, on one extreme end there's someone who is so intuitive practical you wouldn't trust to properly split a dinner bill (this is not a "designer stereotype" btw, but an example of the very extreme end of the scale), in between there's doing calculations, solving simple equations, writing CSS, writing CSS-with-constants, using a templating language, doing actual coding, hardcore coding genius, and at the far end there's Neo who can stop bullets with his mind by wearing the right kind of shades and longcoat.
Your fear of "having too much logic and driving designers away" is only valid if the majority of web-designers fall right between "capable of writing CSS" and "capable of writing CSS with constants". Sorry but that's a rather narrow range and I'm not buying it.
And the few designers that happen to fall exactly in that range will either have to write CSS without constants (which is fine), or learn to deal with it.
I'm not saying that this is the spec that pushes CSS into the code-territory. I'm not saying there is any one spec that does. I'm looking at the aggregate of CSS4 and am afraid that we are heading in that direction. See, for example, the crazy (and awesome, btw) things you can do in upcoming selectors such as matches[1] combined with a for[2], or the mind-bender that is the shadow dom[3].
I think the more important reality is that TIMTOWTDI doesn't really belong in CSS, and that's what we're seeing happen more and more.
Part of the problem is that CSS And rich internet applications can't really properly coexist - they do now, because that's part of how we work, but as time goes on the amount of lifting we're going to want to do with JavaScript is only going to continue to increase.
Does W3C publish a rationale for each spec? I searched the Shadow DOM spec for the word "rationale" and found nothing, the abstract didn't say why the spec is useful, and the TOC didn't seem to list a justification section.
Reading the Introduction section, I get the impression that Shadow DOM is supposed to help with creating widget-based UIs, but if we're at that point, why are we still using the text/document-focused DOM instead of creating a new abstraction that is better suited for UI (though the insertion point concept looks potentially useful)?
I agree with you in principle about the abstraction issues in CSS, however I would submit that CSS constant's contribution to the problem is negative. It simplifies real-world CSS to have constants, and this has frankly been obvious for about 15 years now.
As for the rest of CSS, I've really been rolling around to "just create a canonical JS binding and be done with it"; it's headed headlong into the Turing Tarpit and as long as it's going to end up there one might as well use a language designed to live in it.
I agree. I really think it's practically impossible to be capable of writing CSS and still have difficulty understanding CSS constants. The whole idea of CSS is that instead of declaring your style inline over and over again, you declare it in one place and then apply it to an entire class of layout element.
Every concept that is part of "constant" is fundamental to understanding CSS in the first place.
If something as simple as a variable scares you then I am guessing you have no hope in hell with dealing with a bit of jQuery, let alone Javascript.
Welcome to the real world. It's time to upskill.
Side note: Developers may be inferior designers, but that does not make them inferior coders, since by their nature, that is what they do day in, day out. I am not a designer, I am not a front end guy, but my html/css/javascript is a lot better quality and reusable than I have seen come out of any design agency. We won't even go into having any consideration of the selectors they use and any rendering speed they may have...
I'm afraid of the same thing, but not because it will drive away designers, but because CSS is meant to be, and is most powerful as a declarative language.
What CSS really needs is an actual layout module in the specification (instead of the hacks we still use to this day to execute the most simple of layouts).
With all that said, I do think variables are a great idea.
I really don't see how this would have a major negative impact on speed. If anything, it will allow CSS files to be smaller reducing the amount of data being downloaded to the client and may actually improve performance.
It makes no difference, these are proposal for constants so it's trivial substitution. Furthermore by avoiding repeating the same value over and over again CSS variables likely reduce the file's size.
If they act in a similar way to variables in SASS, then they can be reassigned without issue. They are not constant, although they may be treated as such.
Of course, the CSSWG will no doubt create a solution that is both absurd in it's complexity, and limited in it's use. For example, constants defined with css-constant('foo', 'bar') instead of $foo: bar
> For example, constants defined with css-constant('foo', 'bar') instead of $foo: bar
The issue with sigil is that they risk conflicting with (and making more complex the parsing of) selectors. `$` used to be coopted by the Selectors Level 4 draft spec in order to select a non-tail subject for instance (it's apparently been changed to the `!` suffix).
Not that I like what they picked any more than you do (the spec is currently using the `data-` prefix for definition and `data()` for dereference, likely in keeping with HTML5's `data-` attributes)
It's W3C, what were you expecting? It's the very best example of death-by-committee I've ever seen. If they designed a lightbulb, it'd require a 9 step checklist just to get it out of the packaging, wouldn't fit in the industry-standard socket (because, of course, they've reinvented the wheel again, poorly), and by the time you actually got the thing installed the rest of the world will have moved on to better light-producing devices, but will be forced to deal with the W3C brain-damaged version of the lightbulb because it's a "standard".
I think future Web standards should take out the Gecko/Chrome/IE layout+parsing engine and make it a separate library. Standardize a minimalistic (but powerful) GL-style presentation API.
Why are standards committees dictating developer workflow? We should be able to swap in our own parser and UI framework (which is what DOM is) that fits the specific website/webapp needs best. Not reinventing the wheel, of course - things would naturally coalesce into ubiquitous standard libraries, but a bit more competitively.
This wouldn't make css any more powerful than it can be when treated as a compilation target. You can get all the logic you need in a preprocessor embedded in another language, e.g for js I made this: http://github.com/twfarland/son
New styling possibilities would be more interesting, e.g layer blend modes.
31 comments
[ 3.4 ms ] story [ 113 ms ] threadVariables are not logic. Once CSS seizes being declarative and starts becoming a programming language, I think we might start seeing problems, but the author is not suggesting adding an if-statement to CSS (one might argue that media queries are already conditional enough).
I'm a designer, by the way.
The proper name for a web designer who can't write HTML+CSS is "artist".
1) is able to write valid cross-browser CSS ready for deployment without developer tweaking
2) would not understand basic logical constructs such as CSS Constants.
does not, in fact, exist. At least, I have never met one.
Think of it like this, imagine there is a sort of spectrum for capability of abstract logical/mathematical related thought. Roughly, on one extreme end there's someone who is so intuitive practical you wouldn't trust to properly split a dinner bill (this is not a "designer stereotype" btw, but an example of the very extreme end of the scale), in between there's doing calculations, solving simple equations, writing CSS, writing CSS-with-constants, using a templating language, doing actual coding, hardcore coding genius, and at the far end there's Neo who can stop bullets with his mind by wearing the right kind of shades and longcoat.
Your fear of "having too much logic and driving designers away" is only valid if the majority of web-designers fall right between "capable of writing CSS" and "capable of writing CSS with constants". Sorry but that's a rather narrow range and I'm not buying it.
And the few designers that happen to fall exactly in that range will either have to write CSS without constants (which is fine), or learn to deal with it.
[1] http://dev.w3.org/csswg/selectors4/#matches [2] http://dev.w3.org/csswg/selectors4/#idref-combinators [3] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...
Part of the problem is that CSS And rich internet applications can't really properly coexist - they do now, because that's part of how we work, but as time goes on the amount of lifting we're going to want to do with JavaScript is only going to continue to increase.
Reading the Introduction section, I get the impression that Shadow DOM is supposed to help with creating widget-based UIs, but if we're at that point, why are we still using the text/document-focused DOM instead of creating a new abstraction that is better suited for UI (though the insertion point concept looks potentially useful)?
As for the rest of CSS, I've really been rolling around to "just create a canonical JS binding and be done with it"; it's headed headlong into the Turing Tarpit and as long as it's going to end up there one might as well use a language designed to live in it.
Every concept that is part of "constant" is fundamental to understanding CSS in the first place.
Seeing something like #046e08 everywhere scared me much more as a new developer than something as simple as "let green1 = #046e08" would have.
It merely makes maintenance much, much easier.
Welcome to the real world. It's time to upskill.
Side note: Developers may be inferior designers, but that does not make them inferior coders, since by their nature, that is what they do day in, day out. I am not a designer, I am not a front end guy, but my html/css/javascript is a lot better quality and reusable than I have seen come out of any design agency. We won't even go into having any consideration of the selectors they use and any rendering speed they may have...
What CSS really needs is an actual layout module in the specification (instead of the hacks we still use to this day to execute the most simple of layouts).
With all that said, I do think variables are a great idea.
Unless maybe you are living in the 80s and using a Spectrum 48k?
Speed. Christ.
It makes no difference, these are proposal for constants so it's trivial substitution. Furthermore by avoiding repeating the same value over and over again CSS variables likely reduce the file's size.
Of course, the CSSWG will no doubt create a solution that is both absurd in it's complexity, and limited in it's use. For example, constants defined with css-constant('foo', 'bar') instead of $foo: bar
The issue with sigil is that they risk conflicting with (and making more complex the parsing of) selectors. `$` used to be coopted by the Selectors Level 4 draft spec in order to select a non-tail subject for instance (it's apparently been changed to the `!` suffix).
Not that I like what they picked any more than you do (the spec is currently using the `data-` prefix for definition and `data()` for dereference, likely in keeping with HTML5's `data-` attributes)
See also Variable (mathematics) [1] vs. Variable (computer science) [2].
[1] https://secure.wikimedia.org/wikipedia/en/wiki/Variable_%28m... [2] https://secure.wikimedia.org/wikipedia/en/wiki/Variable_%28c...
http://dev.w3.org/csswg/css-variables/
Why are standards committees dictating developer workflow? We should be able to swap in our own parser and UI framework (which is what DOM is) that fits the specific website/webapp needs best. Not reinventing the wheel, of course - things would naturally coalesce into ubiquitous standard libraries, but a bit more competitively.
New styling possibilities would be more interesting, e.g layer blend modes.