4 ms·
Your argument that you should use a CSS preprocessor because it makes changing a shade of blue easier is a weak one because a) search/replace for such a case IS
by oneeyedpigeon 11y ago
Your argument that you should use a CSS preprocessor because it makes changing a shade of blue easier is a weak one because a) search/replace for such a case IS perfectly viable b) it is likely to occur so rarely that the savings - if any - will be minimal. There may be other reasons to use a preprocessor, but complicating an architecture for very little benefit might actually be counterproductive.
- nailer 11y agoYou don't often change the values of variables and you're better at regex than most front end engineers?
- oneeyedpigeon 11y agoNo, the colours of the sites I look after don't tend to change on a regular basis. And, if they did, a regex wouldn't be required for the search and replace.
- tacos 11y agoI'm a designer. There is no "blue". There's the blue in the logo. And then there's the blue saturated a bit more when it's on a gray border. And there's the blue brightened a bit when it's on white. If repeating yourself over and over in CSS makes sense by all means stick to your guns. This practice is verboten in all other aspects of tech engineering and it's only the truly idiotic nature of CSS that has people thinking like this to begin with.
- anotheryou 11y agoregarding a): - e.g. swapping colors requires you to replace with an interim value - you might miss the one rgba value, because you only replaced the hex or rgb values - try search + replace for instead of $border-radius-top, when border radius bottom can, but does not have to be set in the same line. And more: - browser prefixes - synchronized animation timing - split in to files and folder hierarchy, but compiling to one file (also makes git merges much easier) - and if you have something with mild theme support it's really handy