Remove the ability to customise classes across components

[gvonkoss]

What

The ability to customise classes has not been consistent across our components. We want to create consistency, so are opening this discussion to figure out whether we should remove the customisation, or add it to all components.

Currently we are leaning toward removing the ability to customise.

Why

• More readable SCSS and simpler JS.
• Mixins can be used to include features without needing to wrap mixins in classes.
• Encourages CSS reuse including a component once rather than multiple times with different class names.
• Increase reliability and maintainability

[rowanbeentje]

What's the ability to customise classes - got a short example or the calls used by the components which do support it? Is this like the new Overlay('overlay', { class: 'o-overlay--my-modifier' }) which adds an extra class to enable more targeting, or something else?

[gvonkoss]

🙈and 🤔
we were referring to situations like:

@include oMessage($class: my-message) 

//output
.my-message {
    property: value;
}

I think it would involve some work to break out modifiers and such, but we're trying to get a feel for the general consensus

[dan-searle]

I'm in favour of removing this ability. Is there a particular use case it was introduced for?

[notlee]

@dan-searle Not that's known to me. It might be useful for using a component to build a new component, but we can still provide mixins which include no classes, oNormaliseVisuallyHidden is a good example .

[i-like-robots]

I'm in favour of removing this too because it seems obtuse and is little, if ever, used.

[rowanmanning]

Had a quick chat with @wheresrhys on this, wondered whether he'd have some history. We came up with some potential reasons why you might do this:

• class name shortening
• vanity
• retrofitting origami to sites where the dev has limited ability to edit the html

Going to look through some old issues and commits to see if I can find the real reasons

[notlee]

retrofitting origami to sites where the dev has limited ability to edit the html

Good thoughts. That sounded like a compelling reason but actually doesn't really apply here as usually we only allow modifying the block portion of the class, not element or modifier portions.

[notlee]

For the reasons above, we're decided to start removing the ability to customise the base class of Origami components. Thanks for your input everyone 👍

[notlee]

This was done. No Origami maintained components allow class customisation in this way. I don't think it's something to specially spec against though, especially if we spec how we should customise components, and would like to close this issue. Thoughts @Financial-Times/origami-core?

[JakeChampion]

@notlee Agree, let's close this :-)