Discussion: Expansion of Pattern MetaData with styleModifier Listing

[dmolsen]

A user has a simple pattern that can be modified by a class and would like the "view all" to show that variation.

---

I realize we haven't implemented the metadata discussed in #16 yet but I'd like to get this out there just in case. I was looking at the US Design Standards and mulling how I'd implement a StarterKit based on it. It seems like it'd be somewhat easy. One thing I was struck by was their need to show different states of, say, a button.

Normally I would think "KSS" because then you have docs in your CSS where the item is used and everyone is happy. But we're already setting up and sitting on docs. Could we just extend that officially to show states? This isn't 100% foolproof. A good example is the button pattern. We could easily show/change style but we couldn't toggle type="button" on for just that one pattern.

I'm not 100% finalized with this idea but I wanted to get it out there in case anyone was especially interested in it.

System Input

Add a styleModifiers array to the pattern documentation front matter. It'd look like:

styleModifiers:
  - usa-button-primary-alt
  - usa-button-secondary
  - usa-button-gray

To address data concerns it could conceivably be expanded to:

styleModifiers:
  - usa-button-primary-alt
  - usa-button-secondary
  - class: usa-button-gray
    experimental: true
    data:
        - type: true

And a check of type could determine if the value was a class name or an array that had extra material. data could be added during render. The use of experimental or deprecated may provide for a way to highlight an individual style as experimental or deprecated in the UI. It's possible that an entire pattern could also pick up an experimental or deprecated tag too I guess.

System Output

I honestly don't remember how I was doing this for KSS but somehow I had it providing different versions of the pattern with a class name. Let me dig that out. It may kill this idea but figured i'd run it up the flagpole anyway.

The class names could be outputted into the modal though. That should be straightforward.

Spec Info

The timeline for this feature is not at all critical. Tagging spec-enhancement because this would expand on #16. No vote at this time. Just talking.

[dmolsen]

More ideas on state/status. Maybe this would be better as a state.

http://registry.origami.ft.com/components

So:

styleModifiers:
  - usa-button-primary-alt
  - usa-button-secondary
  - class: usa-button-gray
    state: experimental
    data:
      - type: true

And a class could be experimental or a pattern could be experimental.

[EvanLovely]

Good direction, but Pattern Variants are so much more than just different BEM Modifier classes being added, and then gets so much harder when PL tries to go beyond that. Most data variations could be better handled by JSON Schemas.

My vote: 👎

[bmuenzenmeyer]

I am curious what can come out of pattern-lab/styleguidekit-assets-default#73 and therefore will 👎 until that matures a bit more

[bmuenzenmeyer]

vote failed, closing issue