2022-11-24
1787
#css
Daniel Schwarz
141822
Nov 24, 2022 â‹… 6 min read

What should a modern CSS boilerplate look like?

Daniel Schwarz Previously, design blog editor at Toptal and SitePoint. Now I advocate for better UX design alongside industry leaders such as Adobe, InVision, Marvel, Wix, Net Magazine, CreativeBloq, CSS-Tricks, and more.

Recent posts:

How To Implement View Transitions In Multi-Page Apps

How to implement view transitions in multi-page apps

Enhance navigation in multi-page apps using the View Transition API, CSS, and JavaScript — no heavy frameworks needed.

Rob O'Leary
Jan 31, 2025 â‹… 12 min read
net maui 9 blazor

.NET MAUI 9 brings new improvements to Blazor

Developers can take advantage of the latest release of .NET MAUI 9 to build better user experiences that more accurately react and respond to changes in their applications.

Andrew Evans
Jan 30, 2025 â‹… 6 min read
Implementing React Islands In Static Web Applications

Implementing React Islands in static web applications

React Islands integrates React into legacy codebases, enabling modernization without requiring a complete rewrite.

Nelson Michael
Jan 28, 2025 â‹… 4 min read

Onlook: A React visual editor

Onlook bridges design and development, integrating design tools into IDEs for seamless collaboration and faster workflows.

Jude Miracle
Jan 27, 2025 â‹… 8 min read
View all posts

2 Replies to "What should a modern CSS boilerplate look like?"

  1. I totally disagree with most of your ideas.
    Changing the box-model is something I really wouldn’t do. I get that it can be a bit of a challenge to get your head around the standard box model at first, but once you get it has at least as many pros as it has cons, and as it is the standard way, it makes your CSS a lot more understandable for others that might have to work with it at some point.
    Valuing your own design over the needs of users, as you do with disabling borders and even worse outlines, is plainly rude and selfish. (That you try to be clever about t it by using focus-visible shows, that you are not totally ignorant. It might make it even worse though, as a lack of knowledge might be an excuse for a lack of wisdom…)
    You can do this for each element you actually carefully design and where you do offer good accessibility alternatives – I do it all the time. But you can never know if your client or her nephew at some point in the future will install a plugin that shows crucial elements that you made inaccessible with your laziness.

    Changin the root font-size because you want to make it easier to calculate things, that most likely should be handled totally differently (ever heard of CSS custom properties?) seem just foolish. Also, code examples with unitless values for font size or with? Really?

    Even if some of the standards of the web are disputable, your ‘solutions’ for the most part are worse.

Leave a Reply