4 ms·

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

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

by Lozzer 18y ago

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.