Open mandrew opened 8 years ago
Hey @mandrew, just thinking of some ways to expand the comment structure to handle these cases.
We could set it up to handle entering multiple classes through custom variables (rather than a set $modifierClass) eg:
Markup:
<a class="btn $color-modifier $component-modifier">Button</a>
$color-modifier:
.btn-default
.btn-success
$component-modifier:
.btn-default--small
.btn-default--medium
.btn-default--large
or alternatively allow having multiple class attributes in the single variable, eg:
Markup:
<a class="btn $modifierClass">Button</a>
.btn-default.btn-default--small
.btn-default.btn-default--medium
.btn-default.btn-default--large
.btn-success.btn-default--small
.btn-success.btn-default--medium
.btn-success.btn-default--large
I use a lot of BEM syntax in my projects, which relies heavily on component class modifiers so makes sense to be able to handle these cases. I'd lean towards the first option in this case as it's more legible in the code base. Thoughts?
I suppose going down the first route could also apply to other markup variables, which could generalise the markup a bit more and open it up to be more flexible, eg:
Markup:
<$element class="btn">Button</$element>
$element:
a
p
span
button
Due to the long list of modifiers on ss.org, I'm thinking of refactoring the modifier classes into 'component-modifier' and 'colour-modifier' in the future but the module doesn't allow for more then one & the ability to test the interactions between both modifiers. I was thinking about using a dropdown for the extra modifier.