4 ms·

I have definitely thought about the convenience of variables before, but it isn't good to bloat CSS itself with them. The spec's examples like "CorporateLogoBG

I have definitely thought about the convenience of variables before, but it isn't good to bloat CSS itself with them. The spec's examples like "CorporateLogoBGColor" could be handled by a simple tool that generates CSS. The simplest case is a preprocessor-like input/output scheme. For example, a script (in a complete language with real variables, functions, etc.) and a template file (with references). That way, there's separation of responsibility. The browser doesn't have to be more complex, risking bugs and exploits and slowdowns, because the "requirement" for variables isn't really there. What usually happens after someone adds "variables", is somebody says hey, we need functions too. And arithmetic. And oh wait...now it's a full-fledged language. Oops...

DaniFong 18y ago
Why is a fully fledged language a bad thing, in this case?
- olavk 18y ago
  The Rule of Least Power: http://www.w3.org/2001/tag/doc/leastPower.html http://www.w3.org/2001/tag/doc/leastPower.html
Lozzer 18y ago
I agree that the examples could be done with preprocessing a template, but I'd like to be able to simple arithmetic in the CSS file, just for the ability to mix relative and absolute units without kludging in extra divs. For example: left: 20% - 20px; I wish I'd written down some of the times I'd wanted to do something like that so I could point to a specific example. The obvious one of centering a fixed width image can be done with auto margins (though I've a feeling that didn't work in IE6).
- makecheck 18y ago
  That is a pretty good example, actually. Yes, if it is an expression whose value cannot be known until the browser figures it out, then there could be value in having CSS support it. But JavaScript supports dynamic lookup of style information, and has math expressions. It may be that CSS is still the best place for such an enhancement, but the trick is to always look for the best place to make these changes. Would a JavaScript onLoad script like "page.styles['x'].margin.left = page.width_in_pixels()*0.20 - 20" be as good, better or worse? I'm not even sure myself.
  - Raphael 18y ago
    It's just a matter of convenience and taste. CSS is for presentation and JavaScript is for behavior.
    - IsaacSchlueter 18y ago
      You could argue that a taste for convenience is a pretty good definition of a quality developer ;)
  - IsaacSchlueter 18y ago
    There are a few problems with doing that, in my experience. First, from a theoretical point of view, Javascript is an functional language. That's ideal for expressing event-driven behavior. Not so great for expressing style information. It's the difference between saying, "When you walk in the room, look at the wall, and see that it is red" vs saying "The wall is red." Style information is best expressed in a declarative rule-based syntax. Second, from a practical point of view, CSS and JS are loaded and run in different ways by the browser. CSS, being a declarative rule-based language, can be loaded up ahead of time, and applied to the DOM all in one go. Javascript must be parsed and evaluated, and respond to changes dynamically. Great for click events, not so great for specifying FAC and layout. Third, from a maintainability point of view, even when it perhaps makes some sense to set styles dynamically in Javascript (ie, DHTML), it's usually better to have the JS modify a className and put the style rules in a CSS file. To the browser, it makes no difference. But to the next programmer dealing with your code, who's wondering where a particular style is coming from, it makes it a lot easier to fix bugs. This is the "don't put canned goods in the fridge" rule. Sure, it doesn't hurt the refrigerator or the can of soup, but you'll go a little crazy every time you look in the cupboard and can't find it. That being said, the CSS/JS divide is far from conceptually or practically perfect. CSS already has a bunch of event-driven hooks (:active, :focus, :hover, etc.), and there are some cases where you simply must modify the HTMLElement::style object. But like everything else in a web page, there's a trade-off, and the rules of thumb are there for a reason. Know them well, so that you can know when and why it's appropriate to break them.
IsaacSchlueter 18y ago
>could be handled by a simple tool that generates CSS. Not quite. Check the bits about changes to the DOM interfaces. You can get and set variables via Javascript, and the styles of the page will all update as a result. That's powerful and useful. It is a bit of a slippery slope. But it's hardly as bad as expression() ;) Variables don't change the fundamental nature of CSS as a declarative rule-based language, and in my opinion at least, it's a pretty good fit. But it also doesn't address the biggest problems with CSS. I wrote about 5 of them here: http://foohack.com/2007/10/top-5-css-mistakes/ http://foohack.com/2007/10/top-5-css-mistakes/ but I forgot the worst one of all. The 12 billion keywords. I'm not sure how that would have been done differently, since any declarative language is bound to have a big vocabulary, but I've seen so many novice webdevs struggle with remembering what does what. A good editor with auto-complete helps, but it's still a pain.

DaniFong 18y ago

Why is a fully fledged language a bad thing, in this case?

olavk 18y ago
The Rule of Least Power: http://www.w3.org/2001/tag/doc/leastPower.html http://www.w3.org/2001/tag/doc/leastPower.html

Lozzer 18y ago

I agree that the examples could be done with preprocessing a template, but I'd like to be able to simple arithmetic in the CSS file, just for the ability to mix relative and absolute units without kludging in extra divs. For example: left: 20% - 20px; I wish I'd written down some of the times I'd wanted to do something like that so I could point to a specific example. The obvious one of centering a fixed width image can be done with auto margins (though I've a feeling that didn't work in IE6).

makecheck 18y ago
That is a pretty good example, actually. Yes, if it is an expression whose value cannot be known until the browser figures it out, then there could be value in having CSS support it. But JavaScript supports dynamic lookup of style information, and has math expressions. It may be that CSS is still the best place for such an enhancement, but the trick is to always look for the best place to make these changes. Would a JavaScript onLoad script like "page.styles['x'].margin.left = page.width_in_pixels()*0.20 - 20" be as good, better or worse? I'm not even sure myself.
- Raphael 18y ago
  It's just a matter of convenience and taste. CSS is for presentation and JavaScript is for behavior.
  - IsaacSchlueter 18y ago
    You could argue that a taste for convenience is a pretty good definition of a quality developer ;)
- IsaacSchlueter 18y ago
  There are a few problems with doing that, in my experience. First, from a theoretical point of view, Javascript is an functional language. That's ideal for expressing event-driven behavior. Not so great for expressing style information. It's the difference between saying, "When you walk in the room, look at the wall, and see that it is red" vs saying "The wall is red." Style information is best expressed in a declarative rule-based syntax. Second, from a practical point of view, CSS and JS are loaded and run in different ways by the browser. CSS, being a declarative rule-based language, can be loaded up ahead of time, and applied to the DOM all in one go. Javascript must be parsed and evaluated, and respond to changes dynamically. Great for click events, not so great for specifying FAC and layout. Third, from a maintainability point of view, even when it perhaps makes some sense to set styles dynamically in Javascript (ie, DHTML), it's usually better to have the JS modify a className and put the style rules in a CSS file. To the browser, it makes no difference. But to the next programmer dealing with your code, who's wondering where a particular style is coming from, it makes it a lot easier to fix bugs. This is the "don't put canned goods in the fridge" rule. Sure, it doesn't hurt the refrigerator or the can of soup, but you'll go a little crazy every time you look in the cupboard and can't find it. That being said, the CSS/JS divide is far from conceptually or practically perfect. CSS already has a bunch of event-driven hooks (:active, :focus, :hover, etc.), and there are some cases where you simply must modify the HTMLElement::style object. But like everything else in a web page, there's a trade-off, and the rules of thumb are there for a reason. Know them well, so that you can know when and why it's appropriate to break them.

IsaacSchlueter 18y ago

>could be handled by a simple tool that generates CSS. Not quite. Check the bits about changes to the DOM interfaces. You can get and set variables via Javascript, and the styles of the page will all update as a result. That's powerful and useful. It is a bit of a slippery slope. But it's hardly as bad as expression() ;) Variables don't change the fundamental nature of CSS as a declarative rule-based language, and in my opinion at least, it's a pretty good fit. But it also doesn't address the biggest problems with CSS. I wrote about 5 of them here: http://foohack.com/2007/10/top-5-css-mistakes/ http://foohack.com/2007/10/top-5-css-mistakes/ but I forgot the worst one of all. The 12 billion keywords. I'm not sure how that would have been done differently, since any declarative language is bound to have a big vocabulary, but I've seen so many novice webdevs struggle with remembering what does what. A good editor with auto-complete helps, but it's still a pain.