5 ms·

While I agree with the premise that css preprocessors are overused, I can't stress enough that the use of complex css selectors is a really bad idea. Not only c

While I agree with the premise that css preprocessors are overused, I can't stress enough that the use of complex css selectors is a really bad idea. Not only can it kill performance (or at least make it hard to reason about) it encourages tight implicit coupling between the style sheet and the document which generally leads to hard to maintain front ends.

oneeyedpigeon 13y ago
Is there a better way to solve the problem presented? Because I think the author does it with about the least amount of coupling possible, and that's to be applauded.
- peterhunt 13y ago
  The "last" class he mentioned is a better solution. His only reason against it was "complex template logic is bad". If you're using a sufficiently powerful system for managing the Dom it's usually much easier to manage the complexity of the "last" class. It's fast and easy to tell at first glance which styles will be applied, and refactoring is easy as a result. His mention of separation of concerns is, IMO a common misunderstanding of what that term means. The coupling has to be made somewhere after all and it's better to choose the more performant and more explicit way.
  - oneeyedpigeon 13y ago
    I'm not a big fan of the 'last' class approach since it's redundant and pollutes the markup. YES, it only does this to a very small extent, but when we're talking about which solution is 'better', I think it weighs pretty significantly. I don't see anything inherently tricky maintenance-wise in his approach.
    - peterhunt 13y ago
      What happens when you change the structure of the markup? How do you know for sure which rules apply to the stuff you're changing?
camus2 13y ago
> While I agree with the premise that css preprocessors are overused I'd like to know how one maintains a huge modular css code base without any sort of preprocessor. Preprocessors are here because CSS sucks, and no standard committee seems to want to fix it. That's why people built these tools right, to solve a problem nobody was going to solve for them. That's exactly the same thing with javascript. If javascript was decent we would not need all these compile to javascript languages. These tools bring diversity and choice to a poor plateform with shamefull languages that are not evolving very fast. You cant fix it just by adding features without fixing the core. that's what preprocessors are for and it's ok to abuse them without shame. EDIT: my point is "it's good enough" isnt good enough, in a time where we are supposed to maintain complex front-end projects and asset pipelines, that work on different devices that have their own idea of how to implement (poorly written) standards.
- peterhunt 13y ago
  Well, I think JavaScript is good enough (I do prefer Python though) and we certainly don't need compile-to-JS languages like CoffeeScript (which IMO just takes a somewhat-ambiguous syntax and makes it more ambiguous). TypeScript is somewhat of an exception, but I view it less as a language (since it doesn't change runtime semantics afaik) and more of hints to a linting tool. The problem with CSS preprocessors is that they are simultaneously too powerful and not powerful enough. That is, things like SASS mixins and nesting make it easy to make mistakes (specificity overload and huge stylesheets are the two big ones). At the same time they don't change runtime semantics so you can't fix the biggest problems in CSS like specificity wars, finding dead selectors and namespacing. I do like variables and expressions though (mainly for colors and grid units). The way you maintain a big modular codebase is to make your stylesheets really stupid and build the smarts into whatever is generating the DOM. The tools we have for generating DOM are both far more mature and we have more control over the semantics of the runtime.

oneeyedpigeon 13y ago

Is there a better way to solve the problem presented? Because I think the author does it with about the least amount of coupling possible, and that's to be applauded.

peterhunt 13y ago
The "last" class he mentioned is a better solution. His only reason against it was "complex template logic is bad". If you're using a sufficiently powerful system for managing the Dom it's usually much easier to manage the complexity of the "last" class. It's fast and easy to tell at first glance which styles will be applied, and refactoring is easy as a result. His mention of separation of concerns is, IMO a common misunderstanding of what that term means. The coupling has to be made somewhere after all and it's better to choose the more performant and more explicit way.
- oneeyedpigeon 13y ago
  I'm not a big fan of the 'last' class approach since it's redundant and pollutes the markup. YES, it only does this to a very small extent, but when we're talking about which solution is 'better', I think it weighs pretty significantly. I don't see anything inherently tricky maintenance-wise in his approach.
  - peterhunt 13y ago
    What happens when you change the structure of the markup? How do you know for sure which rules apply to the stuff you're changing?

camus2 13y ago

> While I agree with the premise that css preprocessors are overused I'd like to know how one maintains a huge modular css code base without any sort of preprocessor. Preprocessors are here because CSS sucks, and no standard committee seems to want to fix it. That's why people built these tools right, to solve a problem nobody was going to solve for them. That's exactly the same thing with javascript. If javascript was decent we would not need all these compile to javascript languages. These tools bring diversity and choice to a poor plateform with shamefull languages that are not evolving very fast. You cant fix it just by adding features without fixing the core. that's what preprocessors are for and it's ok to abuse them without shame. EDIT: my point is "it's good enough" isnt good enough, in a time where we are supposed to maintain complex front-end projects and asset pipelines, that work on different devices that have their own idea of how to implement (poorly written) standards.

peterhunt 13y ago
Well, I think JavaScript is good enough (I do prefer Python though) and we certainly don't need compile-to-JS languages like CoffeeScript (which IMO just takes a somewhat-ambiguous syntax and makes it more ambiguous). TypeScript is somewhat of an exception, but I view it less as a language (since it doesn't change runtime semantics afaik) and more of hints to a linting tool. The problem with CSS preprocessors is that they are simultaneously too powerful and not powerful enough. That is, things like SASS mixins and nesting make it easy to make mistakes (specificity overload and huge stylesheets are the two big ones). At the same time they don't change runtime semantics so you can't fix the biggest problems in CSS like specificity wars, finding dead selectors and namespacing. I do like variables and expressions though (mainly for colors and grid units). The way you maintain a big modular codebase is to make your stylesheets really stupid and build the smarts into whatever is generating the DOM. The tools we have for generating DOM are both far more mature and we have more control over the semantics of the runtime.