3 ms·
Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.
by LocalPCGuy 8y ago
Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.
- ravenstine 8y agoYeah, it's really not hard to delete a CSS file. People really are that lazy, but that's on them, not the technology.
- BurningFrog 8y agoThis is a losing argument. Judge all you want, but you can only change technology, not human nature. Good engineering is to find pragmatic solutions that work in the real world.
- exogen 8y agoNobody thinks it's hard to delete a file. It's hard to know when you can delete a rule. Are you positive that all the rules in your component's CSS file only affect that component? Then great, delete the whole file. What about the individual rules within that file? How do you know whether your app is still rendering any components with the `fancy` modifier anymore? Keep in mind any JS on the page could be be dynamically toggling the `fancy` class, including in very rare circumstances, including from dynamic data that might bring the string "fancy" with it so that you can't just grep your codebase for it. Is it safe to delete the `fancy` rule? Another problem is that even BEM admits that sometimes nested selectors are necessary. It's right there in the BEM FAQ: "While in general BEM recommends avoiding nested selectors, in this case they are reasonable." Sometimes you need your button to look a certain way when it's inside a nav menu item. So what's the solution? Either a nested selector (targeting both the nav item and the button) or a new modifier on your button, like `is-in-nav-item`. Eventually your app changes and you're not rendering any buttons in nav items anymore. Maybe nav items don't even exist anymore and you at least remembered to delete those. Are you also going to remember all the places in your code you need to track down to delete these obsolete nested selectors/modifiers? Or is there just going to be dead code now? What if the selector is slightly more general, and you're not sure if it's targeting other things as well? Are you confident that you won't break anything else? CSS selectors are effectively global. Anything could be secretly relying on the styles that a selector applies. That is the problem. Not deleting a file. Your individual component CSS files are now the "append-only" stylesheets, not necessarily the whole combined stylesheet.
- LocalPCGuy 8y ago> Are you positive that all the rules in your component's CSS file only affect that component? Absolutely
- exogen 8y agoThanks for ignoring everything but the simplest case! No further questions. You've solved CSS.
- barryvan 8y agoThis is where something like CSS Modules comes into its own. You can have (nearly) absolute confidence that what's in the CSS file colocated with the component is only used by that component. Sure, there are escape hatches like `:global(...)`, but those should be considered a code smell. The beauty of CSS modules over a convention-based approach like BEM is that you end up with cleaner, simpler CSS files -- with selectors like `.Widget .search.error` rather than `.Widget__search--error`. The downside is that there's a compilation step, but chances are that you already have _some_ sort of compilation going on -- even if just to bundle things up. The way to handle "special" cases for buttons -- like when they appear in certain contexts -- is to allow the calling code to add a class to the button; a class which comes from the caller's own CSS module. Alternatively, use CSS variables: Button.css .Button { background: var(--btn-background, turquoise); color: var(--btn-foreground, octarine); } Nav.css .Nav { --btn-background: fuchsia; --btn-foreground: lime; }