I'll have to agree and disagree with that statement. Sometimes your job is to further develop an existing solution with crappy CSS and poor design, leaving 50%

I'll have to agree and disagree with that statement. Sometimes your job is to further develop an existing solution with crappy CSS and poor design, leaving 50% or more of the CSS redundant compared to a more optimal solution. In this case, CSS has clearly been applied wrong, but if you want to be able to work with it consistently constants would have been a powerful tool in your toolkit. Sometimes you want whatever page or site you are working on to work with a defined palette. Maybe the same colour should be used for either foreground or background colour depending on its current state (inactive, selected, hovered) and so on. In many such cases, depending on complexity, trying to minimize the redundancy in the CSS practically makes the CSS unreadable or unmaintainable since the different attributes and settings for one selector is spread all across your CSS definitions. In other words: Solving one problem creates a new problem, maybe equally bad or worse. Some might suggests we should be able to reference selectors in selectors. Like "make this A:hover have the background colour of A:non-hover's colour-attribute". That however would make CSS much more like a programming language than a declarative layout language. It would also run the risk of recursiveness and add confuzion with regard to state-based behaviour. No matter what syntax is used, I can't imagine this resulting in more natural or readable CSS. As far as constants go, I can't see them making any more problems or any worse problems than the ones discussed above. Among many evils, I would consider constants one of the smallest. But who knows... Maybe I just lack imagination.