3 ms·

Have used tools like this before, and invariably end up accidentally stripping styles from an <insert JS UI lib> component with a dynamically assigned classNam

by ry_ry 10y ago

Have used tools like this before, and invariably end up accidentally stripping styles from an <insert JS UI lib> component with a dynamically assigned className or something equally silly. It's such a hard problem to solve and the Stylesheet Snowball is one of the most frustrating pieces of technical debt a large site can pick up. It makes me wonder if scoped CSS modules, despite fundamentally breaking CSS with their hyper specific hybrid BEM-class-ids might be the best preemptive solution even when you're not scaling up to massive SPAs. Edit. Meant CSS modules, wrote CSS components. I am not a clever man.

_nalply 10y ago
I agree, it's a hard problem. Perhaps run a test-suite with UnCSS? If you still accidentally strip styles then the test-suite is not complete.
- dlo83 10y ago
  Not a bad idea.
Shinchy 10y ago
The advent of Sass and Nesting helped an awful lot, but there is still much to be done.
madeofpalk 10y ago
This is already theoretically solvable with CSS Modules. Because you 'statically' import your CSS (class names) as an object, which can't/shouldn't change after build, you could run an analyser to remove any unused classes from the stylesheets. Essentially tree shaking for CSS.
noir_lord 10y ago
I used BEM everywhere on the front end of a project, at the time I didn't really like it very much. I came back to that project 7mths later and I could find everything exactly where I left it, I realised that past me had made a reasonable choice for the future. Now I hold my nose and use it (or something like it) everywhere. Even b-<somefoo> { <otherstuff> } helps hugely, I just wish there was an easier way of stopping accidental stomping from other selectors outside b-<somefoo>.
rvanmil 10y ago
My experience with CSS modules is that it has the same problems, just at a smaller scale. And because of the local scope I also see a lot more code duplication. It also doesn't play very well with global CSS libraries like bootstrap.
caseyf 10y ago
For me, BEM takes much of the pain out of reusing and (especially) refactoring big CSS.
andybak 10y ago
> Have used tools like this before, and invariably end up accidentally stripping styles from an <insert JS UI lib> component with a dynamically assigned className or something equally silly. The only way I can think to handle this is if you've got a really thorough test suite in Selenium or similar. Do a before and after, capture screengrabs of everything and flag up where the 'new' CSS has caused visual differences. It's a horrible solution but then it's a horrible problem.
- eriknstr 10y ago
  Alternatively, you could dump the DOM of each rendered test case and use that to construct a single document that has all the classes and ids that are in use in it and run UnCSS on that. Maybe. Not saying it will be easy (in particular rules which are about certain hierarchies might get hairy) but I think it's worth a shot.
  - ry_ry 10y ago
    Huh, pulling it out the unit tests is a pretty good idea actually - if the test coverage is good enough it might be worth a bit of investigation. Especially since it'd be an optional build step you'd only want to run infrequently.
vog 10y ago
> with a dynamically assigned className or something equally silly. How is that silly? Assume e.g. a very simply dynamic list, where you just want highlight rows after clicking on them. Should it set the CSS properties of the <tr> directly? It makes more sense to dynamically add/remove a CSS class such as "selected-row". However, since initially no row is selected that class does not appear in the initial HTML. > scoped CSS components Not sure if this is the same, but I had very good experience with component-oriented frameworks where each component has an HTML snippet and CSS snippet attached to it. The CSS is written in a way that it affects only the responsibility scope of the component, nothing outside the component, nothing inside child components.[1] Then, these CSS snippets are simply collected into a large (and perhaps compressed) CSS file. [1] This is usually done be either prefixing all CSS rules with a component-specific class name, or by using a component-specific custom HTML element and selecting on that. Stepping into children is avoided by using only child selectors ("a > b > * > * > c" instead of "a b c"), so the rules don't reach deeply except for the cascading properties of CSS itself.
- ry_ry 10y ago
  Oh dynamically setting class isn't silly, but the times i accidentally removed the 'unused' style because it's not explicitly coded into that app and was flagged by the tool, I felt pretty silly! I got as far as starting to build us a tool to traverse our raw jsx to identify these programmatically generated classes, but my implementation was a bit flakey for various reasons and required too much config to make it worthwhile so I binned it off.
  - vog 10y ago
    > Oh dynamically setting class isn't silly Oh, so I misread your sentence. Thanks for the clarification. Sorry for the noise.

by ry_ry 10y ago

_nalply 10y ago

I agree, it's a hard problem. Perhaps run a test-suite with UnCSS? If you still accidentally strip styles then the test-suite is not complete.

dlo83 10y ago
Not a bad idea.

Shinchy 10y ago

The advent of Sass and Nesting helped an awful lot, but there is still much to be done.

madeofpalk 10y ago

This is already theoretically solvable with CSS Modules. Because you 'statically' import your CSS (class names) as an object, which can't/shouldn't change after build, you could run an analyser to remove any unused classes from the stylesheets. Essentially tree shaking for CSS.

noir_lord 10y ago

I used BEM everywhere on the front end of a project, at the time I didn't really like it very much. I came back to that project 7mths later and I could find everything exactly where I left it, I realised that past me had made a reasonable choice for the future. Now I hold my nose and use it (or something like it) everywhere. Even b-<somefoo> { <otherstuff> } helps hugely, I just wish there was an easier way of stopping accidental stomping from other selectors outside b-<somefoo>.

rvanmil 10y ago

My experience with CSS modules is that it has the same problems, just at a smaller scale. And because of the local scope I also see a lot more code duplication. It also doesn't play very well with global CSS libraries like bootstrap.

caseyf 10y ago

For me, BEM takes much of the pain out of reusing and (especially) refactoring big CSS.

andybak 10y ago

> Have used tools like this before, and invariably end up accidentally stripping styles from an <insert JS UI lib> component with a dynamically assigned className or something equally silly. The only way I can think to handle this is if you've got a really thorough test suite in Selenium or similar. Do a before and after, capture screengrabs of everything and flag up where the 'new' CSS has caused visual differences. It's a horrible solution but then it's a horrible problem.

eriknstr 10y ago
Alternatively, you could dump the DOM of each rendered test case and use that to construct a single document that has all the classes and ids that are in use in it and run UnCSS on that. Maybe. Not saying it will be easy (in particular rules which are about certain hierarchies might get hairy) but I think it's worth a shot.
- ry_ry 10y ago
  Huh, pulling it out the unit tests is a pretty good idea actually - if the test coverage is good enough it might be worth a bit of investigation. Especially since it'd be an optional build step you'd only want to run infrequently.

vog 10y ago

> with a dynamically assigned className or something equally silly. How is that silly? Assume e.g. a very simply dynamic list, where you just want highlight rows after clicking on them. Should it set the CSS properties of the <tr> directly? It makes more sense to dynamically add/remove a CSS class such as "selected-row". However, since initially no row is selected that class does not appear in the initial HTML. > scoped CSS components Not sure if this is the same, but I had very good experience with component-oriented frameworks where each component has an HTML snippet and CSS snippet attached to it. The CSS is written in a way that it affects only the responsibility scope of the component, nothing outside the component, nothing inside child components.[1] Then, these CSS snippets are simply collected into a large (and perhaps compressed) CSS file. [1] This is usually done be either prefixing all CSS rules with a component-specific class name, or by using a component-specific custom HTML element and selecting on that. Stepping into children is avoided by using only child selectors ("a > b > * > * > c" instead of "a b c"), so the rules don't reach deeply except for the cascading properties of CSS itself.

ry_ry 10y ago
Oh dynamically setting class isn't silly, but the times i accidentally removed the 'unused' style because it's not explicitly coded into that app and was flagged by the tool, I felt pretty silly! I got as far as starting to build us a tool to traverse our raw jsx to identify these programmatically generated classes, but my implementation was a bit flakey for various reasons and required too much config to make it worthwhile so I binned it off.
- vog 10y ago
  > Oh dynamically setting class isn't silly Oh, so I misread your sentence. Thanks for the clarification. Sorry for the noise.