Pattern Style Modifiers & KSS

[dmolsen]

This would be a December project if it's of any interest...

TL;DR

Could use KSS to comment and relate CSS to patterns. A single pattern could be modified so it shows different styles. Combined it might provide an interesting styleguide solution where descriptions for a pattern come from CSS. Could be extended to provide CSS driven states in pattern examples.

MORE

After looking at KSS I think I'm starting to get what you meant by associating a pattern with CSS. KSS is an agnostic method for creating machine-readable comments in CSS. This allows for the creation of "living styleguides". GitHub uses it for their styleguide. Here's an example:

/*
A button suitable for giving stars to someone.

:hover                  - Subtle hover highlight.
.stars-given          - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled              - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.
*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

The thing that has me really interested is that it seems like we could extend KSS to include a pattern as the reference mark-up for a particular style. Right now, KSS is just about describing CSS. In order to get a styleguide going it seems like someone has to hardcode the mark-up/CSS link in real code. It seems like what we could do is tack on a pattern reference at the end to make that connection:

/*
A button suitable for giving stars to someone.

:hover                  - Subtle hover highlight.
.stars-given          - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled              - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.

Reference atoms-button.

*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

So we could parse the CSS/KSS before generating anything. When a particular pattern is shown we could see if it's been referenced for a group of styles via KSS. We can also check if it has more than one style of implementation (e.g. plain, stars-given, and disabled). We'd iterate over the pattern multiple times and apply each different style of implementation. We'd also show the comments and other info from the KSS. The patterns would be shown in a similar way to GitHub (the right column, not nav) but organized/nested based on pattern and not based on the stylesheet.

In order to allow a single pattern to be modifiable we'd have to include a little mustache when we create the pattern. For example we could create a pattern called atoms-button-star:

<a href="#" class="button star {{ modifyStyle }} ">Button (a.button)</a>

As we iterate through the associated styles for a pattern we can swap out {{ modifyStyle }} with the chosen style. The cool thing is that it opens up the possibility of modifying styles from other templates. We might be able to do this in a pattern that includes our star button:

Have you starred this repo? {{ atoms-button-star:stars-given }}

Which would generate:

Have you starred this repo?
<a href="#" class="button star stars-given ">Button (a.button)</a>

Rather than hardcoding patterns that have states we might be able to simply modify them with CSS. It might also be interesting to see if we could do something with the Page-specific JSON. For example:

{
    "modifyStyle": {
        "atoms-button-star": "stars-given"
   }
}

There are problems that I'll have to tackle:

• the : mod on a pattern name will only work for that pattern. It won't affect nested patterns If you have an organism that includes a molecule that includes the star button you couldn't affect the star buttons state. Maybe the JSON is the way around that.
• We'd only be modifying one style. Not to say we couldn't find a way to chain or provide a more "tag-like" experience.
• atoms that are more complicated in the interest of developing a proper styleguide might not be re-usable in this way. For example, my button example could/should be both an a and button tag. That obviously wouldn't be embeddable in an Organism, Molecule, or Template. This is the tension we're already experiencing with Atoms though.

No rush on this. Just wanted to throw it out there while I was thinking of it. Figured it fell into doing things the way designers would think of it, being agnostic, and helping create a fuller deliverable.

[dmolsen]

Writing this down while I'm thinking of it...

On a pattern detail page the default style could be chosen. A selected a style could be chosen via the code view pop-up or added via the address bar. For example:

http://patternlab.localhost/?p=atoms-button-star&s=stars-given

This would show the atoms-button-star pattern (as it does now) and give it the style stars-given. Essentially the style could be injected via JS so no need to create multiple pattern files. Unfortunately, I think the s request var would need to be added to History which is such a pain in the ass. It would make it easy to share a particular styling of a pattern with a client though.

[lewisnyman]

It might be worth looking into Holograph aka Hologram for PHP - https://github.com/sumpygump/holograph

It wouldn't introduce the Ruby dependancy that KSS would.

[dmolsen]

There is a PHP KSS library which I was looking at. I haven't fired it up yet though...

https://github.com/scaninc/kss-php/

But I'll also look at Holograph. Thanks for the heads up :)

[forjoyilive]

What did you end up deciding on, for this? We have a very small number of employees, and KSS would make sure Pattern Lab was up to date with the latest code and styles.

Edit: I see this is slated for an upcoming version. Whoops!

[lrobeson]

Can anyone provide specifics on how exactly to get KSS working with PL? I've messed around with the PHP-KSS plugin but I'm still unclear on how it's all intended to work together. Is the end result supposed to be a KSS styleguide and Pattern Lab, or everything inside PL?