Best practices for eRegs theming #410
Description
This issue is related to #358, but covers topics beyond just templates. The goal is to discuss and come to some agreements on best practices. After that, I hope we can break out some additional issues to implement the practices we agree on.
Also, I should point out that my perspective comes from theming fec-eregs which is significant theming beyond eRegs' goals for theming. I hope that we'll find these practices make the light theming easier as well.
Versioning regulations-site
fec-eregs is basically doing it's own versioning of regulations-site today to
avoid an upstream change breaking our layout. We fix our requirements.txt to
a particular commit of regulations-site, and rev it every once in a while.
If regulations-site was versioned based on compatibility using major, minor,
and patch numbers, then it would be easier for us to evaluate the work involved
in bumping regulations-site.
Also, once we have versions, we can think of our templates and blocks available
as an API that we need to support. This helps us communicate and specify
a contract around what is customizable or not.
Avoid global element styling
Use classes so they can be extended, overridden, and most importantly, removed from
HTML. This avoids having to write overrides to styles which can change from
version to version of regulations-site. Currently there are styles on button and ul among others.
Adopting convention for CSS
The Block Element Modifier is
recommended by the Front End Guild for CSS. This lends itself well to adding
modifier classes which extend the styles of existing components while keeping
specificity low and predictable.
@cmc333333 mentioned he's not a fan of BEM-style naming, but some kind of convention would be helpful. Names are less important than the concept of structuring CSS rules using blocks, elements, and modifiers.
Consider namespacing the CSS classes
For example .eregs-disclaimer preferred to .disclaimer. This makes it easier to play with other frameworks. I'm trying to use styles from fec-style, but occasionally there is a collision, like .disclaimer or .panel. LESS/SCSS @extends can be used to work around some of these issues.