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

81–90 of 93 posts

Re: CSS Modules

#81

Post by ssalazar »

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'

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

Great. How many "good" CSS developers are there, and what is their hourly rate? If average developers still can't figure it out after its been around for a decade (see [1]), then the language has failed. At the end of the day CSS needs to usable for regular programmers, or its not very useful as a core framework for the Web.

[1] http://howtocenterincss.com/

Re: CSS Modules

#82

Post by Wintamute »

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…

A lot of the latest thinking in (non-JS) CSS suggests that violating DRY is an excellent idea. Copy and pasting CSS rules is cheap, but maintaining and adapting a large complex CSS project that's blowing up in a team's face can be very expensive.

Re: CSS Modules

#83

Post by sic1 »

mradmin wrote: post #49
chinchang wrote: post #47

This seems like too much abstraction (magic) of things. Plus those auto generated classes really look odd and would make debugging difficult.

I assume soucemaps would solve this.

It's lovely to assume this, but I see no mention of sourcemaps anywhere. This was my immediate gripe, debugging.

Yea, the class name should point you to the file you want to look at, but that is still manual legwork. And the whole atomic css-like pitch he has with the over-the-top `composes` functionality looks like its own nightmare.

I'll watch from over here and see if this pans out for ya'll.

Re: CSS Modules

#84

Post by ivanca »

TeeWEE wrote: post #64
ivanca wrote: post #22

Earlier quoted context omitted.

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

Where do you read that? I just checked the spec and coundt find this exception to the rule.

I didn't, it is how it works in latest Chrome.

In all fairness, that's how a blank browser works by default (e.g. Times News Roman is the inherited font-family if you don't specify one) so is very likely the intended behavior.

Re: CSS Modules

#85

Post by martin-adams »

bobwaycott wrote: post #60
martin-adams wrote: post #48

Earlier quoted context omitted.

Correct. Would the word 'comprises' be more appropriate?

I stumbled upon the Github issue and then found the HN reference. I commented with some additional thoughts and keyword options. I don't think 'comprises' would be the best choice here; it has quite a stricter meaning than 'includes' and its synonyms.

What about 'inherits' or 'extends' to match known programming terms?

Re: CSS Modules

#86

Post by mradmin »

sic1 wrote: post #83
mradmin wrote: post #49

Earlier quoted context omitted.

I assume soucemaps would solve this.

It's lovely to assume this, but I see no mention of sourcemaps anywhere. This was my immediate gripe, debugging. Yea, the class name should point you to the file you want to look at, but that is still manual legwork. And the whole atomic css-like pitch he has with the over-the-top `composes` functionality looks like its own nightmare. I'll watch from over here and see if this pans out for ya'll.

I can't speak from experience with regards to this particular approach, but I've worked with css-modules with webpack (css-loader), and debugging the class names is no problem at all, CSS source-maps point to the source, you can view the source code within your developer tools. It shouldn't really be any different than debugging Sass generated CSS, for example.

Re: CSS Modules

#87

Post by mangeletti »

crazygringo wrote: post #69
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 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…

Re: your comment and the others below

The variables argument is the only one I can truly get on board with. I really wanted variables. Find + replace in your editor for something like #fafaf0 isn't exactly error-prone or hard to do, so it wasn't ever a huge problem, but variables would have been very nice.

Pertaining namespaces, that's what the cascading part was made for. I had 4000+ line CSS files for large ecommerce websites where I had 5 different declarations of some classes (e.g., .item), but using proper selectors and understanding specificity meant never having a problem.

Pertaining large files, @import(...) always worked for me. For the most part, I'd use one large file (hence 4000+ line files mentioned above) because it helped with load speed, which did suggest that there was value in a build tool that would read @import(...) statements and pull those files into one large file after the fact. But this didn't mean we needed a framework with its own syntax, etc.... even today, tools like django-pipeline will pull in and combine CSS files for you, in the order given, so that you can write your files separately and have them combined after.

Pertaining z-index, I never had an issue with this, except with drop-down menus, but even then it was intuitive and consistent that the next element down will be 1 layer above the one directly above it, and it was also intuitive that nested elements' implicit z-indexes would be relative to their parents, etc.

Re: CSS Modules

#88

Post by Kequc »

christophilus wrote: post #72
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…

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.

The modifier I use is longer, but I might switch to is-, that seems like a nice convention.

Re: CSS Modules

#89

Post by namuol »

NathanCH wrote: post #77
talmand wrote: post #61

Earlier quoted context omitted.

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.

That so much CSS is "bad CSS" indicates that the problem isn't the craftsman so much as the tool...

Re: CSS Modules

#90

Post by talmand »

namuol wrote: post #89
NathanCH wrote: post #77

Earlier quoted context omitted.

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

That so much CSS is "bad CSS" indicates that the problem isn't the craftsman so much as the tool...

Ah, I see, so when I attempt to use a hammer as a wrench I can claim the hammer is a horrible tool.

CSS does exactly what it was designed to do and does it quite well. It only goes "bad" when people attempt to make it do things it wasn't designed to do. Blaming the tool for that is the sign of a bad craftsman.

Post reply on HN