CSS3: css variables are a bad idea. Just allow us to call other selectors.
Everytime I hear about CSS3 allowing the use of variables, I cringe. I can tell right off the bat that this is an extremely bad idea and will be abused beyond belief.
One of the ways I propose replacing this up and coming feature is by just allowing us to call other selectors within a selector. I’ll demonstrate:
<style type=”text/css”>
.bold {font-weight:bold;}
.blue {color:blue;}
.testingagain {selectors:.bold, .blue;}
</style>
<p class=”testingagain”>testing this out</p>
In the above code block the testingagain class would inherit the properties of both the bold and the blue selectors. Further more you could overwrite them, just as you do now.
<style type=”text/css”>
.bold {font-weight:bold;}
.blue {color:blue;}
.testingagain
{
selectors:.bold, .blue;
font-weight:normal;
}
</style>
<p class=”testingagain”>testing this out</p>
Hell, let’s get jiggy with it:
<style type=”text/css”>
.cool {font-weight:bold;color:blue;}
.shout{background-color:red;text-align:center;text-decoration:underline;}
.testingagain
{
selectors:.cool, .shout;
font-weight:normal;
text-decoration:none;
background-color:yellow;
}
</style>
<p class=”testingagain”>testing this out</p>
Why I like this method
Because you can already do it now! You have to do it in the HTML like so
<style type=”text/css”>
.bold {font-weight:bold;}
.blue {color:blue;}
</style>
<p class=”bold blue”>testing this out</p>
With my proposed method it moves this into the css file for easier maintenance and readbility.
So what do you think?
Rip's Domain 
But that’s not really using variables, that’s just calling multiple classes on an HTML element. Your example is fine in only the most simple use case, but what if you have more than one declaration assigned to a class?
.blue { color: #00f; font-weight: bold; }
If you then used that class selector on another element:
.testingagain { selectors: blue; }
It would be both blue and bold, which may not be what you want.
Variables are an easier way to reuse values throughout the CSS; not just colours, but numbers and strings too, and would work better than your example:
@variables { blue: #00f; }
h1 { color: var(blue); }
h2 { background-color: var(blue); }
h3 { border-bottom-color: var(blue); }
@Peter,
Obviously you didn’t read the post fully and just wanted to be the first to comment. Read the post again and I answer your question. But for those that won’t read it.
“In the above code block the testingagain class would inherit the properties of both the bold and the blue selectors. Further more you could overwrite them, just as you do now.”
Notice I specifically state that you could overwrite the properties, just as you do now?
Wow, what a fantastically rude way to welcome someone to commenting on your blog. Believe me, I’ve got better things to do with my time than race to be first to comment on your blog. I thought this was an interesting proposal and I wanted to critique it; forgive me if that was wrong.
I did read your whole post, and I’m sorry but it doesn’t make sense to me; by using your method of calling selectors within selectors, you open up the route of inheriting lots of unwanted declarations, or then having to write extra code to overwrite unwanted inheritance.
Plus, in the use case I showed above – multiple declarations sharing a single value – your method just isn’t as easy to use.You’d have to write out all the values you wanted to use:
.blue { background-color: #00f; border-bottom-color: #00f; color: #00f; }
.testingagain { selectors: .blue; }
Which means you still have to update three values if you wanted to changes the colors to #f00, for example.
Hi,
Many people have different views on this, some in favour and some against. I’m in the favour camp because it’s different to what we already have and gives us an extra tool to define commonly used values.
You’re idea is interesting but as you’ve pointed out can be done at the moment (albeit by including the extra class in the HTML) but I’m not sure how you’re method would be less open to abuse than the proposed CSS variables method.
What I’ve always found interesting about CSS is that there’s no correct way of creating a layout and I’m all in favour of extra ideas being thrown into CSS for us to use and at the end of the day, if some developers don’t like this method then they don’t have to use them as there are alternatives 🙂
I’m almost afraid to respond given the attack on the first responder; but I’ll bite.
I don’t really see how your idea is at all different from CSS variables–except it’s less elegant in its approach. In order to be at all effective, your method relies on many small classes that are concatenated together to form the style of what you’re actually looking for. A bunch of single line classes used as constants (since “variables” is a misnomer in this case) are just that.
@davewoods100
you’re right about the abuse. i guess any method can be abused if not used correctly. i agree with you on the layout issue, properties could and will be added to CSS to make layouts easier.
@brian
you could use a bunch of smaller classes if you wanted to, the option is there. i guess the main problem I have with variables is that once you throw them into the mix, now CSS gets labeled as a programming language rather what it is, a mark up for layouts and will become a frankenstein. just take a look at what html has evolved to. sure they’re making html easier for people to embed videos and media into their pages, but I can’t help but think if that’s what it was meant to do. using something like jquery that is unobtrusive to embed videos and media is fine in my book. i don’t know, maybe i’m wrong.
At the top of many CSS files when I’m doing design work, I end up with a comment that looks like this:
/*
* Body Text color #333
* Body Text size: 0.75em
* etc…
*/
It would be truly great if these were actual variables that I could plug into my code and only change them in one place when / if they change.
The problem with doing your suggested method with anything other than the simplest of selectors is as Peter pointed out earlier–you open yourself up to inheriting a lot of styles you don’t necessarily want–moreover, it introduces a new cascading model that could get VERY complicated.
#myContainer div{ font-size: 2em; }
#myContainer div p{ [selector: #myContainer div] }
So now the text is 4em? Is that what’s intended, or did you really want only 2em?
Variables get around this by allowing us to define reusable values–I don’t think it leads down the path of it being a programming language at all; it’s merely simple substitution.
In concept I think it is an interesting idea, as anything to keep the markup down is usually good practice.
You could take a different approach and use php or what have you, and create a dynamic stylesheet with global variables. Use rewrite to rename the .php to .css
Anyway, at least you were thinking outside the box a bit.
Nice post
At first I actually preferred your method. I think it’s great and would be a more logical / natural way of extending CSS than the proposed variable system. But after reading Peter Gasston’s comment I think the proposed variable system actually makes more sense. Nice try though.
I think the relative simplicity and straight-forwardness of CSS is also what makes it so popular. I can see the author’s point of using what’s available, and the advantages it brings. However, I wouldn’t go as far as ruling new inventions out. Use what works best for the case at hand.
Your proposal is good, but it’s not variables, it’s Rule’s heritage.
So, I think “selectors” should be call “inherits” or “extend” to use common programmatic names.
—————————————-
Why variables are useful :
-You can have one file with variables (the colors, images, … of your site) and a main CSS containing the style rules. To create another style for your site, and if your variables are good thinked, you can only replace the file containing the variables.
—————————————–
Additionnaly, with variables, you can update a lot of rules by JavaScript by updating a single variable’s value : document.CSSVariables.item(“color1″).cssText=”blue”;
Using CSS variables would be very helpful, however, if you plan to store color values in a database.
An example: let an admin modify the color scheme of the site. Let the system query the db and write values out to a variables file.
Without CSS variables, you’d have to use a scripting language to allow the database values to be output to a CSS file, and in that case, a lot of your CSS will become dependent on the scripting language. If anyone messes up the scripting language, then the CSS will break.
CSS variables do show many promising uses, but I agree completely that many will abuse them and use them incorrectly.
Although I’m very in favour of using variabeles (which is the very reason i stumbled upon this post), I do like the Idea of elements inheriting other element’s values.
I would extend the idea like this:
#someid .someclass{
font-weight:bold;
color:blue;}
a.externallink{
text-decoration:underline;
color:red;}
.myclass {
inherit:#someid .someclass:value(font-weight), a.externallink:value(color);}
resulting in
.myclass {
font-weight:bold;
color:red;
}
At first blush this seems like a great idea. But when I started to play with it I encountered 2 problems.
====================
First is the semantic issue. Variables allow me to define presentation terms that don’t pollute the semantic meaning of my HTML. If I introduce selectors that only describe presentation, I would want to make sure that it does not appear in my HTML. For example:
.oxford-blue { color: #8888FF; }
h1 { selector: oxford-blue; }
Selectors ideally should have domain meaningful names like “recommendation” or “title”. I now have a “oxford-blue” class that some other developer might use elsewhere in the HTML. What happens when I decide to make the actual color orange?
-won’t need to be modified
<span class="oxford-blue" – will need to be modified
Variables avoid the pollution of the semantic namespace:
@ oxford-blue = #8888FF
.title { color: @oxford-blue; … }
The html has access only to the "title" class, not "oxford-blue".
====================
The second issue is decoupling. A variable allows me to decouple a property name from its value. For example, if I want a simple color variable:
@ oxford-blue = #8888FF
#signup-area { …; border-color: @oxford-blue; …; }
h1 { color: @oxford-blue; }
I can reuse the color definition above with any of a large number of properties that take a color value. If I were inheriting from a selector, I would be forced to get the entire property.
I realize that many people do not use CSS as a way to semantically mark up their HTML, so the first issue may be a moot point to many 😦
Hmmm…. my example for issue I above did not come out. Let me try again without the angle brackets:
What happens when I decide to make the actual color orange?
(span class=”title”) -won’t need to be modified
(span class=”oxford-blue”) – will need to be modified
Hi,
This a wonderful idea, for many reasons. Some don’t see it that way (http://dorward.me.uk/www/css/inheritance/), because the mindset is different. Let’s clarify the issue a bit, because there are actually two different problems:
– most people claiming to want CSS Variables actually want CSS constants
– multiple classes must be specified at the markup level
To start with, it seems some of above posters are already confused. If you call “blue” to a class, then you’re really looking for constants, not variables.
Assuming you want variables as a means to reduce the CSS clutter, or for instance, the ability to define colors on one side and format on another, then what rip747 is not only far more powerful, but is trivial to implement by browsers, because, hei, they already provide that mechanism by default!
There already is inheritance in CSS – the cascade part of Cascading StyleSheets.
I also don’t see how much less complex and inabusable your inherited selector system would be against variables. In fact, this system would be much more complex, and could make the stylesheet very difficult to follow through and assess.
From what I’ve seen of CSS variables – it seems more of a way of setting up aliases for values – if implemented in the same way as Arild above suggests.
I think this is a great idea!
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
[…] Always be efficient. Know when to use CSS variables and when just to use selectors. […]
At first I was intrigued by this solution, but then I saw just how ugly and prone to prone it would be.
Not only that, but it doesn’t actually fill the void of variables which could be used like so:
var defaultBack = #666;
var negativeDefaultBack; = -defaultBack;
var titleText = 200%;
var subText = titleText / 5;
.exampleClass {
background-color: defaultBack;
color: negativeDefaultBack;
font-size = subText;
}
this could allow the modification of entire colour schemes through modifying one variable’s value.
Much more powerful AND elegant in my opinion.
“Prone to prone….”
I meant “prone to problems”.
I agree with NinKenDo, it’s very much like the ideas of LESS ( http://lesscss.org/ ). LESS offers both ways, variables that respresent values, and variables that represent whole style definitions.
I like the idea offered by NinKenDo too. It introduces not just variables but full fledged EXPRESSIONS, and the current implementation described in CSS3 drafts looks more like a macros to me.
Check out Sass (http://sass-lang.com/). It gives you variables, mixins and inheritance.
What you are forgetting is that a variable can be applied to more than one property where as your implementation can’t. For example lets say you have a colour stored in a variable you may want to use this colour for the background of one element, the border of another and the font colour of a third. By using variables you can define that colour once and use it several times easily. This makes changing the styles easy as a colour which is meant to be the same on different elements (but not necessarily the same property) is only defined once.
What you are talking about is inheritance which CSS should also have but does not replace the usefulness of variables. Further, although we can use something like this now, it’s a bad practice (although a common one). It’s best to avoid class names that describe what an element should look like and instead use class names that describe what an element is or what its purpose is. Your method leads to html elements like which is really not much better than just using the style attribute.
I would suggest that a better method for inheritance would be like this:
.some-class
{
inherit: blue, bold;
}
Where the meaning of this is not to just copy rules from some other part of the css but rather to ‘add’ the inherited classes (notice that they are not selectors) to the selected elements. The difference is subtle but very important if you think about the effects of nesting and more complex selectors.