[WIP] CSS section style/language overhaul #211
Conversation
| - Magic numbers (when you absolutely cannot avoid using them) | ||
| - Overrides of imported frameworks like USWDS | ||
| - Rules that must be used in conjunction with one another | ||
| (using BEM naming conventions is somewhat self-documenting in this regard) |
There was a problem hiding this comment.
I'd welcome any additions to this list!
There was a problem hiding this comment.
Top level components you create, to leave a note of what they are, how they're used, any a11y concerns, etc.
|
|
||
| Originally, 18F hired for two distinct varieties of front-end work: design and | ||
| development. 18F no longer separates the two to diminish administrative | ||
| repetition, rather, all front-end work is now called front-end development. |
There was a problem hiding this comment.
I'd also love some eyes on this paragraph.
| - Is it mature and currently supported? | ||
| - Does it support older browsers and provide fallbacks for newer techniques when necessary? | ||
| - Is the library size reasonable? | ||
| - Do other developers and designers on your team know how to work with this framework? |
There was a problem hiding this comment.
Do these seem reasonable? What else should go in this list?
There was a problem hiding this comment.
I'm of the opinion that we should revamp this list to strongly suggest starting with the USWDS unless you have really compelling reasons not to, and to strongly suggest NOT introducing Yet Another Framework. Even in the cases where BassCSS has been used already, I know there's been a fair bit of follow-up discussion wondering why it was essentially reproducing USWDS. If we think is the right basis for the front-end on government sites (and I think that's safe to say) then I think we should be a bit firmer in that opinion.
|
|
||
| ### Example | ||
| The original KSS repo is not maintained. There are numerous forks that are |
There was a problem hiding this comment.
Is it accurate to say that it is not maintained? Is it not updated because it's abandoned, or because it's mature and needs little to no updating?
There was a problem hiding this comment.
The last update was 5 years ago, and other projects have forked it to implement their own versions. Smells unmaintained to me, but I'm down for tweaking the language!
There was a problem hiding this comment.
How about something like "While the original KSS repo has not been updated in several years, community development has continued in forks and it remains one of the most used CSS documentation tools"
Co-Authored-By: hbillings <[email protected]>
Co-Authored-By: hbillings <[email protected]>
hbillings
changed the title
… more-timeless-guidance
|
|
||
| ### When to use mixins | ||
|
|
||
| - Use mixins for groups of properties that appear together intentionally and are used multiple times. | ||
| - Use mixins for components to change size. |
There was a problem hiding this comment.
I actually don't know what this means. Anyone care to clarify?
There was a problem hiding this comment.
I don't either. I think this is trying to quickly explain why inheritance is great, but that really just comes down to "use mixins when you're repeating yourself a lot" and I don't think a lengthy explanation is probably necessary here... I think most people who are decent with CSS are already really aware of repeating themselves and inherited/cascading effects in general. So I like your addition, but would probably strike the "change size" bit. I think the bigger issue is the difference between include and extend, which is tricky to understand and has huge implications to the final CSS
This is an experiment to see if it's possible to rewrite some of our existing guidance in a way that goes out of date less easily. Also reorganizes the CSS section to be guidance and style guide sections, rather than calling the entire thing a style guide (which it isn't). This reorganization does mean that sometimes we talk about things in multiple places (i.e., the how is separate from the why, but they should link to each other), so we should talk as a group about how we feel about that.
Open questions: