Live data from Hacker News

Principles we use to write CSS for modern browsers

gist.github.com

71–80 of 129 posts

Re: Principles we use to write CSS for modern browsers

#71

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace. My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar. [1] https://github.com/css-modules/css-modules [2] https://github.com/vuejs/vue-loader/blob/master/docs/en/feat...

CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

It looks like CSS modules is meaningfully different from being just a naming convention.

With a naming convention, if you want to use work from two different packages and they happen to use the same names, you need to edit one of them. People come up with conventions to try to avoid this, like prefixing everything with the package name, but that doesn't fundamentally fix the problem. If two packages have the same name, they clash again. You have a fundamental tradeoff between short prefixes which are easy to work with, and long ones which are less likely to clash.

In other systems, when you use a package, you choose the prefix. If two packages use the same names, you just give them different prefixes. Short prefixes are fine, because they don't need to be globally unique.

It looks like CSS Modules works the second way, and that's an improvement over just being a naming convention.

Re: Principles we use to write CSS for modern browsers

#72
post #69

So, I don't do any front end work in my day-to-day, so this may be a stupid question. This article starts out with how CSS gets a lot of negativity. What alternatives are there? Do browsers understand anything but CSS for styling?

There isn't an alternative really. Like Javascript, it's all there is.

So are these other tools people are talking about some different methods that just transpile back to CSS in the end or something like that?

Re: Principles we use to write CSS for modern browsers

#73
post #67
post #7

Some thoughts: - Good CSS design needs zero !important statements. Fix your specificity or your component architecture if you have a need to use !important. - DRY is a good thing, not a bad thing. Maybe straight CSS isn't quite there yet but... - Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS? - Flexbox will be great once IE dies the well-earned death it deserves. I'm very ha…

Secretly, I'm not that happy with flexbox. I think it's more intuitive in some cases, but I don't think it's more intuitive than floats and the like. For example, I always feel like I want a `justify-self` property like `align-self`, but instead I must use `margin: auto` on the opposite side—in a flex row of elements, if I want the last one to be right aligned while the rest are hanging out in the center, I have to t…

I agree that flexbox isn't particularly intuitive. I visit the "Complete Guide to Flexbox" at least a few times a day.

The real strength is how little of it you have to write. The most complex layouts I have only take a few lines of flex and they're way more responsive than their non-flex counterparts.

Re: Principles we use to write CSS for modern browsers

#74
post #49

Earlier quoted context omitted.

I would love to read a long-form article about this if you're ever inclined.

I'm flattered, but I'm not sure I have much more to add! What would you expect to be explored more deeply in such an article?

I just haven't encountered this problem yet as a junior dev and would like to learn more. Perhaps it will just come with more experience.

Re: Principles we use to write CSS for modern browsers

#75

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace. My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar. [1] https://github.com/css-modules/css-modules [2] https://github.com/vuejs/vue-loader/blob/master/docs/en/feat...

CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

> CSS Modules is still a "naming convention," just one that is auto-generated for you.

Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.

Re: Principles we use to write CSS for modern browsers

#76

Earlier quoted context omitted.

My experience is that that ceased to be the case about a year ago. Now everyone also has Chrome.

Your experience isn't in healthcare, finance, military, manufacturing or oil and gas (to pop a few verticals off the top of my stack), it would seem. Literally 80% of my (adult, American-enterprise-employed) students in 2015-2016 so far have IE9 as their desktop standard, and have to beg for a special exemption to be allowed to install Chrome or Firefox.

Even Epic has dropped IE9 support AFAIK. That's a pretty good indicator to me that healthcare has moved off it.

Re: Principles we use to write CSS for modern browsers

#77

Earlier quoted context omitted.

Your experience isn't in healthcare, finance, military, manufacturing or oil and gas (to pop a few verticals off the top of my stack), it would seem. Literally 80% of my (adult, American-enterprise-employed) students in 2015-2016 so far have IE9 as their desktop standard, and have to beg for a special exemption to be allowed to install Chrome or Firefox.

Besides military (haven't done that in 10+ years), I'm in all those other verticals and more. All desktops now have IE11 (because MSFT pretty much says "you must") and Chrome.

I wasn't speaking figuratively when I said literally, you know. :)

It's a breath of fresh air when an enterprise student has a modern environment. But it's enough of an outlier (in my experience teaching all these different places) to still surprise me to hear when it's true.

Re: Principles we use to write CSS for modern browsers

#78

Earlier quoted context omitted.

Your experience isn't in healthcare, finance, military, manufacturing or oil and gas (to pop a few verticals off the top of my stack), it would seem. Literally 80% of my (adult, American-enterprise-employed) students in 2015-2016 so far have IE9 as their desktop standard, and have to beg for a special exemption to be allowed to install Chrome or Firefox.

I've done those verticals, too. We always had Firefox. I don't know what it's like now. That was 10 years ago. (AKA sit down and shut up with your bullshit "sit down and shut up"s)

I literally deal with students in every class, a not-small percentage of students, that are disallowed by domain policy from installing another browser.

Re: Principles we use to write CSS for modern browsers

#79
post #28

".ComponentName-descendentName" nested inside ".ComponentName"? Remember kids, the cascade is TEH B4DZORS - so always include everything you would have gotten from it in every class name. headdesk Solidly delivered on the "no DRY" premise. Maybe they should coin a new acronym like "WET": "Write Everything Thrice"

We Enjoy Typing is the explanation I usually see.

Re: Principles we use to write CSS for modern browsers

#80
post #75

Earlier quoted context omitted.

CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

> CSS Modules is still a "naming convention," just one that is auto-generated for you. Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.

And it fixes a few other unexpected problems as well.

We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application.

When I saw it happen the first time, it really kind of cemented in the idea that this combined with a way to "punch through" the modularity to combine and extend "base" classes and include global colors (for us it's SASS imports) has pretty much "solved" CSS for me.

Post reply on HN