I just want to correct some incorrect assumptions about how it works.

It doesn’t process it every time, it only will process if the css stylesheet has changed, and there is a command line compiler so you can precompile everything.

The PHP version actually is built to the same spec that the webkit version is, the stylesheets are interchangable. I implemented it this way so that when browsers catch up, those stylesheets would be usable without change.

The one difference between my implementation and the spec, however, is that I have an eval() that lets you do stuff like:

padding: eval(variable / 2);
margin: eval((anothervariable / 2) * yetanother);

Honestly, I don’t give a shit if people use it or not, we use it at massify.com and have found it an incredible boon to productivity in regards to how we build some very complicated pages and keep consistency across the entire site. YMMV.

Best,

Jon.

I like your idea. An inheritance possibility in CSS would make everything easier. I have been thinking about this as well. However, let’s call this pseude attribute import, merge, use or mixin. Caling them classes or 00 inheritance in CSS often confuses people because they think that you want to implement complex OOP concepts whereas we only want to achieve something simple: namely, the overlay/overwrite (top-down) of CSS class attributes using a CSS selector for a different CSS class in a CSS document.

Many people say that we already have this in CSS, which is basically true (whitespace seperated class name list). However, the inheritance definition is shifted from the CSS document into the HTML document. Which means that, if I want to achieve a relatively strong abstraction of CSS styles in CSS, I have a long list of class names in the HTML document element class attricute. Firstly, the document gets too large and secondly, one always has to remember the whole chain of the inheritance hierarchy.

Especially the latter causes lots of trouble. We have two or more people working on the CSS/HTML at the same time, and each of them needs to have a good overview of the CSS definitions and has to speak often to the other developers, otherwise, they define things twice which is unnecessary. In large projects, it is almost impossible to keep a clean CSS in the long run.

On the other hand, you would put the inheritance (merge, mixin, import) back into the CSS document if you worked according to the blackbox principle as a developer. I only have to know the base classes (definitions), I can import/mixin/merge this base class to my new class and overwrite only the necessary attributes in this new class. In the end. I only have to know thes one new special style class and I can hand it over to other develpers. Then, they can overwrite the class again. furthermore you achieved an improved recycling of style definitions.

I hope all cann follow me. I’m not a native english speaker.

Your 3 last link are really just disputing the role of CSS as a layout language… which is an old debate that basically comes down to columns. It always seems accompanied with a nostalgia for the old days of table layouts. Table design is a failure. There is room for bringing columns to CSS, it just needs to get implemented.

In any case the people who have a problem with CSS for layouts usually want to add another layer of tech… which does nothing to bring all the “mental eggs in one language basket” as you say.

Getting back on topic.
It seems to me (I may be wrong) that the main request for CSS constants (or variables) comes from app builders who want a more dynamic CSS for their widgets and apps. I get that, but it’s very specific. It gets even more specific when you realize most of them are talking about colors and nothing else. In fact in most cases, you could use constants to accomplish the same thing.

As I was saying earlier, most browsers support the “named colors” and “system colors”. The W3C refers to them as keywords.
http://www.w3.org/TR/CSS21/syndata.html#keywords
“A is either a keyword or a numerical specification.”

What would be cool is if you could declare your own “keywords”.
I can already go:
.myApp{color:redbrick;}
.myApp{background:ButtonFace;}

so why not simply allow me to do:
@colors{myAppBasetone:#FF0099;}
.myApp{background:myAppBasetone,#F09;}

(notice the “font-family style” backup color)
This is something they could add to SVG & Canvas as well.

I realize that stylesheets are collections of queries, and as such, perhaps the “inherit” statement should allow the use of another selector, rather than a “class definition” as I called it earlier. This has a large potential for abuse, but a large potential for proper usage. It would run something like this:


.myBaseSelector
{
color: white;
}

Really, css variables are the cleanest solution to the problem of reusable style definitions. Why is that such a hard concept to grasp?

I’m not saying we should run back to the original specification of JSSS, but I think the current concept has too many flaws, and too much complexity already. I don’t want to get off topic, so here’s a few links that describe the problems pretty well I think:

http://www.cybergrain.com/archives/2004/12/css_considered.html
http://www.accidentalscientist.com/2007/07/css-sucks-for-layout.html
http://www.nczonline.net/blog/2007/10/8/css_sucks
http://gui.net/blog/2006/12/15/why-css-sucks/
…and the list goes on

@Joeri: Well, we are doing it, or at least we should be. We can only serve static CSS content, so I really don’t see any reason to dynamically generate a different stylesheet for every page. The YSlow performance tips go into the details fairly well.

As for aliasing, like take mentioned (e.g. CustomRed = #ff0010), it can be pre-processed and cached fairly easily… The code to do it with PHP is just a dozen of lines long, if that.

@ialexi: you’re right, OOP-style inheritance isn’t possible in CSS because it’s not a object oriented language in the first place. Stylesheets are a bunch of queries, and the objects to which the queries apply live in the HTML. I consider CSS much more similar to SQL UPDATEs than to Java.

However, I disagree at the point you said “it’s common to have 3000 lines of CSS code”; I’m doing nice / responsive / complete sites using less than 400 (the site that is opened right now on my Dreamweaver’s window have less than 200) lines.

Your site’s complexity / size might not be (and very, very often, isn’t) proportional to the amount of CSS styles you have to write.

@tlrobinson:
You’ve got this phrase out of it’s context. The complete paragraph says:

“The other implementation is written in PHP. It proves that it is not necessary to add constants to CSS. Just like the existence of the WebKit implementation cannot be taken as proof that constants in CSS are useful, so the PHP implementation cannot prove that either. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.”

BTW, LOL, hyperbolic example.

How much similarity is shared between a language resource and programming languages from completely different levels you see?

This is a ridiculous claim. It’s like saying there’s no use for higher level programming languages (or CSS for that matter) because I can just write assembly.

Damn XHTML strip.

IMO, no matter how pretty could be that so-beloved / so-hated CSS “vars”, it would introduce problems more related with programming, rather than styling (like var scope, fallback behavior, undefined vars, etc).

And, also, these vars are a requirement that comes only from a small part (IMO) of web developers / designers / whatever. You can use, currently – without worrying about when will incorporate a new CSS capability, things like

.my-pretty-class{color:red;}
.asd{background-color:white;}
.dsa{background-color:orange;}

I’m red
Me too

If you really need an universal property.

Still, I take back a bit of what I said regarding inheritance earlier. My biggest problem with CSS variables is that they appear to be declared in some sort of global scope, and to me, this seems to be a big no-no. I liked the idea of inheritance because it would allow a much more organized way of storing variables.

An even more organized way, however, could be very simple in concept. Imagine the following code, which illustrates the possibility of inheritance and a better variable scheme (forgive me any errors — I am a tad rusty at the moment, and also forgive the absolutely terrible color scheme):


.myColorScheme {
keyColor: #0000FF;
accentColor: #FF0000;
}

/* In another file */
#navigation {
inherit: boxElement;
float: left;
display: block;
/* Other layout code here */
}


This really is not against how CSS is defined; .myClassName selectors aren’t really selectors, but class definitions. It only makes sense to be able to use the content of those class definitions later.

The inheritance I show would simply insert the properties defined in the class to inherit from into the class inheriting; you could even make one class inherit from another multiple times, but if you did, it would probably mean that you designed your CSS poorly.

So why shouldn’t I be able to define these and make up new ones as I define entities in an XML or XSL document? I think newcomers to CSS are able to understand color:white… so why not be able to have color:basetone and color:accents.

That is what seems to me the most natural direction. Of course it’s very specific to colors… but on the flipside it’s not like there’s a huge demand for variables either and this one would actually have a “type”.

@TNO
I think you mean JSSS…
Doesn’t it lack any control on nodes other than their node names?
It’s extremely laborious to hand code or read because of it’s one line declaration for each node attribute.
Maybe it’s got variables and expressions but without access to Classes and IDs or any other label than the tag names… it won’t be doing anything productive with those variables.

Saying CSS is broken is a pretty bold statement and you don’t say why it is… CSS does what it’s supposed to do and very well.