How the spec says to implement silent mode for SASS

[dan-searle]

http://origami.ft.com/docs/syntax/scss/#silent-styles

For every class selector included in a module’s SASS, the module must also include the same selector as a placeholder, with the same styles. Eg:

I think the Origami spec should be less opinionated on how silent mode is achieved. In some cases it makes sense to have like-for-like placeholder equivalent of each class selector, but in many cases it may be more appropriate to use mixins etc.

For example, where we're using BEM modifiers to provide styling variants, it is important that the selector they output in matches the selector they're modifying:

.o-button {
    /* standard button styles */
}

.o-button--standout {
    /* overrides & additions to make the button brighter */
}

In this example, if each of those were provided as SASS placeholders, we'd have to document that they must be @extended into CSS classes that share the main name (it would technically work if they didn't, but it wouldn't be a misuse).

If the above was achieved with a mixin, then the naming requirement can be built-in and it'd be simpler to document:

@mixin oButtonsButton($buttonclass) {
    .#{$buttonclass} {
        /* standard button styles */
       &--standout {
         /* overrides & additions to make the button brighter */
       }
    }
}

This also means that for non-silent mode, the module just calls its own mixin:

@if (not $o-buttons-is-silent) {
    @include oButtonsButton(o-button);
}

This is simpler than trying to wrap a bunch of styles in a 'placeholder or optional class selector'.

It may even be better for the spec to say that SASS must be implemented silently, but must provide an optional non-silent (aka buildservice) means of usage via CSS classes.

[kavanagh]

I agree.

[kavanagh]

Also we should be trying to ensure we do this:

.o-button {
    /* standard button styles */
}

.o-button--standout {
    /* overrides & additions to make the button brighter */
}

and not

.o-button {
    /* standard button styles */
}

.o-button.o-button--standout {
    /* overrides & additions to make the button brighter */
}

[triblondon]

I want to be opinionated on this because it makes sense for components to deliver styles to other components in a standard way, so you don't have to figure it out each time. If this is the way we prefer, I'm happy to standardise on it, but I'd rather we do express a preference.

[wheresrhys]

if each of those were provided as SASS placeholders, we'd have to document that they must be @extended into CSS classes that share the main name (it would technically work if they didn't, but it wouldn't be a misuse).

I think this is only true some of the time (I'm guessing 'wouldn't' is a typo) . If my module uses one type of button and that button is of the standout style it's perfectly proper for me to extend both those placeholders into .o-sass-woes__submit and menas I need fewer classes in the html and stylesheet.

Also the mixin is making the implicit assumption that the product/dependant wants both button and button--standout. What if the number of button variants increases - is it ok for the mixin to force outputting of all the button variant styles in the namespace passed into the mixin?

On the other hand if e.g. a hitherto hoverless type of button gets a hover state defined for it in a newer version of buttons, then dependants would effortlessly pick up hat change.... but placeholders can probably tackle that by differentiating between ui-states and skinning - ui-states needn't (and perhaps shouldn't) be silent, whereas skinning should be e.g. %o-button--standout.is-disabled not %o-button--standout%is-disabled

I'm not a massive fan of placeholders for other reasons (mainly that they make the order of your stylesheet unpredictable and, it's looking likely, are much slower to compile than mixins), but they do offer a good way for dependants to be very picky about the styles they want and thus reduce overall stylesheet size.