Live data from Hacker News

Principles we use to write CSS for modern browsers

gist.github.com

51–60 of 129 posts

Re: Principles we use to write CSS for modern browsers

#51

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.

I agree with vinceguidry's comment.

Perhaps I wasn't clear - of course you should be careful about naming things well (one of the hardest problems in CS, right? :P), but using consistent terms, case and the like is one thing.

A large part of CSS naming conventions is doing more convoluted stuff such as business-page__contact-form__submit--disabled, just because there are other submit buttons on your website and you don't want some styles to clash. This is the part that is abstracted away by automatic solutions.

If your favorite programming language scoped all variables globally, no matter where you defined them, sure you could prefix them with the name of the current function to solve your problem, but it'd be painful and error prone.

Re: Principles we use to write CSS for modern browsers

#52

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

What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation. This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other progr…

That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react!

EDIT: why the downvotes?

Re: Principles we use to write CSS for modern browsers

#53

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.

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)

Re: Principles we use to write CSS for modern browsers

#54
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…

> - Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS? Because there is so much tooling churn + barrier to entry. The point is that sometimes it's better to repeat yourself than to use the tool of the month.

If you're using React but not LESS or SASS then you have a strange attitude to "tool of the month" but it does explain antipathy towards DRY.

Re: Principles we use to write CSS for modern browsers

#55
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"

CRY: Continuously Repeating Yourself

WET: Write Everything Twice

Credit: https://roots.io/sage/docs/theme-wrapper/#fn2

:)

Re: Principles we use to write CSS for modern browsers

#56

Recently I got into functional CSS: https://github.com/chibicode/react-functional-css-protips

At that point you might just go full css-in-js and embrace inline styles.

I'm not sure which is worse:

A) having twenty classes on each element, each doing only one or two things

B) having twenty classes overlapping on the same one or two things

Re: Principles we use to write CSS for modern browsers

#57
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…

Avoiding !important is generally very good advice, although the ZOMG NEVAH! approach is a bit overzealous IMHO.

One good example would be overriding random external styling (e.g. an included CSS file some plugin you use). If their stylesheet has very long and specific selectors, you can either repeat them entirely (#plugin .container .subcontainer .input-wrapper.input-wrapper-blue input[type=text]:first-child) or stay within your general selector-writing practices and use !important instead. I'd argue the latter is a better practice.

Re: Principles we use to write CSS for modern browsers

#58

Earlier quoted context omitted.

What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation. This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other progr…

That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react! EDIT: why the downvotes?

They're quite rationally looking for assignments that increase their own market value.

Re: Principles we use to write CSS for modern browsers

#59
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…

Avoiding !important is generally very good advice, although the ZOMG NEVAH! approach is a bit overzealous IMHO. One good example would be overriding random external styling (e.g. an included CSS file some plugin you use). If their stylesheet has very long and specific selectors, you can either repeat them entirely ( #plugin .container .subcontainer .input-wrapper.input-wrapper-blue input[type=text]:first-child ) or s…

I agree with respect to 3rd party libraries. One of the things I hate most about Bootstrap is its amazing overuse of !important.

However, my context was mainly around architecting your own CSS, not as it relates to using someone else's.

Re: Principles we use to write CSS for modern browsers

#60
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…

I'm surprised there is no polyfill-like thing for flexbox, or is there?
Post reply on HN