CSS-Rewrite: Documentation and component importing

[ninjaofawesome]

OVERVIEW

In this branch I:

• updated the readme
• added pertinent partials to base.scss
• updated normalize

NOTES

• I'm not sure we need to import the mixins, as per Quartz's setup. Included but commented
• I think we could eliminate base.scss in favor of core.scss serving the same purpose, but will do in a separate ticket.

[sebastiansandqvist]

Can you change the base branch from master to css-rewrite? Hard to tell what changed otherwise

[sebastiansandqvist]

I think that you can exclude all the coverage stuff maybe besides index.html. You will never be touching any of this since it's generated, and if nyc which generates the coverage reports changes its implementation, we'd need to change our docs, so this could very quickly be out of date.

[ninjaofawesome]

Cool, will remove. Thanks!

[sebastiansandqvist]

Whenever you're looking at code coverage, even for a specific component, you'll just open coverage/index.html

[sebastiansandqvist]

I'm weary of copying and pasting many of these from the current quartz. For one, there's not a lot of BEM in here. Secondly, this enforces the kind of thing that often makes components hard to implement, which is code like this:

.form {
  fieldset {
    &.inline {
      label, .inner-button, input {
        display: inline-block;
      }
    }
  }

I'd rather have something like:

.form--thing-foo {
  display: inline-block;
}

Because otherwise it's really inflexible. ie. you must have a .form with a <fieldset class="inline"> containing a <label>.

[ninjaofawesome]

I agree, but there's A LOT that's coming from quartz, to bem-ify everything might take awhile. Could we consider this a first pass and refactor those to bem next, or should we prune out what we're not really using presently?

[sebastiansandqvist]

Since everything we're doing is incompatible with existing quartz anyway, there's no harm in building up from nothing and tailoring specifically to these components

[sebastiansandqvist]

Since this .inline exists, that entire code block I commented on above is actually unnecessary. Instead of

+.form {
+  fieldset {
+    &.inline {
+      label, .inner-button, input {
+        display: inline-block;
+      }
+    }
+  }

which only adds inline-block, this class .inline is sufficient. By adding the css piece-by-piece we can get rid of a whole lot of unnecessary rules.

[ninjaofawesome]

Perhaps we should audit all the files that we should include for now, all of this is from the existing Quartz CSS. :)

[sebastiansandqvist]

Looks great! Merge please!

[ninjaofawesome]

@sebastiansandqvist I "bemified" text.scss for review, but I think this is now starting to get into scope creep. However, I have some questions/ideas of what we could do, could be an interesting conversation.

[erikmoldovan]

Heyo. What's left to do before merging? @davegonzalez @ninjaofawesome @sebastiansandqvist

[sebastiansandqvist]

A lot! @ninjaofawesome suggested we have a meeting to discuss in person and I agree we should.

[sebastiansandqvist]

Oops, just to clarify, a lot to do on CSS prior to merging into master but this is totally good for the integration branch IMO. @ninjaofawesome feel free to merge to that branch any time!