Mixins & Utility classes
o-t-w opened this issue · 8 comments
I've always seen mixins and utility classes as alternative approaches.
Since autoprefixer made manually writing prefixes unnecessary I've largely avoided mixins altogether.
As per the playbook we will be defining mixins in a bunch of files in one directory and utility classes that use them in different files in a different directory. These mixins will set one single CSS property. This is pointless - it is more code and more fragmentation for no benefit.
People will have different subjective opinions about Sass. Unless it is giving us a real benefit then we should not mandate that people use a gigantic megaton tangle of Sass everywhere unless there is a real benefit.
@o-t-w -- I'm not sure if your issue is with SASS or the way we are handling CSS here.
@Alicole I do have a general unadulterated hatred of Sass tbh, but leaving that aside: Its possible to Sass in ways that are (slightly) useful and also possible to use it in ways that just add needless complexity and overengineer things.
Tying so much of our CSS to a technology that is already waning in popularity doesn't seem like a great idea 🤷
Batphoning @davidpauljunior @alexkilgour @sonniesedge for their thoughts.
I think that before deciding that something is over-engineered, it's important to first know why it was written how it was written.
If I understand it correctly, this isn't about abstraction for the sake of abstraction. But is more about trying to come up with a system that works for the different ways that classnames are used across projects.
One project might use a combination of classnames to describe the way something behaves:
<ul class="u-reset-list c-flex flex--space-between">
<li>Garth</li>
<li>Wayne</li>
</ul>But another might use classnames that just describe a thing, and the behaviour is hidden in the CSS:
<ul class="c-author-list">
<li>Garth</li>
<li>Wayne</li>
</ul>
.c-author-list {
@include reset-list;
display: flex;
justify-content: space-between;
}
Certainly on Naoki (the BMC / SpringerOpen part of Oscar) we have made a significant shift from the latter, to the former. And we have seen that in making that switch we pretty much don't need mixins.
I would be interested in seeing if the global toolkit can encourage a single way to write the HTML, rather than trying to cater for many different approaches.
The relevant bit in the playbook is
Where there is more than one rule, an associated mixin should be provided at the 30 Mixins level
But I realise this could be clearer later on when talking about mixins vs components
Also it is worth noting that in some cases we have less control over the html, so adding a class is not possible, or at least harder, than using a mixin to extend the existing markup
(This all reinforces the need to write some component authoring guidelines)
"I found out that using many util classes made my html not easily readable so i prefer adding mixings of those under a classname for that item." (emphasis mine)
This was Nasia's comment during the open space. I think it is worth reiterating that we are moving away from the Shunter-Mosaic utility class only way of writing CSS towards BEM and that utilitly classes will be lightly used when needed, which might alay the need for both mixins and utility classes without ruffling too many feathers? I might be nice to standardise on a common approach - so long as everybody is happy with it?