larlet-fr-david-cache/cache/2022/28c9baf3ff21fbc616ccf13776104ccd/index.md

title: When Our Tools Hold Us Back
url: https://www.oddbird.net/2022/11/11/platform-tools/
hash_url: 28c9baf3ff21fbc616ccf13776104ccd

<p>The
<a href="https://almanac.httparchive.org/en/2022/">2022 Web Almanac</a>
has been out for a while,
and (as always)
it’s an interesting<span class="widont"> </span>read.</p>
<p>There are more than 20 chapters this year,
and I haven’t read them all.
But I did enjoy the chapters on
<a href="https://almanac.httparchive.org/en/2022/css"><span class="caps">CSS</span></a>
(by Rachel Andrew)
and <a href="https://almanac.httparchive.org/en/2022/fonts">webfonts</a>
(by Bram Stein).
Both authors note a similar trend –
<strong>many usage patterns
that refuse to change from year to year
can be explained by popular<span class="widont"> </span>tools</strong>.</p>
<p>I’ve noticed that same effect elsewhere,
and I want to dig into it a bit –
the various ways our tooling
can change (and limit)
the web platform features we<span class="widont"> </span>use.</p>
<p class="anchor-link-wrapper">
<h2 id="the-worst-color-formats" tabindex="-1">The worst color<span class="widont"> </span>formats</h2>
</p>
<p>According to the Almanac data,
the most common color formats on the web
are <span class="caps">HEX</span> (<code>#C71585</code>),
short-form <span class="caps">HEX</span> (<code>#c18</code>),
and then old-school
<code>rgba(199, 21, 133, 0.8)</code>.</p>
<p>But why are we still using
the oldest and least legible
color formats,
when better formats are well-supported?
<span class="caps">HSL</span> is more human-readable than <span class="caps">HEX</span>,
and the <code>rgb()</code> function
now supports alpha transparency
without switching to <code>rgba()</code>.</p>
<p>Alternately, if we like <span class="caps">HEX</span> so much,
why don’t we use the alpha-<span class="caps">HEX</span> syntax
(<code>#C7158599</code>)
that’s been supported for several years.
Why aren’t these options gaining<span class="widont"> </span>popularity?</p>
<p>It’s hard to say for sure,
but I have a multi-part<span class="widont"> </span>guess.</p>
<p class="anchor-link-wrapper">
<h2 id="how-design-tokens-intervene" tabindex="-1">How design tokens<span class="widont"> </span>intervene</h2>
</p>
<p>First, colors are <em>design tokens</em>,
and often get set as custom properties
or build-tool variables
at the start of a project.
Once the tokens are established,
we don’t spend much time looking at
the actual color syntax underneath.
I don’t ever interact directly
with the <span class="caps">HEX</span> code <code>#E60073</code> –
I can just reference
<code>var(--brand-pink)</code>.
So we focus our attention on the naming conventions
rather than the underlying color syntax,
which is hidden from<span class="widont"> </span>view.</p>
<p class="anchor-link-wrapper">

</p>
<p>I think there’s also a tooling component here.
Many graphic design tools are a step removed
from the web platform.
While some do try to export <span class="caps">HTML</span>/<span class="caps">CSS</span>,
only a few consider that
the core goal of the tool.
Even then, there’s been a long-term disconnect
between a web that’s responsive,
and our almost completely static design<span class="widont"> </span>tools.</p>
<p>A few tools have started to provide
<em>flexbox-like</em> ‘responsive’ layouts,
but I haven’t seen anything <em><span class="caps">CSS</span>-grid-like</em>.
Most don’t even have
basic support for relative or fluid units.
Rachel notes in the Almanac
that most lengths on the web
are defined in <code>px</code>.
Is that because authors intentionally avoid <code>em</code>/<code>rem</code>,
or because the mockups that we receive from designers
are all limited to <code>px</code> by our design<span class="widont"> </span>tools?</p>
<p>I’ve <a href="https://twitter.com/TerribleMia/status/1446262147772682260">commented on this before</a>:</p>
<blockquote>
<p>The least responsive part
of Responsive Web Design
is the design tools.
This needs to<span class="widont"> </span>change.</p>
</blockquote>
<p>When it comes to color spaces/gamuts,
design tools vary in support.
Looking at some of the big<span class="widont"> </span>players:</p>
<ul>
<li><strong>Adobe <span class="caps">XD</span></strong>
supports <span class="caps">HEX</span>, <span class="caps">RGB</span>, and <span class="caps">HSB</span>.
<strong>Illustrator</strong> adds <span class="caps">CMYK</span> and a grayscale option,
while <strong>Photoshop</strong> also supports extended gamuts
such as Display P3,
and perceptually-uniform<span class="widont"> </span><span class="caps">LAB</span>.</li>
<li><strong>Figma</strong>
(now also owned by Adobe)
provides <span class="caps">HEX</span>, <span class="caps">RGB</span>,
‘<span class="caps">CSS</span>’ (which is <code>rgba()</code>),
<span class="caps">HSL</span>, and<span class="widont"> </span><span class="caps">HSB</span>.</li>
<li><strong>Sketch</strong>
shows <span class="caps">HSB</span>, <span class="caps">HEX</span>, and<span class="widont"> </span><span class="caps">RGB</span>(a).</li>
</ul>
<p>I don’t know of any popular design tools
that provide <span class="caps">LCH</span>,
or the newer okLAB/okLCH variants,
let alone <em>relative</em> colors
defined as a function of mixing or adjusting
other underlying<span class="widont"> </span>colors.</p>
<p>And when it comes to copying our colors
out of a design tool,
the options are generally 6-digit <span class="caps">HEX</span>,
or copying individual channel values,
one at a time.
Either way,
converting our colors
into a more human-friendly syntax
would often be an extra step,
and may not be worth the<span class="widont"> </span>effort.</p>
<p>Since all legacy colors on the web
rely on a single color model (<span class="caps">RGB</span>)
and gamut (sRGB),
there has been little <em>meaningful</em> difference
between formats (until now).
Once we used a graphic interface
to pick the color we want,
it maybe didn’t matter
what format we copy-pasted into
a variable<span class="widont"> </span>somewhere.</p>
<p>But what’s the designer path
towards using new, extended color spaces in <span class="caps">CSS</span>?
Can they ever gain traction on the web
without first finding support in our design tools?
I’m not<span class="widont"> </span>sure.</p>
<p class="anchor-link-wrapper">

</p>
<p>Code tools also play a role in<span class="widont"> </span>this.</p>
<p>Sass, for example,
relies on the same
<em>interchangeability</em> of legacy web formats.
No matter what syntax an author chooses,
Sass will store the value as <span class="caps">RGB</span>,
and then allow manipulation
in any other <span class="caps">CSS</span> format.
But at the end of the day,
<em><span class="caps">CSS</span> output is always generated
in whatever format has the widest browser<span class="widont"> </span>support</em>.</p>
<p>It doesn’t matter to Sass
what syntax authors use
for their <em>input value</em>,
the <em>output value</em> is always
either <span class="caps">HEX</span> or a color name when opaque,
with <code>rgba()</code> for handling transparency.
Very few people need that level
of legacy browser support,
but it’s not hurting anything<span class="widont"> </span>either.</p>
<p>Not yet, at least.
This will all change going forward,
as we add
<a href="https://sass-lang.com/blog/request-for-comments-color-spaces">Sass support for more color spaces and<span class="widont"> </span>gamuts</a>.</p>
<p>In this case,
the Almanac may give us misleading info
about what syntax authors <em>prefer</em>.
For all we know,
authors might be <em>working primarily in <span class="caps">HSL</span></em>,
and we wouldn’t see that
in the production code at all.
In fact,
one of the most popular complaints
on the Sass issue tracker is
a request for <span class="caps">HSL</span><span class="widont"> </span>output.</p>
<p>But this is a distinction
with very little at stake.
So long as authors can use their favorite format –
and the output really does
provide the same <em>meaning</em> as the input –
it’s not a barrier for authors
using the latest color formats.
We’re just making that harder to<span class="widont"> </span>see.</p>
<p class="anchor-link-wrapper">
<h2 id="extending-vs-replacing-a-language" tabindex="-1">Extending vs replacing a<span class="widont"> </span>language</h2>
</p>
<p>In Sass,
we have a strict policy
that <em>valid <span class="caps">CSS</span> is always valid Sass</em>.
If authors use syntax that we don’t recognize,
we pass that along to <span class="caps">CSS</span>.
We can check for obvious parsing errors,
but only the browser can determine
if it’s a supported feature.
While we provide <em>extra</em> Sass support
for colors that we understand,
authors can use new <span class="caps">CSS</span> color formats in Sass
without us releasing any new features.
Sass may not understand those colors for a time,
but it will leave them untouched in the <span class="caps">CSS</span><span class="widont"> </span>output.</p>
<p>Similarly,
Sass hasn’t added support
for either <code>@layer</code> or <code>@container</code> –
and there may not be any reason to.
I’m already using both in my Sass,
without any<span class="widont"> </span>issue.</p>
<p>There have been unfortunate exceptions on occasion
(see <code>min()</code> and <code>max()</code> for example),
but we’ve worked very hard to remove those limitations
when they crop up.
The tool should never stand between
authors and the underlying<span class="widont"> </span>language.</p>
<p>Last month,
I spoke about <code>@layer</code> for
<a href="https://aneventapart.com/event/denver-2022">An Event Apart Denver</a>.
During the Q&amp;A session after my talk,
someone asked,
“How can I use this with <span class="caps">CSS</span>-in-<span class="caps">JS</span> tools?”
And the truth is…
<em>I don’t know</em>.
It depends entirely on the<span class="widont"> </span>tool.</p>
<p>Single-file components in tools like Svelte <span class="amp">&amp;</span> Vue
are <em>technically</em> <span class="caps">CSS</span>-in-<span class="caps">JS</span>,
but allow writing arbitrary/plain <span class="caps">CSS</span>.
I would expect (hope?) that
<code>@layer</code> should <em>just work</em> in that context
(similar to using<span class="widont"> </span>Sass).</p>
<p>But many <span class="caps">CSS</span>-in-<span class="caps">JS</span> tools
and utility frameworks
are more invasive –
replacing some or most <span class="caps">CSS</span> with a proprietary syntax.
They don’t provide <em>additions</em> to the language,
but a whole new language
that stands directly between us
and the basic <span class="caps">CSS</span> functionality we need.
There’s no option to write <span class="caps">CSS</span> directly,
we have to rely on the tool to do it for us.
<em>If the tool can’t do something,
neither can the authors using it.
All we can do is<span class="widont"> </span>wait</em>.</p>
<p>I even ran into this issue
by simply hosting my personal site
on Netlify,
which provides minification
for deployed assets like <span class="caps">CSS</span>.
That seems like a great feature!
But the specific <span class="caps">CSS</span> minifier that they use
is somewhat overeager,
and began stripping out all my new
<a href="https://css-tricks.com/css-cascade-layers/"><code>@layer</code></a> rules.
I had to turn off the minification step
in order to publish my entirely-valid<span class="widont"> </span><span class="caps">CSS</span>.</p>
<p>That shouldn’t be the case.
Minifiers shouldn’t need to understand
all the new features that land in <span class="caps">CSS</span>.
This is similar to the issue with
<a href="/2022/08/04/zero-units/">removing units from zero</a>,
or Harry Roberts’ recent warnings around
<a href="https://csswizardry.com/2022/09/critical-css-not-so-fast/">Critical <span class="caps">CSS</span></a>.
In a language like <span class="caps">CSS</span> –
where order is meaningful,
and duplicate properties are a useful feature –
it’s risky for automated build tools
to try and be <em>clever</em> about minification.
I don’t know that a <span class="caps">CSS</span> minifier
should do much more than white-space<span class="widont"> </span>management.</p>
<p class="anchor-link-wrapper">

</p>
<p>In regard to web fonts,
Bram points out
that authors are not taking full advantage
of variable fonts –
we’re mostly changing the font weights,
and selecting from standard<span class="widont"> </span>values.</p>
<p>As someone who has spent hours
searching through lists of variable fonts,
that doesn’t surprise me much.
Most variable fonts are either experimental display fonts
without a lot of practical use,
or they only provide a single weight axis.
While I love having all my weights in a single file
and smoothly transitioning from one weight to another,
<em>specialty weights</em> are not a high priority for me.
I’ll start using more powerful font variables
once there are more fonts available
with more interesting variables to<span class="widont"> </span>manipulate.</p>
<p>Most of us are also using
the over-complicated <code>font-feature-settings</code> property,
instead of the simpler <code>font-variant</code>.
I’ve been doing that on my site as<span class="widont"> </span>well!</p>
<p>Why did I think that was the best approach?
Likely because that’s the generated output
recommended by
<a href="https://wakamaifondue.com/">Wakamai Fondue</a> –
a popular tool for inspecting font capabilities.
It’s a great tool,
filling a much-needed gap,
but I wonder how the usage stats would change
if they updated their output<span class="widont"> </span><span class="caps">CSS</span>?</p>
<p>Maybe even more common,
much of the web is built using <span class="caps">CSS</span> libraries
like Bootstrap,
or third-party themes
provided by a site-builder or <span class="caps">CMS</span>.
The influence of both
WordPress and Bootstrap is clear
throughout the Almanac data.
When Rachel notes the popularity of
flexbox (very popular) vs grid (not so much),
I wonder how much of that
can be traced back to
Bootstrap ‘grids’
<a href="https://getbootstrap.com/docs/5.2/layout/grid/">being built in<span class="widont"> </span>flexbox</a>.</p>
<p>I don’t think that’s the only factor.
It’s possible authors have settled on flexbox as <em>good-enough</em>,
and they don’t think it’s worth their time
learning another technique.
I can understand that,
but it’s unfortunate.
I think people are missing out
on one of the coolest features
added to <span class="caps">CSS</span> <em>ever</em>.</p>
<p class="anchor-link-wrapper">

</p>
<p>When we talk about web trends,
I often hear people refer back to
the idea of ‘pace layers’ on the<span class="widont"> </span>web:</p>
<p><figure class="embed">
<figcaption class="caption">Described by <a href="https://adactio.com/">Jeremy Keith</a>
in his <a href="https://speaking.adactio.com/87IIn1">Building talk</a>
a few years<span class="widont"> </span>back.</figcaption></figure></p>

<p>In context,
Jeremy is not just referring to
the web languages themselves –
<span class="caps">JS</span> isn’t necessarily changing faster than <span class="caps">CSS</span> –
but also the <em>ecosystems</em> of these languages.
The closer we get to the core functionality of the web,
the slower each language/ecosystem is likely to change.
Even within a given language,
we expect our tools and conventions (<em>fashion</em>)
to move faster than the languages<span class="widont"> </span>themselves.</p>
<p>But that can only happen
if the tools are designed to
sit on top of their underlying languages.
Once the tools stand <em>between</em> us and the language,
we become entirely reliant on tool-builders
to determine what features are<span class="widont"> </span>available.</p>
<p>When our primary tools
intervene so strongly
between us and our ‘materials’ –
the core web languages –
we can accidentally flip the pace layers of the web
on their head.
Suddenly <span class="caps">CSS</span> is able to move faster than the ecosystem,
and we’re stuck waiting on our tools to catch up
with well-supported platform<span class="widont"> </span>features.</p>
<p>That’s not how a healthy ecosystem should<span class="widont"> </span>behave.</p>
<p class="anchor-link-wrapper">

</p>
<p>I am asked quite often
what I think about <span class="caps">CSS</span>-in-<span class="caps">JS</span>
or utility-first frameworks,
or even <span class="caps">CSS</span> libraries <span class="amp">&amp;</span> conventions
more generally.
And I try to stay out of any spicy flame wars,
or gate-keeping<span class="widont"> </span>nonsense.</p>
<p>For myself?
I don’t find many of these tools useful.
They don’t solve a problem that I have.
But different projects and different teams
have different needs,
and might find different tools useful.
There’s no single ‘correct’ approach
for writing all <span class="caps">CSS</span><span class="widont"> </span>everywhere.</p>
<p>As long as it results in an
accessible, resilient,
and performant experience for users:
<em>use whatever tools work best for<span class="widont"> </span>you</em>.</p>
<p>(Anyone marketing their product
as <em>The Only Solution™️</em> to some
<em>Essential Problem with <span class="caps">CSS</span>™️</em>
is selling you a religion,
not a<span class="widont"> </span>tool.)</p>
<p>It’s not my job to judge
what tools are useful for other web developers.
But it is my job to
help people think about the <span class="caps">CSS</span> choices they make.
So in that spirit, please<span class="widont"> </span>consider:</p>
<p>⚠️🚨⚠️
When tools intervene
between you and your access to the web platform,
<strong>proceed with caution</strong>.
Ask not only: <em>How well does it work?</em>
But also: <em>How well does it fail?</em>
Not only: <em>What features do they provide?</em>
But also: <em>What features do they prevent?</em><span class="widont"> </span>⚠️🚨⚠️</p>