systematic-css

You'd do this:.list {color: hsl(0, 0%, 27%);font-size: 1.2rem;list-style: square inside;margin: 0 0 1em;}.nav-list {font-size: 1rem;}There are many good things to be said for this approach. If we use classes as the exclusivecontract between HTML and CSS we will benefit from very granular control over thepresentation of individual bits of our design. Our CSS selectors will be less dependent uponparticular HTML structures, allowing us to change much more HTML before triggering widerCSS refactoring. And we will rarely need to unwind unwanted inherited styles, because elementtypes need be given very few default properties.Some would argue that greater dependence on classes increases the couplingbetween HTML and CSS. This is wrong. Classes are intended exactly for thispurpose. Classes are an abstraction layer linking two separate concerns, theequivalent of hooks in event-driven programming.But the class-based approach is far from perfect. We end up with HTML documents that areriddled with classes. And because we're bypassing much of the cascade we don't benefit fromthe convenience and efficiency of the CSS inheritance model. Plus class-based designs tend tohave a lot more rulesets overall, giving browsers more work to do to resolve the final styling ofeach element.And how far should we take this approach, really? Is it sensible to apply classes to everyparagraph, every list and every image, just to get some default styling in place? Should we goeven further and strip default styles from elements like , and ? Of course not.That's utterly impractical.There is a balance to be found between harnessing the benefits of the cascade by assigninglots of default properties for lots of elements, and locking things down by using classes as theprimary API linking HTML to CSS. The sweet spot between these two extreme approaches willThe principles of good CSS 7