uppy.io/examples - stop css from affecting uppy

[lakesare]

Fixes transloadit/uppy#4439

Makes headings normal-sized & fixes heading font issues

Before

After

Removes double shadow

Before

After

Increases right-margin for checkboxes

Before

After

---

In general, in CSS, changes:
all tag references (e.g. h1),
to unique class references (e.g. .h1_src-pages-examples-module).

Hopefully that makes the "Uppy CSS is broken on examples page" issue appear less frequently.

[Murderlon]

I don't think this is the correct solution. It should not be possible to override the CSS of Uppy with simple selectors like .main h1. We should build protections into Uppy to prevent this, either with specificity and uppy-reset class as we've been doing or the more ambitious undertaking of using cascade layers.

We can merge this as a quickfix, but it will just make us blind the problems other users are still facing.

[lakesare]

There are 2 solutions in this pr:

• not targetting <section>s in uppy.io css
  I think we agree that removing .section css rules in uppy.io is the correct solution here.
  Noone targets .sections on a page on production sites; if we were guarding against that we'd need to add .clear to every div in uppy. This would just complicate style overrides.
• not targetting <h1> in uppy.io css
  Kind of agreed with yours/artur's comment wrt the <h1> part, I was on the brim here.
  It is indeed frequent for people to apply font changes to semantic elements site-wide, and it is a sensible thing to do.

No need for a quickfix merge, I'll revert the "uppy.io/examples - make font alright too" commit in favor of making Uppy more robust against outside css.

[lakesare]

but it will just make us blind the problems other users are still facing.

I don't think we should treat uppy.io page as our testing ground for "what css issues users might be having".
What happens again and again is our demo css gets fucked up, and then it takes months to get a fix in, because it's just not a high-priority issue.

If we think it's important then we should add h1/etc. styles to dev/Dashboard.js to make sure in development that Uppy defends against that.

So, I think the default behaviour when editing out uppy.io css should be to use high-specificity selectors, e.g. classes, like standardized in this pr (h1 is an exception, because outside framework is bringing that in for us - and because it is indeed good for Uppy to defend against that).