The following is a guest post by David Clark. I think David’s new Sass library “Scut” is pretty interesting. It’s like a design utility library, which is distinct from a design pattern library in that it enforces no particular structure or particular visual design. I’ve always found this kind of thing fascinating, largely because I’ve never been able to pull it off in a way that feels good to me. I always end up leaning too far into visual design, or too abstract to the point of it not being all that useful. I think David just might be on the right track here. I’ll let him explain in detail.
I’ve started an open-source Sass utility library with a straightforward mission: to ease and improve our implementations of common style-code patterns. I’m calling it Scut.
Scut is a collection of Sass mixins, placeholders, functions, and variables that are generic enough to be widely reusable — within any project, any design — and easy to integrate into diverse workflows and coding conventions. Every Scut utility is an effort to reduce repetition, increase organization, and encourage the reuse and sharing of style code.
Scut is not a frontend framework, and offers no default styling: it does not concern itself with the gradients on your buttons, the padding of your boxes, the font-size of your headers, or the color of your skin. And it won’t provide your vendor-prefixes: Scut’s unique focus differentiates it from other preprocessor libraries. It should help you build websites — especially if you, like me, work on a lot of sites, rather than a single large app — but it doesn’t do everything. It is a companion to, not a replacement for, other popular tools and practices.
I’ve written this article to explain my motivation, intention, and method in starting Scut, and, most of all, to seek your collaborative input.
So as you read, please keep in mind that Scut is in its infancy, and that you, dear reader, have the power to alter and improve it, whether by adding and upgrading utilities or by clarifying the principles behind them. If at any point you decide that you’re ready to try it out or throw in some ideas, please head to Scut’s documentation or the repository on Github.
How We Share Style-Code Now, and Why There’s Room for Scut
Reusable Components: Insert Pretty Button Here
Consider Bootstrap, Foundation, PureCSS, etc. — whether we call them frontend frameworks, UI kits, design systems, or whatever else, their purpose is clear: to help developers build functional, attractive, reliable interfaces, quickly and easily, from pre-crafted components.
Even if we don’t use these frameworks often, we should recognize their value and learn from them. Above all, they demonstrate the virtues of a systematic approach to site design. Mark Otto’s exhortation to “Build your own Bootstrap” and Brad Frost’s description of “Atomic Design” remind us that if we don’t want to adopt someone else’s reusable components, we should build our own bits and pieces to be equally systematic, equally reusable. Mailchimp’s Pattern Library and Mapbox’s Base serve as large-scale examples of that approach.
This variety of style-code sharing and reuse — the component collection, the design system — has garnered a lot of attention, and that’s a good thing. But it is not the only variety; and I write all this in order say that Scut is different.
A good frontend framework helps us in many ways, but the scope of its reusability across diverse projects and designs is limited. Scut aims at a broader, more rudimentary kind of reuse — reuse not of polished components, but of the abstract, generic patterns and practices that underlie those components. (At least, those patterns and practices that are not clear and simple in vanilla CSS.)
Abstract, Generic Patterns and Practices: “Unfinished” Styling
Another way to share and reuse style code — Scut’s way — involves the transmission of useful maneuvers, clever tricks, and best practices, but not finished components.
Here’s the basic idea: Create and share modules that are as generic, flexible, naked as possible, so they can be used in any project to implement a useful pattern, without demanding or determining a particular environment for it.
This kind of sharing happens in two ways: tutorials and utility libraries.
Tutorials
For a paradigmatic example of The Tutorial, I refer you to this very blog, CSS-Tricks, where the eminent Chris Coyier explains and exemplifies patterns we can all apply in our own work. Then there are other blogs, books, articles, Stack Overflow answers, resources divers and sundry — more tutorials on this Internet then we know what to do with.
The writing and reading and sharing of tutorials is an indispensable practice, especially excellent because tutorials teach while they share. However, they provide practices we can reproduce rather than tools we can reuse: they disseminate knowledge, not utilities.
Utilities
The Reusable Generic Utility, Scut’s ideal constituent, is a kind of extension of The Tutorial. It turns out that many (if not most) of the styling tricks, tips, and best practices we read or write about can be abstracted into reusable utilities.
For a fine model of what I mean by “utility,” consider the many functions of Underscore, the JavaScript “utility-belt” — and its offspring Lodash, of course (for this article, please just assume that “Underscore” = “Underscore or Lodash, whatever you prefer”). Let me explain: I’ve been reading Eloquent Javascript, by Marijn Haverbeke, and the other night I encountered a common, useful pattern called the “reduce” or “fold” function. In the tutorial tradition, Haverbeke explains what a “reduce” function does and shows me how to make one. So I could write my own — we could all write our own … But Underscore already has a “reduce” function that we can all use — and since Underscore’s function has run the open-source gauntlet, it’s going to be better than whatever I might produce on my own (though I can’t speak for you, in all your wisdom). As much as I benefit from the knowledge gained, I often gain even more by pairing that knowledge with an open-source utility.
In the world of style code, the best way to collaboratively create a similar utility collection is with a preprocessor library. (Two significant advantages of preprocessor tools over class collections are (1) that they have variability built in, and (2) that they only impact your final stylesheet, what’s served to the client, when they are actually used.) So: enter Scut.
Let’s parallel the JavaScript “reduce” example above with some style code. On CSS-Tricks, there’s an immensely useful article, “Centering in the Unknown,” about centering elements with indeterminate dimensions. The trickiest part is the vertical centering. After reading this article, I know about the method of setting display: table;
on the parent element and display: table-cell; vertical-align: middle;
on the to-be-centered child. And that’s fantastic: it’s a valuable trick to learn. But let’s not stop there. To extend that tutorial and create a reusable, shareable utility, I can write a Sass mixin — something like this:
@mixin vertically-center ($child: ".vcentered") {
display: table;
& > #{$child} {
display: table-cell;
vertical-align: middle;
}
}
Apply this mixin to the parent; pass the to-be-centered child’s selector as the argument (or give that child the default class vcentered
); and you have achieved vertical centering — and done so by creating a tool that can be reused and shared.
Essentially, we’re doing the same thing with CSS (by way of Sass) that Underscore does with JavaScript. Put together a bunch of these utilities, expose them to the open-source community, and you should end up with a helpful library.
(By the way, Scut provides three different methods of vertical centering, each one fitted for different contexts.)
I’ll explain more about the methodology of Scut’s utilities below; but first, you may be asking …
What About Existing Preprocessor Libraries?
If you’re a regular reader of CSS-Tricks, you’ve probably heard of Compass and Bourbon. There are other Sass libraries, and LESS and Stylus have spawned their own. These libraries exist already, bolstered by strong communities, and work splendidly; they do offer “abstract, generic patterns and practices” — so why build another? Because, from what I’ve seen, the existing preprocessor libraries have focused heavily on vendor-prefixing and legacy-browser support, without offering many reusable style patterns. (Some, yes, but not many.) Valuable as they are, they are also, like all things under the sun, limited.
Their limitations jumped out at me when I started using Autoprefixer. (If you haven’t done so already, I suggest reading Andrey Sitnik’s guest post on CSS-Tricks.) I had tried Compass and was using Bourbon regularly; but with my vendor-prefixing taken care of by Autoprefixer, Compass and Bourbon no longer seemed very useful. They offered a few helpers that I would invoke now and again, but not regularly.
I started to wonder what else a preprocessor library might be good for. And that led to the idea behind Scut — a preprocessor library that ignores vendor-prefixing in order to focus exclusively on abstract styling patterns.
The Principles and Purposes of Scut
What Problems do Scut Utilities Solve?
Scut utilities should epitomize the key benefits of CSS preprocessors. I’ll list my favorites:
The Key Benefits of The CSS Preprocessor — which are also The Key Benefits of The Scut Utility:
- It helps me avoid repetition. Instead of typing the same code in various places, I use a mixin, extend, function, or variable, and my code becomes less annoying to type; more accurate — less vulnerable to typos and inadvertent variations; and easier to change and maintain — since each important part resides in one place only.
- It helps me organize code, by grouping associated rules into named patterns — so instead of tangled lists of various rules contributing in various ways to a component’s appearance, I see which rules relate to which specific effects.
- It helps me reuse code (as explained above).
Additionally, the pattern that a Scut utility implements should suffer from one or more of the following problems — and the utility should, of course, solve that problem:
1. The pattern is non-intuitive
The CSS rules required don’t explain themselves. There’s some kind of trick involved: you must have been initiated to decipher the code. Also, because there’s a trick, the pattern is hard to remember. Unless you’ve executed the operation a hundred times already, you probably have to look up instructions on somebody’s blog; and even then, you’ll need to do some thinking, experimenting, and tweaking to get it right again.
To illustrate: You may want to create an element of fluid dimensions with a fixed aspect ratio — let’s say 16/9. After some searching, you’ve found a method that works — but you may not see why just by looking at the CSS:
.parent-element {
overflow: hidden;
position: relative;
}
.parent-element:before {
content: "";
display: block;
height: 0; /* Huh? */
padding-top: 56.25%; /* Wha? */
}
.parent-element > .child-element {
position: absolute;
left: 0;
top: 0;
width: 100%;
height: 100%; /* Filling a container with zero height? */
}
Use a Scut mixin, instead, and a glance at your code will make sense:
.parent-element {
@include scut-ratio-box(16/9, ".child-element");
}
The mixin organizes and names the pattern — and also, of course, saves you from repeating the complicated mess if you need a different ratio-box elsewhere.
For another example, consider the renowned CSS triangle. Without some explanation, the required style code is obscure. To make a blue right-pointing triangle 50px tall and 50px wide:
.triangle-right {
width: 0;
height: 0; /* A shape with no dimensions? */
border-top: 25px solid transparent; /* Why 25px here? */
border-bottom: 25px solid transparent; /* Who needs invisible borders? */
border-left: 50px solid blue; /* My right-pointing triangle is a left border? */
}
The trick is ancient and venerable, and well documented in tutorials around the web. (Chris Coyier recently produced a clever animation to explain how and why it works at all.) So maybe you’ve read some things, you get it, you pull it off yourself. Still, despite your magnificence, the benefit of a good mixin should be clear, to transform the code above into a single intelligible line:
.triangle-right {
@include scut-triangle(right, 50px, blue);
}
And what if you want to build a more complex shape that involves multiple triangles — triangles that are themselves a little more complicated? Then the mixin becomes even more valuable:
2. The pattern deserves a shorthand
The pattern may be easy enough to write yourself — not complicated, plenty intuitive — but it consists of a set of rules that can be usefully and regularly grouped into a named shorthand.
(Of course, vanilla CSS already incorporates some shorthands. Scut just adds more.)
For example, Scut includes some positioning mixins: instead of —
position: absolute;
top: 1em;
right: 2em;
bottom: 3em;
left: 4em;
— you can use scut-absolute
and write —
@mixin scut-absolute(1em 2em 3em 4em)
3. The pattern involves some important best practices
You may think you know how to do it yourself — but unless you’re In The Know and have read all the right things, you may not be doing it the best way. And even if you knew the best way once, in your heyday, you may have since forgotten or missed some game-changing innovations.
There’s nothing like an open-source library to take care of this problem. In fact, best practices is one of the areas where existing preprocessor libraries are pretty strong. So Scut’s best-practice utilities — like scut-font-face
, scut-clearfix
, and scut-hd-bp
(for resolution-based media queries) — resemble some mixins you’ll find in Bourbon and Compass.
4. The pattern is extremely common and a little annoying
You use the pattern consistently — every project, usually multiple times per project. And every time, something in your mind mutters “Again?” and a dark psychic cloud passes over your psychic sun, a transient awareness that you’re a few keystrokes closer to death.
If I had a dime for every time I nullified margin
, padding
, and list-style-type
on an unstyled-list — O! the sandwiches I could buy —— So some of Scut’s first utilities were scut-list-unstyled
and its common variations, scut-list-inline
and scut-list-floated
, exemplified below (with various “skins” applied, to demonstrate how an abstract utility should be able to apply in all kinds of design situations):
How Do You Make a Scut Utility?
In short: maximize reusability. Reusability is what distinguishes a library-ready utility from a project-specific one.
Include sufficient detail to implement the pattern, but no more. The utility alone should not produce a passable component. Again, Scut isn’t about passing around well-constructed, finished designs: it’s about facilitating the construction and finishing of unique designs.
Use arguments to allow for typical variations on the theme. Whenever reasonable, include conservative default values for those arguments — so users may not have to enter every argument every time — and arrange those arguments according to the order in which they’re likely to be changed. Additionally, use @content
blocks, when they make sense, if you expect regular customizations that won’t fit into arguments.
Namespace, to prevent conflicts with other libraries and project-specific code. Scut adds a scut-
prefix to all its pieces. That way, we can include a “clearfix” utility in Scut without worrying that it will conflict with Bourbon or Compass clearfixes (which aren’t namespaced). And we can use generic utility names like “size” (scut-size
), generic variable names like “circle” (scut-circle
), without disturbing the natural balance.
Lastly: document thoroughly, document well. I’m trying hard to do that with Scut’s docs — and I would, of course, appreciate your input and advice. We’ve all been frustrated by documentation — we’ve all known that pain — so we all recognize that the effective reusability of a tool directly relates to the quality of its documentation.
Now To Address Some Reservations
I don’t use Sass
Whatever your workflow, whatever choices you’ve made, good or bad, Scut can probably help, at least a little. If you don’t use Sass, you might still look into the open-source code and either port it (to your preprocessor-of-choice) or read it, along with Scut’s documentation, as a series of mini-tutorials, a kind of style-pattern reference.
I Love OOCSS and Cannot Serve Two Masters
Object-Oriented CSS (OOCSS) and Scut address similar problems with similar solutions: namely, extendable patterns (or “objects”). But they are by no means the same. Perhaps you’re an OOCSS aficionado, and you consider all these mixins and extends to be inefficient nonsense. You want a “clearfix” class, not a mixin that will duplicate code, or a bunch of `@extend` directives that will clutter your compiled CSS. You want to make your triangles with classlists like triangle triangle-large triangle-down triangle-red
, not one triangle mixin invoked multiple times with different arguments.
Well, that’s OK. There’s no need to argue here over the virtues of preprocessors versus those of class-heavy coding conventions, semantic versus presentational classnames, etc., because Scut doesn’t preclude OOCSS-style coding, or any other style: simply summon Scut’s utilities as needed to help create the classes for your objects and their extensions.
I Don’t Like Some of Scut’s Utilities
Let me know what needs to change (file an issue on Github), and we can work together to build a better Scut.
Keep in mind, also, that some of the current utilities are more experimental than others. As Scut stumbles through its unstable youth (v0.x.x), I’m looking for collaborators who are interested in figuring out what works and what doesn’t, which utilities will improve a project’s codebase and which might make it more cryptic and harder to maintain.
I Think This Whole Idea Is Stupid
Again, you’re welcome to tell me what you would do differently. Show me how it’s done. Or else you can go your separate way, do something you enjoy to cheer yourself up again — eat some pie, ride a bicycle — and forget you ever read this.
Curious? Convinced? Confused? Try Using and Contributing to Scut
I hope I’ve said enough, by now, to convince you to look into Scut, maybe tinker with it a little — or even, dare I wish, contribute.
If you’re ready for a trial run, Scut’s documentation will tell you how to install and apply the library. (Basically, use Bower or download the latest release on Github, then @import
into your Sass. Easy as can be.)
And if you’re thinking you may want to donate some modicum of your own brilliance to the project, please don’t hesitate. Go for it. Scut is a simple library, an easy open-source contribution — which could be especially nice for those of us who work primarily in HTML and CSS and feel wary of wading into other Github projects. Scut is all about making your work, my work, and the work of other developers easier, maybe even a little bit better; extending tutorials into reusable utilities; encouraging best practices; and sharing good ideas — goals we can agree on. I hope you’ll find it a worthy experiment.
Nice article! Thank you.
Ah this looks like a great idea going to see if I can implement any of these soon! :) Thanks!
I have a feeling this is going to go down as a monumental article. It combines useful practices that are well thought out and easy to understand, implement, and extend. It’s a bit like taking the torch from SMACSS by Jonathan Snook and running with it in a very practical manner. Thanks David. I’m looking forward to helping Scut grow.
Nice !
It reminds me my Compass Recipes :)
Thanks for the tip — I hadn’t seem your collection of recipes before. I’ll take a look.
I was about to comment the same, you two should probably merge your efforts!
I’ve been working on a similar one myself, it’s called veRepo.
This to me seems to be the missing piece from the sass ecosystem. I am not sure how much value I can add but i will definitely be eager to dig into it.
Lovely stuff… I’m building up my own library of useful snippets. Absolutely love using SASS, really enjoying thinking of new things to build. Here’s a position short hand mixin, inspired by Hugo Giraudel’s offset mixin, I took a different approach though
I don’t really understand why I have to count to 5 in my loop..
anyhow, it does this
awesome!
It counts from 1 to 5, so it runs 4 times which is the length of
$args ()
Great! Here are the positioning mixins I’ve made for Scut, which are fundamentally similar to what you have going:
http://davidtheclark.github.io/scut/#positioning
I use the mixin
scut-coordinates
to deal with the list of four coordinate values, then separate mixins extending that functionality for specific position values (scut-absolute
,scut-relative
,scut-fixed
).I use these mixins all the time when I make sites. Simple as they are, I think they embody some of the key benefits of abstract Sass utilities.
I think this is a fantastic idea. Having read the documentation but not used Scut yet, I can see right away a few useful ideas, such as shapes, typography, functions and some of the layout ones.
However, I wanna caution against using shorthands such as the ones for margin, padding and positioning. While it does help us developers save a few lines of code, it comes at the expense of maintainability, when a new person coming on the project reading through the code, they might get confused at the unfamiliar syntax. The full CSS syntax is simple enough, albeit overly verbose.
I get your concern. I’m not yet sold on the margin and padding mixins, because, as you say, they add a layer over CSS that is already very simple, just a couple of lines — but they do reduce repetition, for the situations in which you want to add the same value to multiple margins; and I like being able to enter multiple margins in one line without overriding all the margins. You’re welcome to continue this conversation on Github — I’m very interested in hearing what other people think about this theoretical point.
(What would you think about making a margin/padding mixin that is just like the vanilla shorthand but with an
n
value to avoid overwriting a side, e.g.@include scut-margin(1em n)
orscut-margin(1em 2em 1em n)
?)However, I am sold on the positioning mixins: I find myself using them all the time — I think they make the code more organized, more readable, and the added layer (above vanilla CSS) is so thin and transparent that I don’t think it’s really a barrier for maintainability.
I must say that a part of me really likes this.. I can truly empathize with the feeling of a dark psychic cloud over my face almost every single time I style a meny. I just started using SASS and I will download SCUT and try it out..
On a different note; What I don’t like about this approach is the automatisation of knowledge. Of course to each his own but I want to really know what my code does and what it outputs. Using SCUT, SASS, LESS, Compass etc.etc. kind of takes away some of that. For someone who’s been in the business for some time this might not be so much of an issue but lets say a newbie comes along, decides to start coding and immediately installs SASS, Compass and SCUT. They’ll have so many solutions handed to them by non-explaining mixins etc. that they wont understand whats really going on (unless they actually open these up and check it out).
I’m just getting started with SASS and will try SCUT and I’m sure I’ll love it, but if a friend of mine ever comes along and asks me how to start learning coding website I’m not going to recommend any of these utilities until they’ve passed the intermediate-status.
I definitely get your concern. I’ve seen new programmers write entire JavaScript-heavy sites by cobbling together snippets and examples that they found online. And the site pretty much works! Later, when helping them debug something, it becomes clear that they don’t even understand what a for-loop is, or how to do the simplest string manipulation.
Then again, that’s exactly how I learned to write code.
It is easy to forget that we learn by copying examples and correcting mistakes. We don’t learn to write code by generating a solid understanding of all the extremely abstract concepts involved and then sit down and start writing perfect code.
Scut adds a really thin layer over the “real style code” that’s practically transparent. Furthermore, when you’re debugging something you wrote with Scut in a browser, you are looking at CSS code, driving home the knowledge that what you originally wrote is not “real code”, and at the same time teaching you something about the utility of utilities and what dependency really means.
Absolutely love your idea and admire that effort, infact looking forward for more for scut, as usaing regularly Compass/Sass i’m seriously confused and Scut sound really awsome , reusable thing is plus but it would be graet idea if scut define feature scope like copmass eg. @import “compass/css3” would import only those style for css3 that we wanna use , i guesss you understand what i’m asking it would be great if scut do same support. Moreover i’m worried about generated CSS styles, bcz if i use both compass and scutt they gonna creat too much their css and if i use foundation afterward then it’s gonna expand more, So, i’m looking more about scut with compass and foundation.Thanks
Glad to hear your enthusiasm. To address your concern: Since Scut only includes Sass mixins, placeholders, variables, and functions, no actual classes, it will not increase the bulk of your final compiled CSS with unused stuff — so you don’t really need to pick and choose which modules you import. (For instance, if you don’t use
scut-triangle
, that code will not be found anywhere in your compiled CSS.) This is part of how Sass works — one of the nice things about preprocessors.Frameworks like Foundation offer a whole bunch of classes because that makes it easier to plug-in their finished components, directly in your markup. So if you’re concerned about excess CSS, it’s a good idea to be specific about which Foundation modules you import (or with Bootstrap, you probably want to create a custom build when you know what you need).
That’s the whole behind these libraries, it’s to avoid situations like these:
You only use what you need.
I’m liking the concept (and well written article!). Just wondering if you’d consider adding some compatibility setting type logic… So for instance, if I don’t care about IE8, I can set that in a setting and
@mixin scut-center-absolutely
would use something like that instead:Also, is there a way in SASS to reference the same mixin with 2 different names without duplicating the mixin? Back in the days, I made a textmate CSS bundle that used tab triggers like
lstn
forlist-style-type: none;
(before Zen coding thank you very much… ;)I think it would make Scut way better if we could use things like
@include scut-ca;
in addition to the long version.Thanks!
You could just create a mixin which references the scut mixin, passing in the same arguments.
A few interesting points here. I’ll respond to each one:
I would prefer not to establish “settings” unless they are really necessary and/or significant. With the utilities in Scut so far there really isn’t much that would change to drop IE8 support — so I don’t think a compatibility setting would be worth it at this time. Whether or not that changes down the road, we’ll see.
I hadn’t really thought about the
translate
technique you bring up (looked it up on CSS-Tricks). Looks like the unique usefulness is in absolute vertical centering of elements with unknown height — right? Interesting … We would have to discuss what might be the best way to include vendor-prefixed properties in a Scut mixin …I’ve also been thinking about short nicknames for mixins. Dave is right that it would be easy to do. It’s something worth bringing up on Github and seeing what other people have to say. I can see immediate objections similar to what Tri mentioned above: a nickname would add another layer between devs new to the code and the actual CSS. But it’s also true that you wouldn’t have to use the nickname if you were concerned about that in your situation … I wonder what other people think.
Yann, I just wanted to notify you that someone posted a pull request about this method. The conversation is here: https://github.com/davidtheclark/scut/pull/109. Feel free to participate!
Boom! You had me at scut-list-unstyled. :)
This is incredibly awesome. I’ve been amassing my own collection of similar stuff, but having it all documented, in one place and maintained by the community is just amazing.
I love you. And not even just in the Platonic sense!
Going through the project, I found one real candidate: reverse indent. It already surprised me once going back through my code, why would I do it this way? Then I needed it again, it’s useful to guide the eye in lists, inlined definition lists, and titles.
For example
Should be something like:
I’ll try to create an account on github sometime soon, but if someone comes around to it earlier, feel free to add.
I think that’s a fine idea — in fact, I believe that Scut already has what you’re looking for, by a slightly different name: “hanging indent”. Have a look:
http://davidtheclark.github.io/scut/#hanging_indent
Here’s the source code on Github. Feel free to offer suggestions for changes or additions. Thanks!
Really great utility library there David. If you don’t mind I’d like to suggest an improvement to the
scut-side-lined
mixin. scut-side-lined mixinI like that horizontal line effect on text, BUT what if you wanted to fade those lines instead of a solid color? I just added an option to have a gradient line if you wanted it.
Here’s the codepen:
Codepen Demo
Basically if you wanted that fade at the very least you type this.
Note: The arguments
$style
, and$double
have no effect since it’s a background image and not a border, but the other arguments should still work.Good tip, thank you!
I would say yeah for vertical centering. But the positioning mixin is less clear than the css in that you have to remember the order of sides rather than having named properties. That is clearly going in the wrong direction in my opinion, for little gain.
here’s mine position mixin – I absolutely love to work with it
Somehow the documentation on http://davidtheclark.github.io/scut/ is crashin my ipad (safari) browser.
I had this problem early on but “fixed” it — in that I was no longer able to reproduce it, so believed it to be gone. I still can’t reproduce it — and I do know other people have accessed the site on iOS browsers without crashing. So … weird. I have received one other complaint about this problem, though, so I’m opening up an issue:
https://github.com/davidtheclark/scut/issues/110
If anybody who knows more than me can figure out what’s going on and fix this issue, or offer some clues, your help would be much appreciated!