converts sass to utility classes on global nav

jduss4 commented 4 weeks ago

Changes proposed in this pull request:

utilizes uswds utility classes instead of mixins in Sass
creates two subcomponents of the NavGlobal that share bulk of styles but vary

Questions / discussion:

I created these subcomponents in an effort to reduce duplication, but it increased complexity. Are we okay with how these look / behave?
If these components look okay, shall I break them into separate files?
Are there any additional sass lines that could be moved to the html?

Related issues

closes #425

Submitter checklist

[ ] Added logging is not capturing sensitive data and is set to an appropriate level (DEBUG vs INFO etc)
[ ] Updated relevant documentation (README, ADRs, explainers, diagrams)

Security considerations

No additional, frontend styling only

beepdotgov commented 4 weeks ago

Said this in Slack, but you’ve done a remarkable job translating the design into the utility-class framework. Visually, it looks fantastic! Well done, @jduss4.

Can’t really weigh in on the ergonomics, but I definitely agree it seems more complex. Two (non-blocking!) things I’m curious about:

When the design specifies something that’s not available in USWDS’s utility classes, how would we reconcile that?
If a component’s design needs to be changed — due to user feedback, product needs, &c — would this approach make it faster or slower to implement those changes?

hursey013 commented 4 weeks ago

Also now seeing that it sounds like this could use more of a team discussion, apologies for missing that!

jduss4 commented 3 weeks ago

Re @beepdotgov 's questions:

When the design specifies something that’s not available in USWDS’s utility classes, how would we reconcile that?

Sounds like adding custom styles via CSS is still the way to go in that case, although ideally we can craft them to be similar to utility classes

If a component’s design needs to be changed — due to user feedback, product needs, &c — would this approach make it faster or slower to implement those changes?

It will probably take someone unfamiliar with the NavGlobal component(s) a few minutes to figure out what's going on, but hopefully it's pretty straightforward still. I don't think that this change will make things particularly faster or slower, imo.

cannandev commented 3 weeks ago

Also now seeing that it sounds like this could use more of a team discussion, apologies for missing that!

Super late to the discussion, but this is one of my favorite topics. I was excited to work on this project as the README describes a utitlity-first approach. It's my dream to live in a world where frontend developers spend more time in the reusable component instead of in a stylesheet. Ideally, I'd like to see the stylesheet used just for settings. I've used Tailwind.css's explanation to convince vendor partners of the benefits of utility-first.

When the design specifies something that’s not available in USWDS’s utility classes, how would we reconcile that?

@beepdotgov I think this is where design and engineering can really work together. It's usually with spacing and sizing (padding, margins, gaps, widths, heights) that I run into issues where there may not be a uitlity class to match the original design. As a designer, would you be open tweaking a design to accomodate utility classes? For example, height and width utility classes are multiples of 8. So instead of an image size of 25px, could we (engineers) bump that to 24 or 28 to avoid writing custom CSS?

cloud-gov / cg-ui