Level Component (née List Item, née Flex Utilities)

[francisrupert]

Task

• [x] Research
• [x] Design
• [x] Prototype (via SPAR)
  • [x] Base
  • [x] Responsive Scopes (i.e. fsa-level@m)
  • [x] Stress
• [x] Build for Production
  • [x] Variations / States
• [x] Examples To be included as part of https://github.com/USDA-FSA/fsa-design-system/issues/316 (examples moved to Gist
• JavaScript Demo (if applicable)

What

A flexbox-based, utilitarian component to enable simple horizontal arrangement of [things].

e.g....

[francisrupert]

Here's a very brief idea of Usage for this component, particularly distinguishing from Grid System.

Use When	Don’t Use
Small-scale layout tasks control components along a level row	For complex or unique arrangements of components; consider using Grid System
Vertically center two or more adjacent elements or components	For large-scale page layout; consider using Grid System

[francisrupert]

@bignamehere,

I’d like you to review the working prototype for this feature. The general idea is summarized well enough in this Issue’s initial post.

This complements, and doesn't replace, the Grid System, which alone isn’t sufficient or convenient for simpler needs to compose together multiple [things] in a horizontal row.

I’ve been testing it within the Reference App in a variety of cases, and I’m feeling pretty good about it. The main thing I’ve yet to do is add Responsive Scopes to it (using the same @bp namespace proven successful in other areas.

Take at look at this Codepen to explore, backwards-engineer, stress-test, and provide feedback on its usage.

[bignamehere]

@francisrupert looking into this a bit more, I believe I understand the difference between the Grid System and the Level. First of all, the documentation will need to outline the difference between a component and a layout. Layouts are a higher order tier in Atomic Design, so I think we can explain it in a way where the Level organizes a small set of controls, where a Layout organizes an ecosystem or features. At least that is how I understand it. Also, it seems to only affect a single "row" of controls, so that distinction can be made as well.

[bignamehere]

@francisrupert After reviewing the examples, it initially felt like one component was trying to do too much, and this might overwhelm the User.

Questions I have...

• Are there any variations that can be broken out into its own component, such as the first one with Mr. Murray, for example a Card component that uses these types of layouts as Card variations. The Murray example that uses a Level within a Level seems odd or like China Doll layouts.

• The use of padding and spacing has always seems complex to me, and it looks like we are just replicating Tailwind.css. This is fine, but is there an easier way for a User to implement lines of code like fsa-box fsa-box--bw-0 fsa-box--br-2 fsa-p--s?

• It seems like --align-baseline should align the containers, and not the text. Aligning text seems to need a very specific name for Users to understand, such as --align-text-baseline.

• Lastly, are the --gutter-[size] portions something that should be a separate utility class (I think they should), and not baked into the component itself? The documentation can show an example of how it is used, but maybe gutter-[size] should be a global in scope and not a variations or "property" of a component.