The styleguide is lookin' real good, but there are still a number of points we need to discuss as a team. Let's try to come to a consensus on these things so we can get this styleguide completed and pushed out as soon as possible.

• Perhaps we should expand on "State" classes. What about something that is "in-between" states? Do we do anything in the admin that would resemble: --is-off > --is-animating-in > --is-on > --is-animating-out... Generally, I try to avoid this, and often rely on a animation/transition event listener to toggle classes as a callback - but I'm not sure if we are doing that anywhere in the admin either.
• I feel like "Layout subcomponents" could use a bit more elaboration. Why is this good / bad?
• I would argue that Psuedo-classes such as :hover, :active, and :focus (move these out of psuedo-classes and consider them psuedo-styles?) should come after Psuedo-elements (if not at the very end of our ordering). Example: often a psuedo-element will need to respond to the :hover of its parent. Isn't it more organized to wrap all of that up in a single declaration?
• I think our "Notes" direct comments should indicate that it is a note. So, // note 1 instead of just // 1... reason being, if the line where flex: 0; // 1 someone could read that as "this value was originally 1... I wonder why they changed it?" Should probably discuss comment style further with the team.
• Naming conventions for mixins or functions.
• Expand on the Size units?
• SASS map for colors? Dom is already experimenting with this - could be incredibly useful!
• How about a map for z-index? What would this look like? Trying to wrangle our stacking context can be a house of mirrors - make it easier to keep track of and shepherd FEDs towards a cleaner implementation.
• Should we lock font-weight into a variable? ($fontweight--semibold, $fontweight--bold, etc), that way people don't do stupid shit like: font-weight: 200; "cuz I likes it thin".... easily disputable - anyone who writes a style like that probably doesn't care what our variables say anyways :(
• What are our thoughts on utility classes? Should these be prefixed with something? ex .util-something
• Is there too much "assumed knowledge" in the way our style guide is written? Is this a concern? Would we rather only hit the main points and be as succinct as possible, or go into more detail as to cause/effect, philosphy, etc?