Here’s a neat idea from Tim Kadlec. He uses the Modheader extension to toggle custom headers in his browser. It also lets him see when images are too big and need to be optimized in some way. This is a great way to catch issues like this in a local environment because browsers will throw an error and won’t display them at all!… Read article “In-Browser Performance Linting With Feature Policies”
Many developers write about how to maintain a CSS codebase, yet not a lot of them write about how they measure the quality of that codebase. Sure, we have excellent linters like StyleLint and CSSLint, but they only help at preventing mistakes at a micro level. Using a wrong color notation, adding a vendor prefix when you’re already using Autoprefixer, writing a selector in an inconsistent way… that kind of thing.
We’re constantly looking for ways to improve the … Read article “In Search of a Stack That Monitors the Quality and Complexity of CSS”
In this week’s roundup, variable fonts get oblique, a new browser extension for linting, and the very first version of CSS Modules.… Read article “Weekly Platform News: CSS font-style: oblique, webhint browser extension, CSS Modules V1”
It sure is nice having a whole codebase that is perfectly compliant to a set of code style guidelines. All the files use the same indentation, the same quote style, the same spacing and line-break rules, heck, tiny things like the way zero’s in values are handled and how keyframes are named.
It seems like a tall order, but these days, it’s easier than ever. It seems to me it’s become a two-tool game:
- A tool to automatically fix easy-to-fix
I bet you have a style that you write CSS in, for the most part. You like 4-spaces, say. You always have a space after braces and colons. You always put a space after rulesets. You only ever put one declaration on a line, and the only declarations that can be multi-line are when they are big blocks like a gradient or a comma-separated box-shadow.
You might take this a little further and codify this. Perhaps you have a team … Read article “Enforcing CSS Syntax Style (and more!)”
You write CSS. Probably a lot of CSS. And you make mistakes. Probably a lot of mistakes. Somebody needs to stop you from making mistakes in your CSS.
Sometimes your mistake is a real bug. Sometimes it’s just sloppy, inconsistent, or unclear coding style. Some of them may seem trivial at first (depending on your temperament), but they become patently important as the codebase grows and ages, as more people stick their hands in it and do ugly things. Things … Read article “Lint your CSS with stylelint”