Imagine this: you are reviewing someone’s CSS. Everything looks valid and has passed linting. Does that mean it’s ready for production? What are some other things you should be spotting before passing the code review?
In this talk, Fiona will show you how to spot some of the early symptoms of code smell and how you can make your CSS more robust.
CSS invites a love/hate relationship: it’s quick, easy and powerful but messy, unclear and “dark magic”.
When reviewing code, it can be hard to know what issues to look for and how to address them.
CSS linting helps in checking basic syntax, spotting errors and following predefined rules.
Build your own list of things to check for not covered by linting.
Stress test your user interface with different layouts, font sizes, screen sizes, element combinations.
CSS makes visual changes, so check how things actually look in browsers.
Developer toolbars can also spot problems.
Ultimately, be human, don’t expect tools to do your work and always question your own code.
Among the things that linting checks can be naming conventions, duplicate selectors, choice of units in sizing fonts, and a lot more.
Linting can in some cases be integrated to work with other tools to provide on-the-fly error advice.
Issues you should check for not picked up by linting can include:
- Code that is too long, vertically or horizontally, indicating unnecessary complexity.
- Selectors that are too long, overly specific and hard to edit later.
- Magic numbers that “just work” without explanation.
- Fixed heights, absolute positioning and other techniques that fail when layout changes.
- Legacy code using superfluous old browser prefixes.