Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modifier classes are ambiguous #2915

Closed
thisisdano opened this issue Feb 20, 2019 · 10 comments

Comments

Projects
None yet
3 participants
@thisisdano
Copy link
Member

commented Feb 20, 2019

In USWDS 2.0 we've started using an additive technique for styling variants of base components. For example, if you want a button with the secondary color as its background:

1.x: .usa-button-secondary
2.0: .usa-button.usa-button-secondary

We feel good that this is a positive change that makes style composition clearer, more modular, and more reliable. For instance, there's now no need to remember if secondary or outline comes first in a single-class button that has a secondary color as its outline — you'd use usa-button usa-button-outline usa.button-secondary in whatever order.

What's ambiguous is when a particular class is a modifier variant or a base class itself. When do you need to add the base class and a variant and when do you need just a single class?

I propose that variant modifier classes should be separated by a double hyphen (--) as in .usa-button--secondary or .usa-accordion--borderless. This would bring our modified BEM convention a bit closer to standard BEM and make it very clear just how the element should be classed to achieve the desired effect.

The double hyphen is relatively simple to type, is consistent with an existing convention, and provides an important distinction. Is this something we should do for USWDS 2.0 to accompany our switch to modular classing? Would this help developers better understand the necessary classes?

@thisisdano

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2019

@maya @hursey013 @uswds/core Do you have any opinions about this?

@stphnwlkr

This comment has been minimized.

Copy link

commented Feb 20, 2019

FWIW, I agree that this was the right way to go. I like your approach to differentiating the base and modifiers.

@maya

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

If we are going to go so close to BEM, then why not just go fully?

@thisisdano

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2019

Mostly because I don't like underscores :)
And, personally, I don't think the distinction between block and element is important enough to warrant the special treatment.

@stphnwlkr

This comment has been minimized.

Copy link

commented Feb 20, 2019

I would add that since you are now setting the standard for the future of government websites (by law), it might make sense to adopt BEM fully. It sets the expected baseline for usage, contributions, and may improve adoption.

@thisisdano

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2019

I'm game to consider BEM though I do currently consider it overkill. It'll take a little longer to fully rewrite everything in BEM and I'm not sure if it sets some expectation that our codebase may not always deliver! But the upside could be just as you say.

@thisisdano

This comment has been minimized.

Copy link
Member Author

commented Feb 22, 2019

OK. BEM it is.

@thisisdano

This comment has been minimized.

Copy link
Member Author

commented Feb 23, 2019

BEM implementation here: #2904

@maya

This comment has been minimized.

Copy link
Member

commented Mar 6, 2019

Was this resolved in #2904 or is there more work to do?

@maya

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

Closed in #2904.

@maya maya closed this Mar 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.