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

Principles we use to write CSS for modern browsers

gist.github.com

Post reply on HN
Print view View original

31–40 of 129 posts

Re: Principles we use to write CSS for modern browsers

#31

Post by spdustin »

freshyill wrote: post #10
davedx wrote: post #4

> Flexbox is awesome. No need for grid framework; Yes, great, if you can ignore all the IE users. Is that what "modern" means? I'd love to use flexbox where I work, but it's just not feasible to give up all the customers we would lose.

Why not both? Global flexbox support is >96% and in the US it's >97%. Unless you're aiming for a 1:1 pixel-perfect experience in crappy old versions of IE, it's negligibly simple to detect IE (or lack of flexbox support), and just use something else. You can usually get pretty close to a lot of flexbox layouts with display: table and related properties, and also falling back to floats for others. In a worst case scen…

Enterprise in the US. IE9 still rules, in many cases. I actually work all over this space, do not tell me otherwise. And now I have to maintain two codebases?

Re: Principles we use to write CSS for modern browsers

#32

Post by brunoc »

andybak wrote: post #2

A random brain dump prompted by this statement: "No DRY. It does not scale with CSS, just focus on better components" All programming involves resolving a conflict between two different principles and a lot of the fiercest disagreements are between people that weight the importance of these two things differently: 1. Reducing repetition 2. Reducing dependencies and side effects The language and it's tooling/ecosystem…

That's consistent with my experience with a very DRY Sass library. If the consumer needs flexibility, such as different themes or new context for components it quickly becomes impossible to manage dependencies and abstraction begin to leak.

CSS tooling is quite rudimentary, too, which doesn't help.

Re: Principles we use to write CSS for modern browsers

#33

Post by vinceguidry »

davidkpiano wrote: post #30
MatekCopatek wrote: post #14

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.

Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.

Re: Principles we use to write CSS for modern browsers

#34

Post by vinceguidry »

spdustin wrote: post #31
freshyill wrote: post #10

Earlier quoted context omitted.

Why not both? Global flexbox support is >96% and in the US it's >97%. Unless you're aiming for a 1:1 pixel-perfect experience in crappy old versions of IE, it's negligibly simple to detect IE (or lack of flexbox support), and just use something else. You can usually get pretty close to a lot of flexbox layouts with display: table and related properties, and also falling back to floats for others. In a worst case scen…

Enterprise in the US. IE9 still rules, in many cases. I actually work all over this space, do not tell me otherwise. And now I have to maintain two codebases?

Your problem is actually simpler than if you had to maintain modern consumer-facing web apps, which have to deal with users across three broadly-defined screen sizes and a variety of mobile APIS. If you're serving the enterprise, then you can make assumptions about your audience that greatly simplify development.

Re: Principles we use to write CSS for modern browsers

#35

Post by vog »

al2o3cr wrote: 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"

I propose to name it the "wet-wet-wet" principle.

Re: Principles we use to write CSS for modern browsers

#36

Post by spdustin »

al2o3cr wrote: 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"

> "Write Everything Thrice"

Solid. I'm using that in my class today.

I love React, and even there, I only style components in the way they need to be styled, and not with any other brand-specific styles. Those go in the good ol' fashioned CSS with "gently nested" CSS selectors. The enterprise world is considerably more nuanced than many SPA devs understand.

A class of folks from US Gov, manufacturing, pharmaceutical and finance industries (to roll them into general groups) and every one of them answers "IE9" when asked what browser they have to support, and every one of them is at home with "the old ways" of writing CSS, by embracing the cascade.

It's not that they're wrong. They're pragmatic.

And, In some cases a little bitter, I'll grant you. ;)

Re: Principles we use to write CSS for modern browsers

#37

Post by shabda »

daurnimator wrote: post #21
ulkesh wrote: 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.

Both the tools mentioned above LESS/SASS have been for 5+ years. There is churn in frontend tooling, but it is not a valid reason for not using LESS.

Re: Principles we use to write CSS for modern browsers

#38

Post by spdustin »

vinceguidry wrote: post #34
spdustin wrote: post #31

Earlier quoted context omitted.

Enterprise in the US. IE9 still rules, in many cases. I actually work all over this space, do not tell me otherwise. And now I have to maintain two codebases?

Your problem is actually simpler than if you had to maintain modern consumer-facing web apps, which have to deal with users across three broadly-defined screen sizes and a variety of mobile APIS. If you're serving the enterprise, then you can make assumptions about your audience that greatly simplify development.

Those assumptions are nowhere near as simple as you think when you are in a space that supports a large majority of all enterprise. You would shudder to see what real-world browser support is like when you write software to be used in that space.

Re: Principles we use to write CSS for modern browsers

#39

Post by t4nkd »

daurnimator wrote: post #21
ulkesh wrote: 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.

Usually this kind of attitude could be justified even if it was just a shitty anecdote, but with SCSS and LESS in particular I'm afraid you've chosen long lived, bulletproofed software that has tremendous adoption and community. Neither would be what anybody would call "the tool of the month".
Post reply on HN