Posts about CSS

After reading through Chris Krycho’s extremely cool and clever CSS mixin for light and dark variables, I was particularly struck by his conclusion:

The last couple bits I need to knock down to not need SCSS at all are:

• The equivalent of the nice @use directive. I think I might actually be able to use Lightning CSS directly along with its interpretation of native @import for bundling and minification.
• Applying the same approach to the syntax highlighting theme shown above for the syntax highlighting theme, for which I also currently use a @mixin the same way.

This got me thinking about what I use SCSS for these days. SCSS has been a constant part of my toolchain for twelve or thirteen years now; I feel like it’s been a part of my workflow forever. But it frustrates far more than it delights today, at least for me. The announcement of CSS Nesting in December gives me hope that a major reason to use SCSS is becoming part of the standard spec in the future.

Beyond that, here are the last couple things I need to not need SCSS anymore:

1. Like Chris, I need a good @use or @import directive. Today, this is SCSS’s best feature. I hadn’t heard of Lightning CSS before, but now I am going to check it out (although I am wary of replacing a well-known tool with a less well-known tool).
2. I think browser targets are helpful as a compilation feature, and I am unsure of a way to make that part of the default CSS spec.
3. I love using SCSS variables for media queries. @media (min-width:$bp-m) is far easier to use, in my experience, than @media (min-width:700px) or @media (min-width:45em). I understand why we can’t use environment variables, but it really is a shame I just can’t write @media (min-width:var(--bp-m)) and call it a day. I don’t know if I’ll ever get this as part of CSS spec. I’m also aware that best practice is probably to abandon variables in media queries and rely on something more conventional, but old habits…

I think the @use directive is the most important for my needs, and at a certain point, I’d be happy to give up futzing with the developer toolchain around SCSS compilation. Nothing has thrilled me more over my career than watching CSS improve and gain features over the past fifteen years. We’ve gone from floats to grids to crazy math formulas inside variables, and as a result, our layouts have been more less rigid and far easier to work with.

It’s still a great time to be a web designer.

A forewarning: Unfortunately, I am going to share a roadblock I ran into, rather than a solution. I am sorry if this post is a bit of a downer.

Recently, I was working on a website for a client that included vector images of maps. The maps look something like this. These are vector maps in a line art style, where the maps appear hand drawn.

Here’s an example design with the map, so you can see what I’m working with:

What I wanted to do was place an inline SVG on the page, then scale its size along with the page itself. So I wrote code like this:

svg.map {
	display:block;
	margin:0;
	width:100%;
	height:auto;
}

You know, your bog-standard CSS.

This works as expected: the SVG scales along with the width of the page, and the aspect ratio of the SVG never changes. (The aspect ratio in this example is not a known quantity, and the client could change this map at any time to a different location.)

Here’s the problem: as the SVG scales, the strokes in the SVG scale as well. On a phone, the map looks correct: 1px strokes surrounding each country. On a desktop, it looks ridiculous: the strokes are 20px wide. It’s as if somebody drew the map with a highlighter.

To fix this, I turned to vector-effect — in particular, non-scaling-stroke. As always, the MDN Web Docs page is very helpful.

Here’s the problem with non-scaling-stroke: It only seems to work if you scale the SVG with transform="scale(X,Y)". It has no effect if you are merely resizing the SVG with CSS.

So this code does not work:

<style>
svg.map {
	display:block;
	margin:0;
	width:100%;
	height:auto;
}
</style>

<svg viewBox="0 0 500 240">
  <path
    vector-effect="non-scaling-stroke"
    d="M10,20 L40,100 L39,200 z"
    stroke="black"
    stroke-width="2px"
    fill="none"></path>
</svg>

Instead, the path must look like the following:

<path
	vector-effect="non-scaling-stroke"
  transform="translate(300, 0) scale(4, 1)"
  d="M10,20 L40,100 L39,200 z"
  stroke="black"
  stroke-width="2px"
  fill="none">
</path>

This was a huge disappointment for me, and for a few peers I ran this problem by. We all expected my solution to work because nowhere in the documentation does it say that scale is required.

Either the documentation needs to get updated, or vector-effect​’s intended use needs to become more robust.

Richard Rutter shared an idea for limiting typographic widows with CSS. I love the simplicity of his proposal and would be thrilled if something like this were implemented as part of the core spec.