Support custom CSS

[ks888]

Suggestion from @kaustubhmenon https://github.com/ks888/LambStatus/issues/14#issuecomment-363839917

Suggestion: Integrate a new CSS/SCSS file for manipulating the UI, without touching any core SCSS files. Could also be similar to Edit CSS in Wordpress (https://en.support.wordpress.com/custom-design/editing-css/)
. While inspecting the structure I noticed that all class names are appended with a random string in the end which could be a possible blocker for targeting CSS classes?

My reply: StatusPage.io also has a similar feature https://help.statuspage.io/knowledge_base/topics/using-custom-css . Though the css class has a random prefix since CSS modules are used, maybe we can let the principal UI components have the id attribute and customize the design like this:

#container {
    width: 90%;
    max-width: 850px;
}

[kaustubhmenon]

@ks888 Would it be possible not to use "CSS modules"? This would avoid any css targeting problems. Generally using ID' s(#) is not best way going forward because they causes problems with specificity (http://oli.jp/2011/ids/). ID's could cause potential targeting issues if the repo gets more functionality and features.

Why not use BEM instead to make sure that classes don't conflict. We have about 3 templates (Current Incidents / Incident History / Incident Main) and coming up templatized/logical class names would not be very difficult. I can definitely help with that :)

[ks888]

Good point! I agree with your idea to make templatized classes.

I think we can keep using css modules while making templatized classes. As this doc describes, css modules enable us to declare an explicit global selector with :global().

The BEM approach will work but I'm worried how many users are familiar with BEM. I also have no BEM experiences. So I feel the simple naming like .container may be better as wordpress.com and statuspage.io do.

[jagracey]

Great work so far @ks888. I wish I had found this last year.

At the risk of offering premature advice without finishing my own due diliegence of the docs, how about simply removing CSS Module content hashing? That still leaves a module name prefix so creating unique selectors should still be very reasonable- global() wouldn't in general, be needed.

The odd #ID lying around isn't an immediate problem, since you can increase specificity with redundancy (#ID#ID). It looks like the only IDs in use are from the SVG charts ($$('*[id]')).

The philosophy of BEM still is available to utilize, and save for [M]odifiers, appears to already be in use.

[ks888]

Thank you for your comment! If content hashing is removed, every css names can be overwritten. Then we will have a backward compatibility problem which makes the refactoring of the UI components difficult. I prefer offering a set of global css names which users freely can override.

[ks888]

Actually the AWS Cognito offers a set of customizable css classes:

background-customizable
banner-customizable
errorMessage-customizable
idpButton-customizable
idpButton-customizable:hover
inputField-customizable
inputField-customizable:focus
label-customizable
legalText-customizable
logo-customizable
submitButton-customizable
submitButton-customizable:hover
textDescription-customizable

Corresponding UI is: