Points of discussion moving forward

[beefchimi]

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?

[ry5n]

I have a couple of macro concerns. Some of these are informed by my being new.

1. What are the problems the new style guide is solving?
2. Who is the audience? FED, or everyone working with the front-end?
3. Does it make sense for this to be just about CSS?
4. I have some experience with the original this was forked from. IMO it’s tooooo biiiiiig. Where can we trim some fat? What does the TL;DR look like?

[ry5n]

Some other random thoughts (micro-stuff, mostly):

• Pseudo-classes are part of State; I agree with @beefchimi they should come after generated content;
• My personal preference is for State classes always being appended to the main class, which means they can look like this: .text-field.is-invalid; this makes state classes more distinguishable from modifiers and uses the extra specificity to make sure the styles apply across modifiers.
• There is probably too much assumed knowledge. The guide is gigantic, and it starts out by saying you should already know about SMACSS, BEM etc. These should rather be “further reading” at the end.
• We should be careful about recommending utility classes at all. If we do, we may need a way to control their application across breakpoints. if we use them, I prefer a u- prefix.
• What is the reason for layout sub-components? (I can guess, but a) it should be given in the guide, and b) I’m not convinced it’s needed.
• Are maps for variables really a good idea? I quite dislike the map syntax (it’s verbose), and it adds complexity.

[beefchimi]

Excellent points @ry5n !

I think overall, we just want to have an updated style guide that is accurate and leaner / easier to parse. There are some key things we want to think about and enforce moving forward, such as what kind of quotes to use, what comments look like, variable name syntax, property order, etc. Putting together a new style guide helps us align our vision.

The audience would be mainly Shopify FEDs, but its of course useful to anyone who has to implement front end code. Until our numbers grow further, there are still non FEDs who have to do FED work - as is the current situation on the Platform team.

I believe we should isolate our style guides to each language. Makes looking things up easier - in my opinion. After all, one of your comments was that this is tooooo biiiiiig. I would say its less intimidating when it stands on its own. I could be wrong though - I don't have particularly strong opinions about putting everything in one spot or having it stand on its own.

I completely agree with your "micro-stuff" points. And yea, I was pretty against sass maps for that exact reason... but in the case of colors, I actually think it is really useful. This is a decent article, but @dfmcphee was working on his own concoction. Worth getting his input on this.

[ry5n]

Thanks for the background on goals and audience. Super helpful!

A Guide for each language actually does make sense, just wanted to confirm – the component-based approach does mean we’re touching on architecture, which I think is fine.

Finally, re: Sass maps and colours… I discussed it briefly with Dom. @beefchimi do you want to discuss that (and all the discussion points) here, create separate issues, or something else?

[beefchimi]

I think it would be cool to split out conversations on individual topics to their own issue - that way we can really drill down on an idea and not pollute this thread, which is more of a general roadmap/ideas thread. Feel free to create an issue to discuss SASS maps or anything else on your mind!

[dfmcphee]

Thanks for the feedback, this is all great. I created a new repo and I will create separate issues for each of these to continue the discussion.