Idea: When (if) statements in CSS(hastebin.com)
hastebin.com
Idea: When (if) statements in CSS
http://hastebin.com/fuyuniweco.rb
14 comments
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can already do things like this with stylus (http://learnboost.github.com/stylus/). As far as I can see, if you are thinking at this level with css you should be using a preprocessor for sure. I can't remember the last project I used vanilla css in.
Here's a totally silly example, but you can see the power:
Here's a totally silly example, but you can see the power:
color-if-hidden(color)
if @display == none
color: color
.hello
display: none
color-if-hidden(red)It's true, but you're not considering cascade rules, of course. How do you know that another selector has `display: inline`ed that element?
EDIT: typo
EDIT: typo
This is a lot like CSS expressions right?
If they weren't horrible for performance and not standard they'd probably be fairly cool:
http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_perf...
If they weren't horrible for performance and not standard they'd probably be fairly cool:
http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_perf...
Ideologic errors apart (which are epic) the feature you propose will anyway be not usable.
In a `@if` what does `li` means related to the `li` inside the body? Absolutely nothing.
What could seriously be interesting instead is a property value selector similar to attribute selector. Something similar to `[@color != red]`
In a `@if` what does `li` means related to the `li` inside the body? Absolutely nothing.
What could seriously be interesting instead is a property value selector similar to attribute selector. Something similar to `[@color != red]`
This is a horrible idea.
Probably a better idea would be to decide the appropriate content based on various criteria on the server-side. Otherwise the stylesheet will become a nightmare to maintain and would contain a lot of inappropriate logic which doesn't belong to css.
Check out SASS's control directives. They do everything you want.
http://thesassway.com/intermediate/if-for-each-while
http://thesassway.com/intermediate/if-for-each-while
take a look at LESS CSS. It does exactly this and more. http://lesscss.org/
I don't think it does. What OP is proposing would require to modify the CSS engine to update the style of elements when something changes (hide some element when some other suddenly (via JS for instance) becomes visible). LESS/SASS does not give you that. Yes you have "if" clauses, but they are evaluated based on some fixed state when "compiling" to CSS.
[deleted]
CSS rendering engines will need to get much faster before anything like this wouldn't feel glitchy or pop-in.
Why would you want to use CSS for something that seems like a job for JavaScript?
Looks cool. My one thought is replace @when with @if, to make life easier for every programmer ever.
Depends on if the OP means this should be event-driven/dynamic or not. The "when" seems to imply that it should be. When .widget becomes larger than 300px (screen resize/flip, for instance), then the font-size should become larger.
If that is OP's intention, then I feel @when is more appropriate than @if
If that is OP's intention, then I feel @when is more appropriate than @if
looks like SASS or LESS.
Non-sense. This is relevant in JS not CSS.
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.