Skip to content
This repository has been archived by the owner on Apr 4, 2023. It is now read-only.

Best practices for eRegs theming #410

Open
adborden opened this issue Jun 10, 2016 · 0 comments
Open

Best practices for eRegs theming #410

adborden opened this issue Jun 10, 2016 · 0 comments

Comments

@adborden
Copy link
Member

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.

cc @cmc333333 @xtine @annalee @donjo

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant