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

71–80 of 93 posts

Re: CSS Modules

#71

Post by madeofpalk »

aleem wrote: post #29

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 f…

> 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.

If I'm using .btn-disabled everywhere, then its hard to be to write a CSS rule that says 'whenever a button follows another button, apply this style to it'. That's why we have this competition with BEM and `.btn .disabled`.

> This example just replaces BEM naming and namespacing with file naming and directory structure.

...Yes. That's the point.

The problem is that CSS is a global 'language', and everything that you write has the chance to impact all your other CSS. When I'm writing a particular component, there's no way to write CSS that's local to just that component.

We have things like BEM that is about establishing a _convention_ to write Pseudo-Local-CSS, but nothing is enforced. Everything is still global. 'CSS Modules' enforces your CSS to be 'local only' as a file-level, just like regular (Node) JS.

It's like how there's a convention of not adding a string to an integer, but adding a type system to your programming language enforces that on a technical, contractual level.

Re: CSS Modules

#72

Post by christophilus »

Kequc wrote: post #55
prezjordan wrote: post #54

Earlier quoted context omitted.

Now what if you wanted to bring in another button - a very similar one - with slightly different styles?

You extend the styles now you perhaps have: .mybutton /* all styles for Normal */ .mybutton.skewed /* overrides for Skewed */ .mybutton.disabled /* overrides for Disabled */ class="mybutton skewed disabled" The suggestion in the OP would be that each one of those classes contain all of the styles for the button. That isn't necessary. Plus it requires, what I count, a minimum of two additional language abstractions in…

I agree. I tend to prefix my modifiers with "is-", though so that you know it is a modifier. e.g. ".mybutton.is-skewed" and then never have a standalone ".is-" rule. They are always modifiers only.

Re: CSS Modules

#73

Post by marcosdumay »

Davertron wrote: post #44
yari_ashi_zero wrote: post #42

HTML is for hypertext documents, and CSS an organ of the same organism called 'HTML/CSS'. It's made for text documents, and applying it to the implementation of GUI-centric applications has always been an ugly hack. For awhile (90s to 00s AJAX) it was necessary, and now the whole professional ecosystem has built up tremendous inertia over the millions of accumulated people/hours of perfecting this 'competency'/hack.…

Moving entirely to svg for user interface has some of its own issues (i.e. there's no default layout engine in svg; everything is essentially absolutely positioned...) but would be interesting to think about. Moving entirely to WebGL would only be viable if you don't care at all about accessibility though. For some subset of applications that might be acceptable (i.e. games), but for something like gmail or other sim…

You just have to create widgets libraries, compile them to WebAsm or something alike, and export an event-based framework for the developers to use. It can even be in another language, compiled to WebAsm.

Or, alternatively, you can just use Flash, instead of cloning it.

Re: CSS Modules

#74

Post by saidajigumi »

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)

But just as with C++, that's effectively an implementation detail, and irrelevant to the larger issues addressed. BEM itself is just name-mangling structured for humans to execute manually. (wait, WAT.) We're talking about the cognitive model and load that designers and developers have to deal with when authoring styles.

I see CSS Modules (and Radium and ...) as being a space for experiments that I hope will ultimately point the way to better "baked in" solutions. Similar to how ideas from Coffeescript were "merged back upstream" into ES6/ES7.

Re: CSS Modules

#75

Post by untog »

madeofpalk wrote: post #70
crazygringo wrote: post #69

Earlier quoted context omitted.

I feel like you're looking at the past through rose-colored glasses, my friend. > Websites like csszengarden.com showed us the promise of style sheets That site was always highly artificial -- huge deficiencies in CSS meant that it always wound up being tightly coupled to the HTML structure for any non-trivial site. > I always felt proud to make a website with only semantic HTML and CSS, and it always worked well. Ev…

> It never worked well Don't confused 'it never worked well' with 'i never understood how it worked'. 'Good'[1] front-end/CSS developers have a very good understanding of float quirks, the box model and how to properly vertically centre things. Just because I don't understand how pointers in C work doesn't mean that C doesn't work well. But yes - CSS isn't ideal. [1] Where 'good' is similar to 'stockholm syndrom'

'Good'[1] front-end/CSS developers have a very good understanding of float quirks, the box model and how to properly vertically centre things.

That doesn't mean "it worked well", it means "people had to learn to cope with its deficiencies". I don't see that as a particularly good thing.

Re: CSS Modules

#76

Post by untog »

mangeletti wrote: post #62

I might be a majority shareholder of the following opinion, but I feel like it needs to be said. CSS was an art, and a science. Websites like csszengarden.com showed us the promise of style sheets, and the galleries of "CSS sites" during the mid to late 2000s demonstrated what amazing works could be taken from photoshop (and Fireworks!) and made into beautiful, pixel-perfect layouts. I always felt proud to make a web…

Websites like csszengarden.com showed us the promise of style sheets

And that's all it was - promise. There is a reason why CSS Zen Garden was just an example using a single page as a template.

In reality, people now make webapps of incredible size. A lot of what CSS Modules seems to be trying to fix is exactly that - how to maintain a lot of styles without namespace clashing, one giant CSS file, etc. etc.

I spent a lot of time dealing with all that, so I don't look back at the past in a positive way. I'm not saying CSS Modules is the answer, but it's interesting at least.

Re: CSS Modules

#77

Post by NathanCH »

talmand wrote: post #61
Kequc wrote: post #55

Earlier quoted context omitted.

You extend the styles now you perhaps have: .mybutton /* all styles for Normal */ .mybutton.skewed /* overrides for Skewed */ .mybutton.disabled /* overrides for Disabled */ class="mybutton skewed disabled" The suggestion in the OP would be that each one of those classes contain all of the styles for the button. That isn't necessary. Plus it requires, what I count, a minimum of two additional language abstractions in…

Excellent answer. I love these "gotcha" examples when taking something that should be relatively simple and trying to make it more complicated to prove, um, something. I wish people would realize that making their CSS more complicated and bloated is not necessarily the answer.

I agree, a lot of these solutions come from bad CSS. Not because CSS is bad.

Re: CSS Modules

#78

Post by tfb »

I've been using JSS for everything. It makes the most sense to me. It's minimal in size and function to the point that any extra functionality can be quickly and easily added via `jss.use(plugin)`. And it's maximally modular. Every class is namespaced, and exporting everything to a single sheet for production builds is super simple, as it should be.

https://github.com/jsstyles/jss

Re: CSS Modules

#79

Post by err4nt »

mangeletti wrote: post #62

I might be a majority shareholder of the following opinion, but I feel like it needs to be said. CSS was an art, and a science. Websites like csszengarden.com showed us the promise of style sheets, and the galleries of "CSS sites" during the mid to late 2000s demonstrated what amazing works could be taken from photoshop (and Fireworks!) and made into beautiful, pixel-perfect layouts. I always felt proud to make a web…

I agree with you! Most people miss or don't understand the _cascading_ part of CSS. If you have well written markup, you can write beautiful CSS that removes much of the need for precompilers like SASS and Less and the hundreds of lines of code they output.

I'm still in the business of full-custom HTML+CSS+JS craftsmanship.

Re: CSS Modules

#80

Post by serapath »

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…

Hey, that looks great :-) I'll try it. What do you think of https://github.com/css-modules/css-modules/issues/23#issueco...
Post reply on HN