[ars]

This will allow never ending loops (two of these can @when each other) - css is not an imperative language that works from top to bottom, it's more of a state language where certain items override other.

If you add this, the language will become turing complete, and then you'll have people disabling css just like they disable javascript.

If you want this, you'll need to find a syntax that makes it impossible for css to become turing complete.

[jerf]

I'm not sure we don't just want to give up and go ahead and make it Turing Complete.

I am well aware of the arguments for DSLs being not Turing Complete and agree with them entirely and wholeheartedly. At the same time, I look at CSS and the strain of it "wanting" to be Turing Complete is becoming so, so noticeable, and what's worse than making a DSL unnecessarily Turing Complete is a DSL that wants to be Turing Complete, and instead of being carefully designed for that purpose gets it accidentally hacked in due to feature creep. (See also: SQL stored procedures, UNIX shell, make, XUL and a number of the declarative UIs that embed too much in the declaration that can't be easily worked with in code.)

Personally I'm coming around to the abstract "right answer" being to scrap CSS and just let JS do it all, letting some people put together some jQuery-like wrappers to make it easy and nice. I understand this will Never Happen (TM), but as CSS grows more and more "features" in the direction of TCness we're getting to the point where what we actually have is isomorphic to that, only much more complicated and impossible to work with.

[peterkelly]

Adding if statements won't make the language Turing complete; there would need to be some sort of iteration or recursion construct for this to be the case.

If the proposed extension was the only change, and the language remained otherwise declarative, then any mutually-dependent if statements could be easily detected by the implementation (e.g. by constructing an expression graph) and either ignored or interpreted as always true or always false. Excel and other spreadsheet apps already include support for if expressions, and they remain purely declarative.

Having said all this, I think that great care should be taken when considering additions like this to CSS, since it could complicate implementations significantly and may lead to poor performance. All of this can be achieved using javascript, so I don't see why you couldn't just write a javascript library instead. jQuery is an example of this approach, which has proved very popular and hasn't required any changes in standards or browsers.

[AntonTrollback]

I didn't spend much time on the syntax. My idea was to mimic the media queries syntax.

Media queries already kind of does this. "When screen max width is larger than xxx. Do this ..."

This idea is a extension where we can check for more than viewport width and height.

[schmolzer]

I don't really see why this syntax can't work as CSS does today? The last style with equal "weight". This idea can be implemented with the same idea.

[ars]

The weight rules applies to any specific element on the page, but this is different.

You can make one rule depend on another, and then that rules depends on the first. This can cause a loop.

You could ignore one I guess, but how do you decide which? Do you use css order? Do you use the order of the page? What is there is an inline style? What is two elements have the style?

It's better not to make a syntax that can get you into trouble like that.