Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Modules

glenmaddern.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: CSS Modules

#21

Post by ekosz »

andreypopp wrote: post #10

Also see styling[0] which is a loader for webpack which allows to generate CSS modules with JS. Files configured to use with this loader (usually `.style.js`) are executed at build time and produce CSS modules. You can use any JS abstractions for that (functions, modules, variables, ...) and any npm package available (color manipulation, typography, ...): import styling from 'styling' import {smallText} from './typog…

This is a very cool library. Thanks for the link. Have you used this in any projects yet?

Re: CSS Modules

#22

Post by ivanca »

spankalee wrote: post #20

Shadow DOM completely solves this problem in a better way by scoping styles to a shadow root. The scoping allows the browser to be smarter about style recalc as well. I do really like the idea of importing CSS into JS as a module to access the classnames and IDs though. I would like to do a similar thing with HTML imports as modules: import references to elements based on id.

Unfortunately Shadow DOM inherits CSS properties such as color;font-family.

Re: CSS Modules

#23

Post by andreypopp »

ekosz wrote: post #21
andreypopp wrote: post #10

Also see styling[0] which is a loader for webpack which allows to generate CSS modules with JS. Files configured to use with this loader (usually `.style.js`) are executed at build time and produce CSS modules. You can use any JS abstractions for that (functions, modules, variables, ...) and any npm package available (color manipulation, typography, ...): import styling from 'styling' import {smallText} from './typog…

This is a very cool library. Thanks for the link. Have you used this in any projects yet?

We started to migrate away from pure CSS Modules to Styling in our apps. Code didn't hit production yet but we are close.

Writing styles in JS instead of CSS gave us a huge expressiveness boost and allowed to use existing JS tooling such as eslint. At the same time all CSS tooling still can be applied to compilation result (such as autoprefixer).

Also would be fun to write styles in TypeScript — statically typed styles sounds great.

Re: CSS Modules

#24

Post by [deleted] »

ekosz wrote: post #21
andreypopp wrote: post #10

Also see styling[0] which is a loader for webpack which allows to generate CSS modules with JS. Files configured to use with this loader (usually `.style.js`) are executed at build time and produce CSS modules. You can use any JS abstractions for that (functions, modules, variables, ...) and any npm package available (color manipulation, typography, ...): import styling from 'styling' import {smallText} from './typog…

This is a very cool library. Thanks for the link. Have you used this in any projects yet?

[deleted]

Re: CSS Modules

#25

Post by troels »

Abstractions are fine and dandy until they break down and you have to pry them open. What I don't understand here, is why the generated code doesn't follow the already established BEM conventions which the posts explores initially.

Re: CSS Modules

#26

Post by egze »

The advantage of BEM naming is that it takes 0 effort to find your style definitions in code.

.Button--disabled copied in the browser, will find exactly 1 definition in the project. .components_submit_button__normal__abc5436 will not find you anything.

Re: CSS Modules

#27

Post by sbensu »

ploxiln wrote: post #9

So... CSS has the same global namespace issue as C, and this CSS Modules is the same solution as C++ namespaces and classes. They call it "mangling". https://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in... (further commentary prudently withheld)

I agree that mangling isn't ideal but the naming resolution rules are already defined in every browser and they use a global namespace! From a distance, I don't see a better approach to providing namespace-like-things.

Re: CSS Modules

#28

Post by dfunckt »

Right, but what about the name? This isn't Cascading Style Sheets any more. Hmm let's see, Composable Style Sheets. There. Oh, wait...

Re: CSS Modules

#29

Post by aleem »

It's wonderful that CSS problems have been distilled so clearly, it's been a long time coming. Radium[1] is really worth checking out, it's simple and clear.

From the article:

  /* BEM */
  .normal { /* all styles for Normal */ }
  .button--disabled { /* overrides for Disabled */ }
  .button--error { /* overrides for Error */ }
  .button--in-progress { /* overrides for In Progress */

  /* CSS MODULES */
  .normal { /* all styles for Normal */ }
  .disabled { /* all styles for Disabled */ }
  .error { /* all styles for Error */ }
  .inProgress { /* all styles for In Progress */

  > In CSS Modules each class should have all the styles needed for that variant
This seems like trading one set of problems for another. It violates DRY and consequently impacts code maintainability. The corollary is that .disabled should @include .normal and then define the overrides so you only have to define the base styles once in .normal... but that also requires discipline and code wrangling.

  > [BEM] requires an awful lot of cognitive effort around naming discipline.
But the proposed alternative is not too different either:

  /* components/submit-button.css */
  .error { ... }
  .inProgress { ... }
This example just replaces BEM naming and namespacing with file naming and directory structure.

[1]: https://github.com/FormidableLabs/radium

EDIT: On second reading, the stuff in there is definitely not "Welcome to the future" exploring the "adjacent possible" realm--those are quite grandoise pretexts to a solution that is just as unwieldy.

Re: CSS Modules

#30

Post by kaoD »

rdsubhas wrote: post #19
sepokroce wrote: post #4

Surely not the future.

Not sure why you're getting downvoted. Problems with CSS at Scale are very real (as mentioned in the slide). But this is a super complicated solution. Its like one of the head-over-heels approaches in JoelOnSoftware blogs. Surely there has to be a simpler way. Its good that the authors are trying. But just look at the picture on this article captioned "This is how intensely we’ve been thinking about CSS". That's wher…

> Not sure why you're getting downvoted.

Because it doesn't contribute anything but nonconstructive criticism.

> Good solutions present themselves and fit naturally.

Complex problems require complex solutions.

Also, what's so complex and non-fitting about this solution? Explaining that (and your alternative solution) would be much better than simply criticizing as you and GP did.

> Surely there has to be a simpler way.

There's a technically simpler way: modules being part of the CSS spec. But they're not, so even if technically simpler as a solution, it's a political nightmare on which we developers have no control whatsoever.

Driving forward the status quo with hacks (like to-JS transpilers did) is nothing but beneficial. Hacks drive standards.

> "This is how intensely we’ve been thinking about CSS". That's where the whole complexity comes from I guess.

How much have you been been thinking about CSS and fighting its flaws? Obviously not a lot.

Post reply on HN