Principles we use to write CSS for modern browsers
gist.github.com
Principles we use to write CSS for modern browsers
1–10 of 129 posts
Re: Principles we use to write CSS for modern browsers
#2A 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 can affect the importance of these.
The project's complexity, rate of change and lifespan is also a factor that might push you one way or the other.
But anything that helps one of these harms the other.
Thoughts?
Re: Principles we use to write CSS for modern browsers
#3A bit meta, but I need this off my chest: I love how this document starts off saying "this is for react apps". IMO every discussion about CSS coding standards needs to start with context.
A lot of old CSS lore came from people who build websites. I mean those fairly uninteractive things, focus on content. Blogs, restaurants, newspapers.
Building an application that happens to use the DOM as their UI toolkit is totally different. The whole "reuse the same classes but with different content" thing that CSS classes were designed for becomes less important, and "reuse pieces of behavior" makes a lot more sense.
There's probably more domains or subdomains that warrant their own CSS best practices. But I'm totally tired of a blog designer and a react app coder fighting on HN about how the other one is doing it wrong, when really they're just solving different problems.
Re: Principles we use to write CSS for modern browsers
#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.
Re: Principles we use to write CSS for modern browsers
#5I agree with the Flexbox and DRY principles, but it's weird to still rely on arbitrary naming conventions like SUIT when CSS modules have been around for a while now.
Naming things has always been difficult, especially in CSS where it can lead to merging/overriding/precedence issues. Not having to think about what CSS class names are either available or possibly conflicting is a benefit from CSS modules that increases productivity by an order of magnitude I've rarely seen in CSS, especially in large codebases.
You've got a button and want to call it "button" and style it using ".button"? Go ahead. It will only inherit styles if you explicitly say so. The global namespace remains healthy for each component you write.
Re: Principles we use to write CSS for modern browsers
#6> 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.
This largely depends on your target audience. Flexbox is only problematic for IE But this should always be checked against more relevant stats (your country, old website you're redesigning, etc.), so yeah, if you know you have a lot of people on IE9 and lower, flexbox is out of the question.
Re: Principles we use to write CSS for modern browsers
#7Some 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 happy the author had great success with their setup. What works, works. But I hesitate to assume that just because it works without using DRY principles or other tooling, it means you shouldn't.
Re: Principles we use to write CSS for modern browsers
#8> 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.
Flexbox is supported in all versions of IE that Microsoft themselves still support (IE 11 and up). You can still support it in IE10 too, albeit with a different syntax.
That means even windows installations that haven't been updated since 2012 will support flexbox.
Re: Principles we use to write CSS for modern browsers
#9> 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.
Flexbox is supported in all versions of IE that Microsoft themselves still support (IE 11 and up). You can still support it in IE10 too, albeit with a different syntax. That means even windows installations that haven't been updated since 2012 will support flexbox.
CanIUse reports bugs in IE11. Anyone had issues in day-to-day development?
Re: Principles we use to write CSS for modern browsers
#10> 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 scenario, you can provide old IE with a more mobile-like experience and just let things stack up.