Roma’s Unpolished Posts

Apps with Presence on Mastodon

Thu, 13 Jul 2023 00:00:00 GMT

Current music:: The Appleseed Cast — Storms
Current drink:: Yunnan tea

Introduction

For a few years I had a “tools burnout”, where I almost completely stopped using various apps, tools, and plugins.

While all of these could be very handy, things can get overwhelming pretty fast. Every tool comes with a certain cognitive load: the necessity to learn it, to remember how it works, and then how to use it. Not always, it can be worth it. Another problem — the sheer number of options. Reading about all the tools that do a similar thing, comparing them, and trying them — all that takes a lot of time and effort.

What if I could simplify it a bit?

Recently, I decided to start using more tools again and looked into what was available.

One interesting approach I found for narrowing down the choices: choosing only the things that have a presence on Mastodon.

Why?

If it is on Mastodon, the tool is relatively recent, and has some level of support.
If the authors of that tool see Mastodon as worthy of their presence, they are likely to share a common set of values with me. But if they continue to use only Twitter or are happy to join Bluesky or Threads but not Mastodon, it is very telling.
With a tool present in Fediverse, I have a very convenient way to follow the updates for it or to reach its developers if needed.
And, of course, as I already mentioned, this narrows down the available choices a lot.

Things I Did Choose This Way

Overcast

@[email protected] — a podcasts app.

I got fed up with the Apple Podcasts app (it is bad) and decided to find something better. Even though Overcast is not available on macOS as a native app, it is possible to install the iPad version of it, and it works pretty nicely and syncs with the version I’m using on the iPhone.

NetNewsWire

@[email protected]) — an RSS/Atom reader.

I finally decided to return to reading RSS and wanted to find a good reader. NetNewsWire seems perfect now: it has a very similar feel to the Reeder I used a long time ago, is free and open source, and also syncs with the iOS version perfectly.

Obsidian

@[email protected] — a knowledge base/note-taking app from the authors of Dynalist.

I did know about Obsidian for a while and tried it once or twice, but I did not yet stick with it beforehand. The final straw was one post in mastodon:

This post did mention an article about a plugin for Obsidian that uses Leaflet under the hood (also on mastodon — [email protected]">@[email protected]) for an RPG dungeon map.

I knew that it was possible to create plugins for Obsidian, but only now has it clicked for me that it is based on the web platform: plugins can be written with JS and everything can be styled with CSS, with CSS snippets being a thing that people actively share. Edit: I already wrote an article about one such snippet — “Fixing Obsidian’s Markdown Display with CSS”.

There is also an unofficial Lemmy community for it, and I did subscribe to it in Mastodon, trying to see how the interactions between different entities in the Fediverse work.

Thunderbird

@[email protected] — an email client.

For a long time, I did use web apps, but I think it is time to get back to desktop apps. Owning your content is nice, and with the ways services evolve and change, relying on an online entity to store everything for you started to feel wrong to me. I would prefer to have all my emails on hand locally, available offline.

Astro

@[email protected] — a web framework this blog is running on.

I wanted to try it for a while, and one of the reasons was its presence in Mastodon. I think the front-end community is thriving on Mastodon, and I would not hesitate to recommend any newcomer join in — so many great developers and authors are now there!

Things I Used Before

The tools above were the ones I started to use after I joined Mastodon and decided to narrow down my choices based on Mastodon presence. But some tools I was already using were also on Mastodon.

iA Writer

@[email protected] — a markdown writing app.

I’ve been using it for years (since June 26, 2011, according to the receipts). As someone who has always loved typography, I always liked how they approached it in the iA Writer and on their site.

While I’m using other apps for notes, outlines, etc. (like the Obsidian I started using recently), I continue to use iA Writer a lot, as I genuinely love the writing experience it provides.

Pixelmator Pro

@[email protected] — an image and video editor.

I purchased it a few years ago and use it for any raster images I need to edit. I recently started using it for editing the videos of the examples I put in articles on my main site — it is very easy to cut and crop videos there.

Baba is You

@[email protected] by @[email protected] — my favorite game.

Surprise — it is not an app or a tool, but a game :) A very hard puzzle game, and I can recommend it to anyone. When I play it, it feels like it trains the same neurons that are responsible for CSS — utilizing, changing, and combining the rules on the fly to achieve previously unthinkable things through logical insights.

For now, that’s it! I will not update this list if I start using something else, but I might write a new post here about it (and cross-link them).

There is also another idea I had for a while — to create something like a “gear” page where I could gather and link to all the software and hardware I use. Maybe one day I will create it as a page on my site. We’ll see!

Let me know what you think about this on Mastodon!

Scroll-Driven Animations in Stable Chrome

Wed, 26 Jul 2023 00:00:00 GMT

Current music:: Mammal Hands — Floating World
Current drink:: White tea with litchi, pineapple, mango, and papaya

Before my first experiments with anchor positioning, I had not previously written about non-production experimental things. I’m usually very practice-oriented and like to play with things that I can just go and put into production. However, a lot of new CSS developments sounded too tasty to leave aside, and when playing with things, I found out that I have a lot to say and contribute.

While there is a long road ahead for anchor positioning itself, I did end up writing three articles about scroll-driven animations while they were being developed in Chrome Canary, describing a number of practical techniques:

I did start playing with them when they were under an experimental flag and continued when they were moved outside of it and planned for an eventual release. There were a lot of things I had to adapt to and change in my experiments through the implementation and specs changes — one of the aspects when you touch experimental stuff.

But I’m very happy with what I managed to achieve in my experiments.

Now, starting from Chrome 115, almost all of these experiments actually work in stable Chrome (outside one experiment using timeline-scope)!

That is a bit of a weird feeling. I did come up with a number of experimental techniques that have now become real:

:stuck implementation, which, I’d argue, is even more powerful than the proposed state query version.
Proper scrolling shadows
Fit-to-width text
Distributing values across a list of items
Staggered animations
Reverse layer ordering
Edge detection for elements on the edges of their flex or grid containers.
Flex-wrap detection.
…and I have a number of experiments and techniques I have not yet published— stay tuned!

How cool is it not only to get the new CSS spec’s implementation into a stable browser, but to already have a bunch of techniques to apply?

Of course, there is still a need to wait until other browsers pick up scroll-driven animations, but things seem to be positive: WebKit seems to be in support of it, and it sounds like Mozilla has already started working on the implementation. That means that, unless done with extreme care, we shouldn’t use these techniques in production.

But there is one place where we could already start playing with the scroll-driven animations: CSS overrides for sites that you look at in Chrome. That sounds like a good place where the low browser support won’t matter much, so keep that in mind: we can now tweak styles with scroll-driven animations!

Let me know what you think about this on Mastodon!

Not an Ideal Start

Sun, 09 Jul 2023 00:00:00 GMT

Current music:: Daughter — Shallows
Current drink:: Sencha tea

Introduction

Hey hey! This is the first entry in my new blog.

I did write an introduction to it on my site — you can read it there for my reasoning about why I did create it and what would be different from the articles on the main site.

In short: to have a more personal place, where I could share random things, experiment with new tech, and separate all of this from my regular polished articles about CSS and Frontend.

Though, at least initially, this blog still would be rather technical, but we’ll see how things would progress!

The Stack

Netlify — my main site is hosted there, the domain is registered with it, making it very easy to just continue using it. Almost no complains.
Astro — wanted to try for a while, and while it works, I’m not entirely sure I would stick with it. But at least for a while I’ll stick with it — would be unwise to dismiss it right away.
TypeScript — first time I’ll be using it outside of my work. I sincerely think that once you have it set up, it can help tremendously. I cannot imagine writing JS without relying on types — either with a proper setup or at least via a @ts-check in a .js file.
MDX — in all my previous blog iterations, I always pushed markdown to the maximum, inventing new syntax for the things I wanted to have in it and so on — the ability to rely on components and remark plugins would make the things I want to do with content much more convenient.

Everything Else — From Scratch

I decided to opt out of any built-in CSS from the Astro starter and not take anything from my existing site’s CSS. Having a blank canvas would allow me to experiment with CSS in any way I want, and I have some ideas of what I want to do here.

So, for now, you might notice the absence of almost any styles — things will change a lot in the future!

Bumps on the Road

I was a bit naive, thinking that starting from scratch with a modern stack would go smoothly. It didn’t!

Right away, I had a bunch of TS issues in VS Code, getting the “Cannot find module ‘astro:content’…” issue and others. Restarting the TS server did not help, and running astro sync did not help. Updating VS Code and restarting it a few times did help though. Things are overcomplicated in the modern front-end for sure.
When I was hooking up Netlify for my repo via netlify-cli, I had a few hiccups due to it using the same 3000 port for the thing it was doing as my Astro dev server that was running at the same time. Lesson learned: next time I’d like to set up a new Netlify site, I will stop the dev server right away.
The RSS experience in the Astro blog starter was not ideal:
- While I did choose to use TS, it came with the rss.xml.js from the box, so I had to rename it to rss.xml.ts and adjust a few type-related things inside ( - The BaseHead.astro template did not come with a <link rel="alternate" type="application/rss+xml" … />, so I had to add it manually.
- Not a big deal, but the generated RSS was not using Atom and did not have a language field, so I had to use the xmlns and customData to provide these.
I did not like how the content collections work in Astro: no good way to control the slug, provide default values for metadata based on the files, and some other issues. I think I would have to explore the integration API and remark plugins as a way to augment it to do what I want from it, but so far the experience was subpar.

But hey! Things work for now, and I will see how things would scale. Astro islands is also a thing that I really hope to delve into as a very convenient way to add dynamic content to my articles — and if that part would go smoothly, to see if I could somehow integrate it onto my main site.

That’s it for now! There are a lot of things I already want to write here, but I’ll try not to throw everything into one post.

Until later!

Oh, wait!

CSS Snapshot

Just for fun — not sure how long I could keep it up — I’ll try writing about which changes and additions I’m adding to the blog alongside every article.

With this article, here is the complete CSS I have in this blog:

html {
	color-scheme: light dark;
}

body {
	box-sizing: border-box;
	max-width: 42rem;
	min-height: 100vh;
	padding: 1rem;
	margin: 0 auto;

	font-size: 1.25rem;
	/* https://modernfontstacks.com/ */
	font-family:
		'Iowan Old Style',
		'Palatino Linotype',
		'URW Palladio L',
		P052,
		serif;
}

code {
	white-space: pre-wrap;
	tab-size: 2;
}

And that’s it. For now.

Other than the basic styles making things slightly more readable, I’m adding one thing I wanted to try for a while — relying on the built-in system fonts instead of any custom ones. I did choose the “Old Style” stack from a very helpful “Modern Font Stacks” project by Dan Klammer for now, but I’ll pay more attention to everything around typography at a later point.

Let me know what you think about this on Mastodon!

Astro MDX Components

Tue, 14 Nov 2023 00:00:00 GMT

Current music:: Sharon Murphy — Can’t Catch Polly
Current drink:: Cold Yunnan tea

Introduction

Today’s post is sponsored by me not knowing what I’m doing. In other words: fiddling with how my blog is built.

As I mentioned in the first post here, I’m using Astro framework and MDX for building everything.

Given Astro is a relatively new framework, I struggled to find solutions to some probably simple things I wanted to do with it.

In this post, I’ll document what I did find working for me, and maybe this could be of any assistance to others also struggling with Astro & its MDX integration.

Providing MDX Components by Default

The biggest reason I like MDX is because it allows a straightforward way of augmenting your markdown, as it is possible to provide your custom components for every HTML tag it will output.

The best part about MDX with Astro is that it builds everything statically by default, and if we provide any custom components to the underlying MDX, they’d be just rendered as plain HTML (unless we’d enable any dynamic islands).

I want to do numerous things with these custom components, and, the important part: I want to always use them.

The default way of applying custom components to MDX is by first importing right into your .mdx file, and then exporting them back as a components object. This is described in the Astro docs: “Assigning Custom Components to HTML elements”, and it provides this code snippet as an example:

import Blockquote from '../components/Blockquote.astro';
export const components = {blockquote: Blockquote}

> This quote will be a custom Blockquote

And that’s how I did do it, for every blog post… Not ideal. Is there a better way? When I was looking for it, most suggestions were to somehow pass components via remark plugins, but I’m not entirely sure if that would work with Astro. If it is up to me, I’d better not enter the plugins’ territory unless I really have to.

Finally, after a few attempts to find a solution, I found out that it is possible to provide custom components, but only if you’re using the “Content Collections” feature.

Basically, when we render a content collection, the final step to render the content to HTML is to do something like this (reduced snippet from the “Rendering content to HTML” section):

---
const { Content, headings } = await entry.render();
---
<Content />

What I did not find in the docs is that that dynamic Content component accepts a components prop!

That means that all I need to do to provide my default custom components is first

import Link from '@components/mdx/Link.astro';
import Paragraph from '@components/mdx/Paragraph.astro';
import ListItem from '@components/mdx/ListItem.astro';
const components = {
	a: Link,
	p: Paragraph,
	li: ListItem,
};

And then pass this object to Content:

<Content components={components} />

And that’s it — now every page rendered this way would automatically apply these components.

Accessing the Slots Content

Now that I have an ability to override the components, one thing that I want to do inside of them — access the content that is passed to them. Then, either do things based on what is inside, or maybe even modify the content. Why did I want this? Perhaps I’ll write about this one day!

In more traditional frameworks like React or Preact, we’d have the children in the props, which we could analyze or modify in some way.

But can we do something similar with .astro components? I did not find this ability initially, so used a bit hacky Preact solution for a while, but I was not happy with the solution I had.

After another attempt to go through the docs, I, finally, got to the solution: Astro.slots.render(). Here is the code example from this doc:

---
const html = await Astro.slots.render('default');
---
<Fragment set:html={html} />

The “default” slot is what would be in every MDX component, so now we can do anything with this html: it is just a rendered string with HTML inside. We could look inside of it, modify, and then pass further into any element via set: html Astro prop.

That’s It

Now I have an ability to do almost anything with the MDX components, without the need to include them every time I write a blog post. And also an ability to just use Astro components without any additional frameworks when all I want is to modify the final generated HTML.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 2

Sun, 22 Oct 2023 00:00:00 GMT

Current music:: Haisuinonasa — Dynamics of subway
Current drink:: Yunnan tea

Hey hey! Oh wow, I did not forget to publish this weekly post. Though, I wish I had prepared some of the links in advance as a way to speed up the process.

CSS Techniques and News

“When to use CSS text-wrap: balance; vs text-wrap: pretty;” by Stephanie Stimac — a comparison of two different values of text-wrap currently available in Chrome, alongside their use cases.
“CSS Text Level 4 Draft Updated” by Florian Rivoal — an important thing to mention in addition to the previous article, as the text-wrap naming would change to text-wrap-style eventually. Unfortunate that it did ship with the current name, with people already adopting it, but the new naming is a bit more clear.
Gecko’s “Intent to ship: CSS text-wrap: balance” — related to the previous two articles: it seems that Firefox wants to ship the text-wrap: balance anyway, and then later adjust to the new naming, making the situation slightly more weird, but also more interop?
“A Couple of New CSS Functions I’d Never Heard Of” by Chris Coyier — a nice little round-up of new CSS functions. I actually never heard about xywh(), and I already like how its name describes its API. Maybe we could rename border-image property accordingly, eh?
“@supports @property” by Jane Ori — a CodePen showing how we can detect the support of @property. A bit hacky, as we don’t actually have a native way to detect this, it relies on detecting unrelated features that shipped in the exact same browser versions that @property did.

The ability to test for this natively was resolved by CSSWG in the “Feature detection for descriptors” issue, though there are still unresolved issues like testing for preludes. Browsers are yet to implement this, though, and hopefully when they do, we will be able to test for things like @property natively.
Chromiums’s “Intent to Ship: CSS Scrollbars: scrollbar-color, scrollbar-width” — I’m not sure yet what I think about these — I understand that it is unlikely we’d get the much more powerful WebKit’s pseudo-elements, so having at least some standard way to control the scrollbars would be nice, but I’d really want to see the scrollbar-width accepting <length> instead of its current auto | thin | none.

I think one of the reasons not to have it was to prevent the scrollbars being too thin… But what if we’d just say “Treat any length value as something like max(thin, my-value)”? Basically, have the value that the scrollbar can get via thin be the lower bound, so we could still control the scrollbar width in a way that it would be consistent with other design elements.
Gecko’s “Intent to prototype & ship: CSS text-indent keywords hanging & each-line” — can be very useful for wrapping <code> elements (not to be confused with hanging punctuation).
Chromiums’s “Intent to Ship: CSS Exponential Functions” — I always welcome more maths into CSS, even though I don’t use it very often. But I know a lot of others do, and sometimes maths can unlock some interesting effects!
“Scroll-Driven State Transfer” — My fourth article about scroll-driven animations, where I explore how we can transfer the state of one element to a completely different place on a page by connecting them with a unique identifier in CSS via a timeline-scope.

Non-CSS Web Platform Stuff

“The History of editing and publishing in web browsers” by Alexandre Poirot — a bit of web browser history that I did not really know of or remembered.

Not Exactly New, but Noteworthy

Some links from a short Mastodon Thread about multicol by me:
- “CSS Multi-Column Layout block element breaking” by Scott Kellum — a “focus area proposal” for Interop 2024. I recommend voting for this issue — any improvements to multicol would be really awesome, it is a highly overlooked area in CSS.
- “Things We Can’t (Yet) Do In CSS” by Rachel Andrew — a 5 years old, but still actual article about various missing CSS multicol features. Curiously, some of them might be possible with the help of some of the newer CSS specs, though in a rather hacky way. I might write about this relatively soon.
- “Overflow in the block direction for continuous media” also by Rachel Andrew — a CSSWG issue about one of these issues which is almost impossible to do without a native support for it. From what I can remember, there are a lot of issues with fragmentation in CSS, and I think there was some work going on to improve it in general? Hopefully, one day, this would be sorted.
“CSS 2” — if you can’t find something obvious in the specs, try looking in CSS2.

A lot of things did not move to the new levels of specs, so a lot of basics and their nuances are still only there in CSS2.
“CSS Indexes” shared by Amelia Bellamy-Royds as a response to me sharing the previous tip on mastodon — a listing of every term defined by CSS specs.

My Bug Reports

“Tests for round(), mod(), and rem() that has a percentage only for one value” — my first PR to Web-Platform Tests. I wanted to try doing this for a while — write WPT tests as an alternative to just filling up the bugs in the browser bug trackers. I was told these, when merged, could automatically create these bug reports for the browsers that fail them? I’m very curious to see how the workflow would be with them.
“Regression: size value for box-shadows did stop working” — a rather weird issue in Chrome Canary which I can see on my work MacBook (and at least one of my colleague can as well), but I cannot reproduce it on my home MacBook. Maybe some weird environment issue? Hmm.

Upcoming Events

Usually, I’m staying at home, slowly working on my CSS articles and experiments, but this time I’ve decided to travel a bit. I did plan to attend Fronteers Conference this year, but it was cancelled — so I decided to visit the border: none instead.

October 26–27, 2023, “border: none 2023” — a non-profit conference in Nuremberg, Germany. I’m planning to attend it in-person, so if you’d be there — say hi! Otherwise, they’re planning to stream the talks, with the ticket starting from €30.
October 28–29, 2023 “IndieWebCamp Nuremberg 2023” — will be my first IndieWebCamp. Right after the border: none, hopefully I won’t be too exhausted after the conference itself.
October 30, 2023, “Weird Things You Missed About CSS” by Stephanie Eckles — a free online CSS Café event. I’ll be in a train back from border: none during it, but would try to attend if the Wi-Fi in the train will allow me!

And that’s it! I’ll be rather busy in the second half of the next week, so I hope I won’t miss posting the third post with the bookmarks. We’ll see, I guess!

Let me know what you think about this on Mastodon!

IndieWebCamp Updates

Mon, 30 Oct 2023 00:00:00 GMT

Current drink:: Cappuccino
Current location:: Espressolab, Theresienstraße 14, 90403 Nürnberg, Germany

Introduction

If you were waiting for my weekly list of links, I would publish it a bit later! As I did mention in the previous weekly, I did attend the “border: none” conference, and right after it, I did participate in the “IndieWebCamp Nuremberg 2023”. So, I did not have too much time to work on the weekly post — but I did gather some links and would try to compile them eventually.

I’ll omit most of what I learned during IWC’s first day; I think most of it would go into the weekly links post, and in this post I would just list things that I did add to my websites.

Microformats

I did add h-card and h-entry microformats to both kizu.dev and blog.kizu.dev.

I remember having an older version of microformats years and years ago over at my core site, but I did lose them with one of the redesigns.

Now was a good opportunity to add them back again.

Here are both of my PRs that did add them to my sites:

They contain a bit more stuff than just microformats, and the code inside is not that interesting, but you’re free to peek into them.

You can also look at the microformats validator results:

There were a few notes I took while doing this:

When validating things via the validator on indiewebify.me, I noticed a potential XSS issue and reported it on their GitHub.
I decided against using the outdated formats like hCard 1.0 (vcard, fn, etc), at least for now.
It is not always easy to add microformats after the fact:
- On my main site, I’m using a CSS grid for the article’s layout, and when I was implementing it, there were no subgrids (and even no good display: contents support), so everything inside my article is a flat list of elements. A bunch of microformats require wrappers, like the e-content for the h-entry. Maybe when I redesign or rewrite the site once again, I’ll take this into consideration.
- There seems to be no good way to provide data in microformats without actual elements in HTML. For example, I’ll be ok with providing my photo as a part of the consumed microformats but not as something visible on the site. Adding actual elements and hiding them did not sound good. I wonder if there might be better solutions, like involving <template> tag or something similar. Or maybe there is one, but I don’t know about it.
- I think it could be nice to have some ways to “connect” elements via some id references, like I’d want to have my h-card outside an h-entry, but mention it for the author field. The pattern I have noticed (and ended up using) is that very often the whole page becomes a h-card or h-entry, allowing nesting everything inside them and creating a semantic connection. However, I think there are enough cases to be able to connect entities that are located in different parts of a page.

Syndicating My Blog to My site

One of the ideas of the Indie Web is to own all your content and display it on your site in some form. I already publish my articles and my less polished posts on my own sites, but until now I did not have any connection between them.

In the time I had to work on it, I did manage to implement fetching my blog posts into my main site and display the most recent five posts as a simple list. I did not spend too much time on this list’s design; I just wanted the content to be there. After all, I’ll be redesigning my home page eventually and will try to incorporate these links in a better way.

How I ended up implementing this:

I output the metadata of the five latest articles on my blog in a JSON, creating it automatically when building the site.
- As I’m using Astro, I did add a src/pages/latest.json.ts file.
- I struggled a bit looking at what this file should return for Astro to properly output the JSON. Basically, [it needs to - Then, on my main site, I’m using the Hugo’s getJSON to retrieve this data and use it for creating this list.

That’s it!

Planned for the future

I think there are still a lot of ways microformats could be added and improved, but until I stumble across a need for something to consume them, I’ll leave them mostly be. Though, I think it could be a good idea to add some kind of test to my build pipeline that would parse the built pages and make sure microformats are present and result in the data I would expect. This way, any site refactoring won’t result in it breaking.

For the “self-syndicating” articles, I’ll need to implement the reverse: show the latest articles from my core site over at my blog. A few things to note:

I think I don’t want to get every article, maybe only “featured”? Though maybe, with me now having this additional blog, there is no need to make anything featured.
I want to make the websites rebuild automatically when one of them changes. I did look into how I could set this up — the build hooks in Netlify where I’m hosting both sites seem like they could do the job, but I’m a bit afraid to set them up in a loop: I’ll need to somehow make it, so only a commit would result in a rebuild, but not just any rebuild triggering an outside hook.

Final Thoughts

I always love working on my websites, and I always wish I had more time to do so. Having this dedicated time at IndieWebCamp to do just that was very nice!

I also met a bunch of new people and learned about a bunch of interesting things. I’ll try to compile them into the next weekly post, so stay tuned!

Let me know what you think about this on Mastodon!

Calculated Fractions (Report the Bugs!)

Thu, 23 Nov 2023 00:00:00 GMT

Current drink:: Peppermint tea

If you see something that you think should work in every browser, but it does not work in every browser, what would you do?

When I did encounter this issue a few months ago for the first time, I thought that maybe this was some obscure CSS specs limitation that did apply to my case.

What was that case? Using a fr unit inside calc() for CSS grids.

It does not work. You can check for yourself in this CodePen (unless you’re from the future, where this is fixed).

It does not work in Firefox, it does not work in Safari, it does not work in Chrome.

The first time I encountered this, I moved on. This, as a feature, would’ve been nice to have, but not crucial, and only as a part of an unrelated experiment. Moving on was a wrong choice!

Today, glancing over the “An Interactive Guide to CSS Grid” by Josh W. Comeau, I randomly remembered that I couldn’t use the fractions inside a calculation. Why was that again? Should I write an observation about this absence of a feature? I investigated.

Things I found:

There was already a bug filled in Chromium from August 2019 by Xiaocheng Hu.
At the beginning of 2022, Lea Verou did already bring this up to CSSWG in a “Should calc(1fr) be invalid?” issue asking if that is per spec, or a misunderstanding of a particular note in the spec.

Tab Atkins-Bittner replied. Here is what they said:

Definitely a bug; fr units should be math’able just fine. That note is, indeed, just observing that fr is not a <length> so calc(1px + 1fr) is invalid, but calc(1fr / 3) should be just fine.
While there were tests covering some fr cases, like properly disallowing it when used with the <length> units (like calc(1fr + 100px)), there were no tests assuring that just the calc(1fr) and similar would work.

So, per spec, this should work. It was even clarified by one of the spec editors! What does this mean?

That means that this is a good case, where filling up the bugs in other browsers, and writing WPT tests should be trivial and, hopefully, won’t be challenged.

That’s what I did!

I opened a Firefox bug.
I opened a WebKit bug.
I opened my third Web Platform Tests PR (open at the moment of writing this).
I cross-linked everything together, just in case (I like backlinks, and I think there should be more two-way connected pages on the web).

Writing this post probably took longer than doing the above (excluding the research time).

Now, one day, hopefully, we could use flexible lengths inside CSS calculations, and maybe what I did today did bring this closer to reality, even if a tiny bit.

Open the Bugs!

I did ask today in Mastodon what people do when they encounter a bug in CSS, in a form of a poll. So far, 61% (out of 164 persons) did choose the “ignore or work around it; continue with your day”.

That was what I did initially when I encountered this issue. It is easy to assume that something that does not work anywhere is “working as intended”. Every so often, it is not. Believe in your feelings! Try to question yourself less. Yes, you might be confused about something, and the issue is on your side.

However! My experience tells me that any confusion can be a very helpful flag for the spec writers and implementers that something could be improved, either in the specs, or in the implementation.

Whenever you encounter something weird, try asking about it. The #CSS hashtag works really well on Mastodon, for example: there are plenty of people who’re ready to help.

And, if you have time — I highly recommend reading the specs, looking if there are bugs filled, CSSWG issues, and WPT tests about what you’ve stumbled upon. Looking deeper into the problems is an excellent way to learn.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 1

Sun, 15 Oct 2023 00:00:00 GMT

Current music:: The Surrealist — Lux
Current drink:: Lapsang Souchong tea

Introduction

How funny — in July I did start my blog but have not posted since then. Isn’t that the fate of most blogs?

As an attempt to have something to write about at least on a weekly basis, here is what I think I’ll do: gather some of the interesting stuff I noticed during the week and just post these with minimal comments. Some of it I shared in my Mastodon already, but I think it could be useful, even if for myself, to have a compilation here as well.

Let’s go!

CSS Techniques and News

“Emulate basic relative color syntax with color-mix() + the none keyword” by Lea Verou. Given color-mix() is already supported in all major browsers, this is a really important find: it brings some of the relative color syntax abilities closer to us — if you can use this with proper fallbacks in a progressive enhancement manner, you can already do it!
“CSS Type Casting to Numeric: tan(atan2()) Scalars” by Jane Ori. A very cool workaround for the absence of an ability to remove units from the lengths in CSS calculations. Works (with some hacks) in Chrome and Safari, not yet in Firefox (as it requires @property). Given the trick is very simple, I might try it in some of my experiments. If you want this natively — vote for this interop 2024 focus area proposal by Scott Kellum.
“[css-backgrounds] background-clip: border-area” — a proposal in CSSWG issues by Lea Verou. I think it makes a lot of sense, though it might be a bit tricky to use correctly due to the necessity to make sure the fallbacks would work and would not result in unreadable text.
“The Cascade is a newsletter about the past, present, and future of CSS” by Robin Rendle. Two issues are already there and are also available on Robin’s website in a non-newsletter format if you prefer it this way.

Not Exactly New, but Noteworthy

“Igalia Chats” — a podcast by Brian Kardell and Eric Meyer about the web, its history, browsers and standards. I just finished listening to all the currently available recordings, and I wish there were more in-depth discussions about the web of this kind.
“ImageOptim 1.9.1” by Kornel Lesiński — a very useful macOS app for image optimization, now native for Apple Silicon.
“Orion Browser” and “SigmaOS” — interestingly, there are now new browsers that are based on WebKit, which is refreshing compared to most of them being based on Chromium recently. Similarly, the “DuckDuckGo” browser, which exists on different systems, just uses the built-in engine, so on macOS it also uses WebKit.
“preact-custom-element” — a Preact helper that allows it to be used with web components. I tried it for a tiny thing I’m working on, and it works okay. There are a bunch of bugs here and there, but otherwise I’m pretty happy with how web components, Preact and HTM can work together. No transpiler needed, small footprint.

My Bug Reports

“Scroll-margin does not work for an element with a parent that has a non-visible overflow” — a bug I reported in Chromium. There are actually so many more issues with scroll-margin and overflow… I’ll need to find time to extensively research it, as I think there is a very big gray area in both specs and implementations.
“No transitions of inherited properties when the change is triggered by animations” — another bug I reported this week, this time for Firefox. Also, it is slightly in a gray area, where specs are not 100% clear about how it should behave, but the way Chrome and Safari handle it are much more useful for developers. This might be required for a lot of techniques based on scroll-driven animations to work in the future, but it could still be useful even without them.

That’s it! I’m doing this today, so maybe there are not as many links as I could’ve gathered if I would note them as the week goes… We’ll see if the next post in the series will have as many or more — maybe not, given how this time there were two very nice CSS techniques shared by Jane and Lea, and this does not always happen, haha.

Let me know what you think about this on Mastodon!

Calculation Indentation

Sat, 11 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

Introduction

For some time, I struggled with some of the more complicated calculations in CSS. Not with their contents, but with how I would like to see them formatted.

Let’s say we have some CSS like this (taken from the styles of this blog):

body {
	--content-padding: calc(var(--MIN-CONTENT-PADDING) + clamp(0px, 100vw - var(--CONTENT-WIDTH), 2rem));
}

ul, ol {
	padding-inline-start: calc(2 * var(--MIN-CONTENT-PADDING) - var(--content-padding));
}

It is not the most complex CSS, but it is already difficult to read and maintain.

How Prettier Handles It

Let’s imagine we’d use Prettier for this. As I’m going to display it here in my blog, by default it has around 54 symbols available with the tab-size: 2. Putting these settings in Prettier gives us this:

body {
	--content-padding: calc(
		var(--MIN-CONTENT-PADDING) +
			clamp(
				0px,
				100vw - var(--CONTENT-WIDTH),
				2rem
			)
	);
}

ul,
ol {
	padding-inline-start: calc(
		2 * var(--MIN-CONTENT-PADDING) -
			var(--content-padding)
	);
}

Well, I guess, better, but I don’t really like Prettier’s way of bumping the indentation when wrapping a line of calculations.

And I never liked how Prettier formatted many other things in CSS, so I would probably never want to use it for my styles.

How I Ended Up Writing It

And here is what, after many thoughts, I ended up doing:

body {
	--content-padding: calc(
		var(--MIN-CONTENT-PADDING)
		+
		clamp(
			0px,
			100vw - var(--CONTENT-WIDTH),
			2rem
		)
	);
}

ul, ol {
	padding-inline-start: calc(
		2 * var(--MIN-CONTENT-PADDING)
		-
		var(--content-padding)
	);
}

A few things to note there.

Main feature I really liked doing: placing the + or - on separate lines. It is now much easier to spot different arguments of the calculations, and to spot what exactly is happening inside.
I think I prefer to keep the multiplication/division on the same line. Maybe even one day we would get the syntax sugar of using custom properties as custom units? Then it would be even more simple.
Yes, the code grows vertically, but I’m perfectly fine with that if that means things are easier to read. And, for more complicated calculations, that could give even better results.

Another Example

Here is another (again, rather simple) example, this time from my “Using the Connections” experiment of my “Future CSS: Anchor Positioning” article.

How I did write it in the article:

.tree-item-label::before {
  top: calc(anchor(var(--to) top) + 0.5 * var(--lh));
}
.tree-item-label::after {
  bottom: calc(anchor(var(--to) top) - 0.5 * var(--lh));
}

How Prettier formats it:

.tree-item-label::before {
	top: calc(
		anchor(var(--to) top) + 0.5 * var(--lh)
	);
}
.tree-item-label::after {
	bottom: calc(
		anchor(var(--to) top) - 0.5 * var(--lh)
	);
}

Verbose, but does not really help.

How I would now prefer to write it:

.tree-item-label::before {
	top: calc(
		anchor(var(--to) top)
		+
		0.5 * var(--lh)
	);
}
.tree-item-label::after {
	bottom: calc(
		anchor(var(--to) top)
		-
		0.5 * var(--lh)
	);
}

Now it is much easier to spot the main difference of the + vs the -, as well as distinguish between the calculation arguments.

It’s All Subjective

That’s just the way I, at the present day, decided to write my CSS. Maybe it won’t fit you! Perhaps I would change it later! Or there would be things I reconsider and add to this method! We will see.

Let me know what you think about this on Mastodon!

Observation: Clamp to Infinity

Mon, 13 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

Min and Max

A confession: I constantly get confused by min() and max() comparison functions — in CSS and JS alike. I often use them for the lower and upper bounds, and, in my head, it is not intuitive to use min() for the “upper” bound, and max() for the “lower”.

Overall, it frequently takes me a few moments to parse any code that contains these mins and maxes.

That’s why I really like the clamp() function for defining the bounds — I find it much easier to understand and parse in my head.

A Problem with `clamp()` in CSS

After another time of me using min() (or was it max()?), I wondered: could I just always use clamp(), even if I need to have only the lower or the upper bound?

The function itself does not provide a simple way to omit one of the bounds — all the arguments are required, and there is no none value that could be used instead of a value.

Update from 2024-02-19

On December 15, 2023, Lea Verou proposed a none keyword that could be used to achieve the same result that I’m referring to in this article.
On February 14, 2024, CSSWG resolved to add it to the specs!

Looking for a Solution

The first thought is to use a massive value, like 99999px for the upper bound, and a similar negative one for the lower. But I would really like to evade magical numbers like that, which, potentially, could backfire in case I’ll actually need to handle bigger values.

My second thought was: hey, didn’t we get the infinity in CSS recently?

<div style="
	border: solid clamp(-infinity, 1em, infinity);
">test</div>

Ah, but it does not work:

test

A live example that shows just an unstyled word “test”.

Of course, because infinity is a <number>, and clamp() requires all arguments to be of the same type.

My third thought was to divide by zero. A perfectly normal thought for me!

<div style="
	border: solid clamp(-1px/0, 1em, 1px/0);
">test</div>

This works:

test

A live example that shows a thick border around the word “test”.

Then I started to write this post and gather the links to specs, as I often do. And guess what, there is a note in the specs:

As these keywords are <number>s, to get an infinite length, for example, requires an expression like calc(infinity * 1px).

Of course, this works as well:

<div style="
	border: solid
		clamp(1px * -infinity, 1em, 1px * infinity);
">test</div>

test

A live example that shows a thick border around the word “test”.

I did use 1px * -infinity instead of -1px * infinity just to test that it works as it should.

But this is so verbose! Is the division by zero a hack? I’m not sure, but it is much more concise, and also is defined in the specs as a valid way to get the infinity:

Dividing a value by zero produces either +∞ or −∞, according to the standard sign rules.

Use Cases

Would I use this in the future? I don’t know. I think it is still a good idea to think of using the clamp() instead of the min() or max() right away — very often you’d still have to add the other bound later, and with clamp() it would be so much easier!

Another case where this can be potentially helpful is when we’re setting up some API using CSS variables — we could provide a way to clamp something optionally, where the default values for both boundaries would be infinities, but could be provided via CSS variables.

Aside: Starting to Record Observations

One thing I wanted to start doing — and this blog now would allow me to — start writing about some observations I sometimes make when experimenting with CSS. Not always something I find has obvious use cases, and not always I have time to write a proper long and polished article like I do at my main site. However, how many interesting things I did stumble upon and did not share in pursuit of perfectionism?

Posting every day for almost 2 weeks made me think a bit less about the polish of the text, and more about “just doing it”. Which I did try to do today.

Let me know what you think about this on Mastodon!

Observation: color-mix and currentColor

Wed, 29 Nov 2023 00:00:00 GMT

Current drink:: Karkade with raspberries

This post is sponsored by the second-to-last day of the month, and me not knowing what to write.

In frantic search for a topic, I remembered one thing I was keeping slightly under wraps — mostly because I wanted to do more experiments with it, probably fill more bugs, and, as usual, polish-polish-polish. But the whole idea of me trying to write more “observations” is to get away from it!

So, today I’ll share my observation: we can use the currentColor inside color-mix()! But only after I’ll share how we can modify the alpha channel of a color by using them.

Sounds simple enough and, maybe, obvious, but it works, look:

Component is not available in RSS, visit the the site to access it.

.context {
	color: hotpink;
}
.test {
	color: color-mix(
		in srgb,
		currentColor 50%,
		transparent
	);
}

<div class="context">
	<p>This is a very pink text.</p>
	<p class="test">And this one has 50% opacity.</p>
</div>

Right away, before I would explain what’s going on, I need to link to two things:

The “Emulate basic relative color syntax with color-mix() + the none keyword” by Lea Verou — I did already mention it twice on this blog. This is the third time!
This Mastodon post by Anne Sturdivant, in which she did, inadvertently, solved an issue I was trying to work around for some time.

Lea’s CodePen was about how we can use color-mix() and mix colors that have none for some color stops.

For a while, I was trying to do the same, but only for adjusting the alpha component of a color, like this:

Component is not available in RSS, visit the the site to access it.

.test-broken {
	color: color-mix(
		in srgb,
		currentColor 0%,
		rgba(none none none / 50%)
	);
}

<div class="context">
	<p>This is a very pink text.</p>
	<p class="test-broken">And this one should have 50% opacity.</p>
</div>

But that doesn’t work anywhere, really (I’ve yet to fill a bug for one of the cases). Or this:

Component is not available in RSS, visit the the site to access it.

.test-broken2 {
	color: color-mix(
		in oklch,
		currentColor 0%,
		oklch(none none none / 50%)
	);
}

<div class="context">
	<p>This is a very pink text.</p>
	<p class="test-broken2">And this one should have 50% opacity.</p>
</div>

This works in Firefox, works in Safari, but doesn’t in Chrome.

I even went to write web platform tests for that one (it was before I found out about the above issue), and they were merged, but! That’s still an ongoing thing, I’ll probably write about it at some point later.

Regardless. Now we can do this!

Component is not available in RSS, visit the the site to access it.

.test {
	color: color-mix(
		in srgb,
		currentColor 50%,
		transparent
	);
}

<div class="context">
	<p>This is a very pink text.</p>
	<p class="test">And this one has 50% opacity.</p>
</div>

It is the same example as the first one, and it should work everywhere.

The crucial parts:

We should use srgb. Other color spaces do not work the same for some reason (again — would probably need to investigate further — do you see how I’d want to spend more time on this instead of just writing about it?)
We should use transparent, and instead of having the alpha component there, we use the percentage with the first color!

Now — we can use this method to adjust (srgb) colors, and get their versions with alpha channel modified! All thanks to Lea and Anne!

Wait About CurrentColor?

I think I did sidetrack a bit. The other thing I wanted to share: that we can do this not just with some color, even if it comes from a CSS variable, but with a currentColor, even when used with color property!

Long story short: this works the same way as font-size: 2em. The em mentioned inside font-size is the inherited value of the font-size, and in the same way, currentColor mentioned inside the color is the inherited color.

I would really want to play with this a bit more, maybe involve @property in some way to see how things would behave with it, but I did promise myself that I need to learn when to stop — and here I am, doing this.

The browser support for color-mix() might seem pretty good, however, as you could see from all the issues around color spaces and mixing — it might not be as stable as we might think. I’ll be cautious before using this in production seriously, there will need to be a lot of testing, and a lot of cross-browser testing.

A quick test that I did with this shows that Safari, Firefox and Chrome all render something in it differently except for the srgb with transparent method, which, I think, we could cautiously start trying.

But even if this is still unstable — I really encourage you to experiment with this. Try other color modes, try other ways to mix things up — and give your feedback to browsers! color-mix() is very powerful, and the sooner it will become stable, the better for everyone.

Let me know what you think about this on Mastodon!

Fixing the Custom Ident Docs

Mon, 20 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

Two days ago, I published a post named “Dashed Idents for Everything”, in which I did say that we could just use dashed idents in place of custom idents in CSS.

In one of the replies, Taylor Hunt did mention that on the MDN page for custom idents it did state that we cannot use dashed idents instead:

A <custom-ident> must not be placed between single or double quotes[…]. Moreover, the first character must not be a decimal digit, nor a hyphen (-) followed by a decimal digit or another hyphen.

Well, I just had to go do some more research: did I miss something in the specs? But no, wherever I did look, everything did seem to be ok with the dashed idents usage for custom idents. Browser testing did not also show any discrepancies.

So, I did go and fixed this on MDN via a pull request. It is now merged, and my post does no longer contradict MDN.

Docs are not always correct — even when they’re written by humans (these written by LLMs could just go straight to the trash bin). If something seems weird, like if you notice a perceived difference between what is written in the docs and what you experience in practice — the best course of action is to do your own research and go and fix the docs. Or, at least, report this to the project. If I did not have opportunity to contribute this time, just filling an issue for MDN content would’ve been enough.

Anyway: contribute in any way you can! Report the bugs, write the tests, do the research, send the PRs. As with everything, at the start you might not know what to do, but when you’re used to it — this is the best way to interact with the web platform.

Let me know what you think about this on Mastodon!

Dashed Idents for Everything

Sat, 18 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

What do you think when you see --foo in CSS? Is this a custom CSS property? Maybe, but not necessary.

It is a “dashed ident”, which is a variation of a “custom ident” (an author-defined identifier).

You can read why we have these in the specs by the links above, but the main difference is: in the dashed ident there are two dashes at the start. That’s it, that’s the whole difference. At least in how it looks.

But there is a big difference in how it works.

Not all places that accept a dashed ident would accept a custom ident.

If something wants a “dashed” one explicitly, for example, anchor-name in anchor positioning, or a view-timeline-name in scroll-driven animations — they won’t accept a regular ident.

When first encountering this difference, it might be challenging to adjust initially — and I did actually mention this in my article about anchor positioning:

One common mistake I initially had in my experiments — using the names without the double dashes in the beginning. The spec defines the names as <dashed-ident>, so they won’t be your usual idents, like with animation names or grid areas, but more like a CSS custom property’s name.

My solution to this problem? See the title of this post. We can just use dashed idents for any author-defined identifiers. Yes, not all places would accept a custom ident, but any place that accepts custom idents, would also accept a dashed one.

By doing this, we achieve the following:

We don’t have to remember if something accepts a custom ident or a dashed one.
We make it easier to understand that these idents are author-defined — the main reason to have them was to be able to distinguish them for the parser in places where there might be both author-defined identifiers present and other CSS keywords. There will never be a conflict between a dashed ident and a CSS keyword, this is guaranteed.

Yes, the syntax is a bit more verbose, and yes, you might get used to dashed idents only being used for CSS variables. But that is changing, and I suspect more and more specs would allow only dashed idents, just because this makes writing the properties’ syntax definitions much easier.

What are the properties that we could start dashed idents for now?

The counter name in CSS counters:
- counter-reset: --foo 1;,
- content: counter(--foo);, and so on.
Keyframes’ names in CSS animations:
- @keyframes --foo {},
- animation: --foo 1s linear infinite;, and so on.
View transitions names (I was a bit surprised that these were not required to be dashed):
- view-transition-name: --foo;.
Named grid lines and areas in CSS grids. Ok, this one might be controversial, just because the definitions that are already rather verbose could become even more verbose. However! A usual mistake I do with CSS grids is using a string for the area name when doing something like grid-column: 'foo', which, obviously, won’t work. I think this can often happen if you’d define the grid-template-areas as an ASCII string — it is logical to follow-up with it with a string usage as well. Using a dashed ident could remove this issue.
- grid-template-areas: "--start --content --end", or even
- grid-template-rows: [--header-top] auto [--header-bottom --main-top] 1fr [--main-bottom]
But yes, it can get verbose. But I think it is still worth it.

Did I miss something? Maybe!

I have been using this notation for a while, and so far, I’m happy with it. If you’re attentive, you could’ve noticed it in my previous post, where I used it for the keyframes’ name! One thing I wanted to try: create a stylelint rule that would enforse this. Maybe one day.

Let me know what you think about this on Mastodon!

Extra Nesting Specificity

Fri, 24 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

Exactly a month ago, I started a thread on Mastodon about unlayered styles, which led to me bumping the corresponding CSSWG issue a bit more than two weeks ago (here is my short post about this).

There was one CSS hack I did share in this thread which I did not yet write about in this blog, which I’m going to do now!

Say welcome to… whatever this is:

*:not(#a#b) {
	& .whatever {
		…
	}
}

So, what we’re looking at? I present you a kind of workaround for the inability to use layers when there are unlayered styles present.

With CSS nesting now available in all major browsers (at the time of writing, I would still not recommend using it in production), we can easily add almost any selectors to our code as a wrapper, making it very convenient to write code without remembering that we have to mention something for every rule.

The & .whatever part in the above example is not interesting — there might be any nested rules, with almost any selectors nested right inside our root selector.

The point is: our root *:not(#a#b) would bump the specificity of anything nested inside by exactly two ID selectors.

The best part: this selector will always apply, is fast, and should never fail.

In the case of our .whatever class, we can think of the final selector as

*:not(#a#b) .whatever {}

This selector should match for an element with the class whatever if any (regardless of type, explicitly represented by a * for clarity) of its ancestors does not contain both an id with the value a and an id with the value b.

Obviously, an element cannot have two different IDs at the same time, but the selector is nevertheless valid, and, because it uses :not(), it would match for anything.

The only case where we’d have to be careful: if we’d want to match the :root or html (and maybe in some other rare cases), in which case we’d have to write &:root or &:is(html) inside the nesting. If we don’t have a parent to check — the selector would fail, so when we know of this, we’d add this selector directly to our root elements.

Did I mention that this selector will be fast? Browser engines match the selectors from right to left, so in this case they will first match the .whatever, then will look at this element’s direct parent, see that it does not contain two IDs, and stop. Only one parent node to check! And, because it is guaranteed that we’d stop matching on the first parent, it is not necessary to use the child combinator like & > .whatever.

It is also rather easy to fake “layers” with this method: just keep adding IDs inside the :not() to bump the specificity up, as a way to separate one group of rules from another!

I find this method very useful for custom website CSS overrides, as it is very rare that a site would have more than one id in a selector. The bigger problem is if there is an !important somewhere, and that’s why it would be nice to have a proper way to handle unlayered styles, and put another layer on top of them.

Let me know what you think about this on Mastodon!

Observation: Range Input’s Thumb and Emerging CSS

Wed, 15 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

A Long Prelude

Today would be a quick “observation”, but a longer prelude. I did stumble upon what I’ll elaborate on today back in June, see this CodePen, but for several reasons I did not share or write about this. These reasons:

Fun fact: I never did really work with range inputs, so before I could do more experiments, I would need to learn much more about them.
I have no idea about their cross-browser compatibility, and the way they and their styles are specified. What are the differences? How likely my experiment could apply to other browsers when they’d get the features I’m using?
I did not have good use cases which to present. Usually, my experiments are very technical: I either achieve some effect, or not. And later, when I’m writing an article, I struggle the most with the actual examples. Like, I have all the use cases somewhere in my head, but it is always hard for me to actually access them. And I’m terrible at design — it takes me countless iterations to come up with something nice.

These reasons, and other things my perfectionism used to contribute, were why I did an experiment, found something for myself, and moved on.

Now that I started trying to write more regularly, write about less polished stuff, and not pursue a perfection (at least not always), I want to continue posting just these small experiments and observations.

I can see how just sharing a technique behind what I’m doing can help eventually.

Yes, perfectionism tells me: “But hey, you could do so much more! Open a CSSWG issue! Read the specs! Experiment on this for another 20 hours!”

I need to learn not to do the maximum, but just share the minimum. The best part: I already have so many drafts of things that I want to do in a more perfect way, unless I’ll clone myself I won’t ever get to do all of that. So, a compromise of just throwing a seed of an observation when I know I cannot grow it fully is something I’m trying right now.

To the Point

If you did not yet look at the CodePen I mentioned before, now is the time! Ah, and look at it in Chrome, ideally in Chrome Canary with the Experimental Web Platform feature flag on.

This CodePen shows two things:

We can define a view-timeline on a ::-webkit-slider-thumb, and then use this timeline to get the slider’s position!
We can define an anchor-name on the same pseudo-element, and target it with anchor positioning!

Ah, and as a bonus, I did also use another method to pass the hovered state from the thumb to the label outside. We cannot use :has() with pseudo-elements, so this is the only way I know we could do something like that.

Can this unlock numerous possibilities for styling the range input? Allowing us to use it to control things outside without JS? Maybe!

But, as I mentioned in the prelude, — I’m not optimistic that this technique would work in other browsers when scroll-driven animations and anchor positioning would get implemented in them. But maybe?

An Occasion to share

If I first experimented with this in June, is there a reason I’m sharing this particular example now? Yes.

This morning I saw this CodePen by Adam Argyle, shared on Mastodon by Chris Coyier.

In this CodePen, Adam demonstrates how we can create an image comparison widget using a range input and just a tiny snippet of JavaScript to apply the current input’s value as a CSS variable, which is then used in all calculations.

Me, remembering my summer experiment, instantly went and forked this CodePen (view in Chrome), replacing this JS with this method using scroll-driven animations to pass the current range input’s state.

It is nice to have a good use case to apply a technique!

Future Observation

In the Mastodon thread about this, Bramus did also share his solution for this, also using scroll-driven animations, but in a different way. I did share another observation later, but I’ll save it for a future blog post. After all, I’m trying to post less polished things, right? And having an already decided topic for a future post is nice as well!

Let me know what you think about this on Mastodon!

My First “Fediversary”

Mon, 06 Nov 2023 00:00:00 GMT

Current music:: Sigur Rós — Ágætis Byrjun
Current drink:: Sweet herbal tea (it is camomile and honey, but I don’t sense it)

Technically, I tried Mastodon for the first time on April 06, 2017, and tried again a few times over the next few years, but it did not stick with me at the time.

I have some hobbies, but I’m not that deep into them. Not as deep as I’m in CSS and front-end, and, at the time, it was rather lonely to not have the people I enjoyed following for years around.

That did change when Miriam Suzanne opened the front-end.social instance, and my presence there is what I’m celebrating today.

I can say that, right now, almost everyone I care about in the front-end world is present either on this instance or in its neighborhood — having a dedicated place for active, sensible people made the whole experience good enough. Critical mass, all of that.

Since the time the LiveJournal started to lose people due to all the social networks pulling people out into their nets, I always had this thought that it is not the place that is important but the people there. Sadly, at the time, people did not really move to just one social network — some moved to twitter, some to facebook, to instagram, somewhere else.

LiveJournal was mostly pseudonymous, allowing you to create connections with people you would never meet in real life and who had completely different lives from you. The real-name policies of most social networks and the absence of control over your community led to people dissipating into the air. I could follow some of my older friends to one place, but not to another.

Even though most of the people I follow on Fediverse now are on Mastodon, I really like the idea that it is possible to have different types of networks, all connected, where you would not need to go and create another separate account in order to follow and connect with someone.

Like, there are things like Pixelfed, Bookwyrm, and the whole IndieWeb way of connecting your website as almost a first-class citizen to the Fediverse (see Bridgy Fed for example).

Now, even if something happened to front-end.social in the worst-case scenario, I believe things would still be ok. People would move to other places in the Fediverse, could keep following almost everyone they did previously, and ideally could move all the followers along with them (though I wish Mastodon did provide some backup mechanism in case the server goes black, and you’re unable to set up the migration).

All in all, I’m very happy to be on Mastodon and a part of the Fediverse as a whole. To the next anniversary!

Let me know what you think about this on Mastodon!

Layer Overrides Update

Thu, 09 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

Two days ago, I wrote an “Unlayered Styles Issue” post, where I shared a link to my comment in a GitHub issue about unlayered styles.

Since then, there was a brief discussion, after which the issue was reopened — yay!

Now, the question is: what should be the direction the issue would move towards. There were a few different proposals over how to allow putting styles after the unlayered ones, the best one was first proposed by François REMY:

Another possibility is to add another layer that is not the unstyled layers but is one just after it. Then confusion drops a lot I guess, especially if we give it a better name.

Something like @layer !important.xyz { ... } where the !important layer is a special layer that is above the unstyled styles.

I did not first see this proposal, but after some thinking did propose essentially the same in my most recent comment there:

After some thoughts, my idea: what if we’d have a single, system layer which could be used to place other layers after the unlayered styles?

Let’s say this system layer would be named !overrides. Then, let’s say it places nested styles after the unlayered styles only within the same parent layer (if any).

What this would mean:

We cannot create an arms race, as we have only one entry point for every layer that can be used to put styles into an “overrides” part.

As we can put other layers inside this layer, we could continue to write our new styles using layers in any way.

We don’t need to handle any specific syntax or complexity outside adding this one specific named layer.

See — basically a repeat of what François wrote.

I really think this is the best out of all proposals there. And, I think I could even use it inside the other layered styles I could write, as a way to first write some unlayered defaults:

@layer my-component {
	.my-component {
		/* some styles */

		&:is(:hover, :focus-visible) {}
		& + & {}
		/* some other styles with any specificity */
	}
}

Then, if I would want to add some modifiers to this component (let’s put aside if we actually want to have a layer per component), but would like these modifiers to go over the component’s styles, I could do this:

@layer my-component {
	.my-component {
		/* some styles */

		&:is(:hover, :focus-visible) {}
		& + & {}
		/* some other styles with any specificity */

		@layer !overrides {
			&:disabled {
				/* Some styles, now guaranteed over any
				   default styles. */
			}
		}
	}
}

If I wanted to add multiple different layers as overrides, then I could either use the same dot notation to make each of them @layer !overrides.disabled etc., or I could nest (or import!) these as their layers inside our overrides:

@layer my-component {
	.my-component {
		/* some styles */

		&:is(:hover, :focus-visible) {}
		& + & {}
		/* some other styles with any specificity */

		@layer !overrides {
			@layer disabled {
				&:disabled {
					/* Some styles, now guaranteed over any
					   default styles. */
				}
			}

			@layer something-else {}
		}
	}
}

But, of course, the main profit would come from an ability to add any styles after unlayered styles in the topmost unlayered context, where there is no a single parent layer surrounding our content. All these cases would become possible:

Adding custom browser style overrides in browser extensions like Stylus — now without any need to care about the specificity of the selectors on the sites we override!
Adding custom styles for Mastodon instances: it would be much easier to write them with this, as it would be possible to write some kind of reset for everything. And then have this reset be in its layer, allowing to write new layers with simple styles using only what is necessary in their selectors.
Writing layered styles for anything new in legacy environments: like, let’s say you have an older website, where you don’t want to wrap all the existing styles in a layer, as you would rather not reduce the browser support for all the existing styles. Now we would be able to write new styles that are guaranteed to override the old styles, with layers. This is especially crucial for older sites, where non-BEM (and not idiomatic in any way) selectors could contain multiples ID selectors in them, and just be very unpleasant to work with.

There are so many cases where I would already start using CSS layers, but can’t because there are some unlayered styles getting in the way. I really hope we would get the ability to do something about this sooner rather than later.

Let me know what you think about this on Mastodon!

Moving to Firefox

Wed, 08 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

What I Had Before

I tried the Arc browser for a few months, and finally decided that I don’t really like it that much.

The main thing that I would miss is the “little arc”: the temporary window for new tabs and for the tabs from external applications.

Other than this, I tried using a lot of its features, but was frustrated at a lot of small bugs here and there. And it did seem like with each release things got worse and worse. Most of my issues were related to window management and multiple monitor set up: not remembering the window size and position, boosts window opening weirdly, incorrect behavior of maximize button and double-clicking on browser window edges among other things.

The last straw was when I saw how it applies the custom styles from its “boosts” feature — as user agent origin! You could ask why this is an issue. This makes it, so any overrides require adding !important — without it, they would always be lower in the cascade compared to any styles on any elements.

I suspect this was a decision based on “oh, but the important styles from the user agent would win over anything!”, but yeah, this makes things much less convenient to override. I wish we had the ability to use CSS layers for overrides!

Anyway.

What I’m Moving To

Now, I’m starting to migrate (slowly) to Firefox Nightly.

Why “Nightly”? A lot of my custom styles require :has() support, and — yay! — Nightly already supports it well enough.

Here is a small list of add-ons I’m currently trying (thanks, Vadim, for some of your recommendations!), in alphabetical order:

Awesome RSS — Show the “RSS” button in the address bar for the sites that have it.
Firefox Multi-Account Containers — I think I had some cases where I would use this, but as I’m just migrating, I have not had a chance to use it yet.
LanguageTool — The grammar checker I’m using.
Stylus — Adding CSS overrides to the websites.
Tree Style Tab — I like the idea of displaying tabs as a tree when doing some research. I wish there was a simple way to just hide the existing tabs, though.
uBlock Origin — Content blocker.

As I’ve just started, I have no idea how things work, what the best settings are, or how to customize things further (I know that you can do a lot with CSS, which is awesome).

If you’ve got any preferences, add-on or setting suggestions, or just life hacks, throw them at me!

Let me know what you think about this on Mastodon!

My First Web Platform Tests

Fri, 03 Nov 2023 00:00:00 GMT

Current music:: Haisuinonasa — breath on one night
Current drink:: Yunnan tea

Introduction

I wanted to start contributing to the Web Platform Tests for a while, and a few weeks ago I finally got to read the documentation and push my first commit there, with another one following suit today.

I found it easy in some ways and hard in others, so I decided to share what I had to do in order to contribute, along with some links you might find helpful.

Why Contribute to WPT?

Like bug reporting itself, contributing to WPT might seem daunting and rather bothersome at first glance. However, the best thing: do it once, understand how things work, and the next time it will be much smoother.

By following all the steps, like properly reducing the bug (this in itself is probably worth a separate post), understanding the issue, and reading the specs, you’ll learn so much! It is much better to understand what you’re doing and not just throw things at a wall, waiting until something sticks.

By reporting the issues you find, you contribute to fixing the problems at their core. It is useful to find workarounds and share them, but it is even better to report the issues (and the actual bug reports are a good place to mention your workarounds as well!).

And by writing the tests for the Web Platform, you make it even more likely that the issue will be fixed. If the problem is in the Interop initiative, it could get picked up much quicker. And some browsers monitor the new failures in WPT, for example, Firefox opens new bugs in its tracker automatically.

The Docs

The place to start would be the official documentation site: https://web-platform-tests.org/

There is a lot, but overall, I found most of the information I needed.

As I’m mostly interested in writing CSS tests, I had no need to read all the documentation; I only needed to read the parts required for what I wanted to do. This is the approach I’d recommend for any docs— unless you’re really interested in everything, usually it makes sense to only go into sections that you need now and try not to read anything that would not help you solve the problem at hand.

For example, I only updated the tests using testharness; for these, I have no need to use the run command, only the serve one.

My Contributions

In this section, I’ll just put links to the WPT PRs I did open, so you could look at how I wrote them and the PR description:

Note that neither adding tests nor opening bug reports guarantees that the problem will get fixed soon. But by doing this, you’re making the fix more likely, and this helps everyone in the long run.

My Workflow

The way I contributed to the WPT was as an alternative to the first step of reporting the bugs. Usually I just went and reproduced the issue somewhere (like in CodePen) to understand the exact issue, then went into the browser’s bug tracker and tried to find the bug. Then I would create one if one was not found, post my use case into the existing one, or just star or cc myself for it.

With WPT, there are a few extra steps.

Initial Investigation

Make sure you can reproduce the issue in the latest version of the browser (s) you see the bug in. Very often, it might be something that is already known and already has a fix on its way. If you cannot see the issue in the latest version, then there is a big chance that it is already fixed. The latest versions I’m usually checking things in are (don’t forget to update them before checking):
Make sure there is a bug: usually it is enough if there is a difference between browsers, and this difference is there because of the vagueness of the specs. Yes, you’ll probably need to read some specs to see what the intended effect is. After all, you might find out that the browser-outlier is actually the one rendering things correctly, and you’d need to file a bug against two other browsers.
Check if this is a known issue. Before, I only checked the bug trackers, now this consists of two steps:
- Go to https://wpt.fyi/ and try to find the test suite for the feature you want to report the issue to. It is likely there is already a related test that fails — sometimes it might have a “bug” icon near it, leading to the browser’s bug tracker. If there is a failing test but no bug mentioned, you might want to check the bug tracker to see if there is a place you could put your use case or help prioritize the fix.
- Go to the browser’s bug tracker and try to find the issue you’re having. Usually, I’m looking only at the open bugs, but sometimes, if you do not find anything open that fits your case, it might make sense to look at the duplicates as well, as they could point towards more generic open bugs that you did not think fit your case. Links to the browser bug trackers:
  - Safari/WebKit
  - Firefox/Gecko/Mozilla
  - Chrome/Chromium/Blink
    
    Note that in January 2024 Chromium tracking will migrate to the Google Issue tracker.
Now, if you did not find the existing bug, or if you did find one, but it did not have WPT tests for it, or the existing tests did not cover your specific case, this would be the time to go and attempt to contribute to WPT.

Writing The Test

Note: for now, I only contributed to the testharness unit tests by modifying the existing test suits. Writing a new test (and writing reftests) is a slightly different beast; when I do that, I’ll try to update this post. However, a lot of what I’ll mention should apply to the new tests as well.

At this point, you should already have a minimally reproducible case. If not, now is the time to finally remove things from your example code to find the point where the bug becomes obvious.

Cloning the Repo and Setting Things Up

I’ll write what I did — I’m on macOS, for you, the setup could be different.

Usually, it is recommended to first fork the repo, but I found it worked better for me to clone the repo first and then add a fork as an additional remote.

Clone the repo: git clone [email protected]:web-platform-tests/wpt.git.
Fork it through GitHub UI.
Add the fork as a remote, in my case, it was git remote add fork [email protected]:kizu/wpt.git (obviously, use your own URL there).
Set up the hosts file: ./wpt make-hosts-file | sudo tee -a /etc/hosts (note that there is a sudo command — if you’re cautious, you could go into the repo and see what this would do).
Run the dev server: ./wpt serve.
Find the port where it did open it: basically, one of the https on port … entry, for example, one with Starting https server on https://web-platform.test:8443. There might be multiple of them, all working. I’m not sure what the difference is, to be honest.
Open the URL in your browser — it should work (though it might complain about the certificates). Now you could navigate inside to any test and check it out, or you could find the relative URL for the test you want to find and go to it there directly.

The main problem you probably have now is finding where to place the test.

Where to Place the Test

In my case, it was these places:

css/css-values/round-mod-rem-computed.html
css/css-color/parsing/color-computed-color-mix-function.html

There are multiple ways to look up an appropriate place:

Use https://wpt.fyi/ to find the place that seems like it fits.
Use the GitHub code search at https://github.com/web-platform-tests/wpt with some parts of the code you did find a bug in to find a place that looks similar to what you want to add.
Use the search in your editor of choice for the cloned repo to do basically the same.

When you first read about the reftests, it might seem that they could be the best way to add tests — but, in my opinion, it is better to first try and find a testharness place to add a smaller unit test.

These run much faster and are much easier to test automatically. I suspect that if I wanted to test the reftests automatically (outside manual comparison in the browsers — a valid way in itself), you’d need to set up the ./wpt run command (which I did not).

Add Your Test

The testharness tests usually test a bunch of different combinations and permutations of things.

As they run fast, it might make sense to add a lot of them, but only if the cases make sense. The problem of “what exactly to add as unit tests” is a much bigger issue, and I do it rather intuitively, based on my experience. Not too little, not too much — just enough to cover most of the cases I can think of at once. There is no need to do the same thing with different input unless the difference is obvious.

Commit & Push the code to your branch, open a PR

I won’t provide a git tutorial on how to create a branch and all, main thing is not to forget to push your branch into your remote fork, like git push -u fork my-branch.

Similarly, in this post I won’t describe how to open a PR or what to write there — I think I already wrote a bit too much for what I initially thought would be a short post!

Maybe I’ll cover the way I tend to write PR descriptions at a different time.

That’s It

Both my PRs were reviewed and merged rather quickly without any issues. Thanks, David Baron and Chris Lilley for reviewing!

After the PRs are merged, I prefer to wait until WPT builds the tests, and it would be possible to see the new failing tests at https://wpt.fyi/. Then it would be time to report these bugs to the trackers.

Hopefully, you found this post useful! I highly encourage you to try and get into the groove of getting to the core of the bugs you encounter, reporting them and maybe even writing WPT tests yourself. It might be a bunch of work, but it is worth it, in my opinion!

Let me know what you think about this on Mastodon!

One Month of Writing

Thu, 30 Nov 2023 00:00:00 GMT

Current drink:: Lapsang Souchong tea

Here I am, writing my last post of this month.

I did, in fact, write in this blog for every day of November.

I probably won’t do this ever again!

As an ultimate conclusion for the idea of this month — and this blog — I won’t spend time wrapping everything up, making a neat list of everything I wrote (though I did update the main page, just experimenting with the style of all articles’ list). I don’t want to rush it, and I want to think more about what I actually did achieve or not.

One thing is certain: for some reason, I did succeed in this weird challenge. Maybe some of the things I shared were helpful for someone? I don’t know.

I guess, after this post, I could take a bit of a rest from these daily posts. Well, I’ll continue the “weekly” series, or perhaps I’ll take one week off — we’ll see!

Let me know what you think about this on Mastodon!

Personal Site Anniversary & History

Sat, 04 Nov 2023 00:00:00 GMT

Current music:: Daughter — Smother
Current drink:: Camomile tea

Introduction

Today is the 22nd anniversary of my first HTML page on the web: November 4th, 2001. Quite a long time going!

Initially, I wanted to post a longer history of my personal website(s), but looking at all the archives, that would be a much longer task, especially if I would like to show the screenshots and examples of what I had. For now, I’ve decided to write a shorter post.

Some Interesting Notes

In the beginning, it was a non-technical, childish site; I moved from one free hosting provider to another in 2001 and “redesigned” that site, I think, eight times? Not counting the not-finished designs.

In 2008, I purchased my first domain and started a technical blog, which evolved over time into what we can currently see at https://kizu.dev

Here is the beginning of the timeline for my personal site and my history with the web.

2001

Before I did start working on my site (I think on November 1st, so it was done rather quickly), I did touch HTML a little during the summer school in June the same year. There was a project for a photo gallery to burn on a CD, with the gallery being made with JS. I think I did mostly content management there, but that exposure was probably what led to me creating my website (as well as a website dedicated to Baldur’s Gate from a school friend).
My first site was on the framesets!

Here is the full HTML of the index.htm that I had:

<html><head><title>Kizmarh's Cave</title></head>
<frameset rows="74,*" border=0><frame src="menu.htm" name="menu" noresize>
<frame src="news.htm" name="document" noresize></frameset></html>

I won’t show you the content of the frames themselves, but there were tables. As in, using tables for the page layout. This would stay for the whole journey of my nontechnical site (I stopped working on it somewhere around 2006).
There was no CSS, not even inline styles.

2002

My first redesign and hosting change!
Framesets were gone, but tables did stay.

I used JS to implement images changing on hover via inline events:

onmouseover='document.qqq.src="mpic2.gif"' onmouseout='document.qqq.src="mpic.gif"'

Later the same year, I rewrote that site to be an SPA. Yes. Just one page, where I did change the content of the sections via JS. But hey, I did also write my first line of CSS: overflow:auto as an inline style!
That version of the site had “Best viewed in Internet Explorer”.
I think this version of the site did participate in a contest and won first place. I would not give that the first place today.

2003

I ditched SPA and kept things simple.
Every page had a different design, and I used image maps in a few places!
There was still no new CSS on the personal site itself.

However, looking through the archives of my files, I found some of my earlier experiments with CSS, from October 26. Here is how I wrote an external stylesheet, then. It’s pretty, isn’t it?

body {background:      #000000;
      font:            11pt/14pt Serif;
      color:           #FFFFFF}

a    {text-decoration: none;
      color:           #BBBBBB}

And here is, as you could tell, my first CSS experiment: masking an e-mail against spambots (with a more modern e-mail):
```
<p style="font:11pt/0pt Courier">
k&nbsp;z&nbsp;a&nbsp;h&nbsp;g&nbsp;a&nbsp;l&nbsp;c&nbsp;m<br>
&nbsp;i&nbsp;m&nbsp;r&nbsp;@&nbsp;m&nbsp;i&nbsp;.&nbsp;o&nbsp;
</p>
```
It still works!

k z a h g a l c m
i m r @ m i . o

A live example that _looks_ like normal text, but actually contains gibberish, like when trying to copy it, or access in any non-visual way.

I don’t think I ever used this in production — at some point I just started using the unmasked e-mails and did not notice a bump in the volume of spam.
Later in December, I did create my LiveJournal account.

2004

Two more redesigns of the personal site, still nothing new there.
I think I did work a bit on a website for my Mom’s job. I don’t remember any context, and there is a chance I first did it in 2001, but I don’t believe the file timestamps, as the site did already contain some CSS, which did not look like something I would write in 2001. But it looks more fitting for 2004.
I started doing my first LiveJournal themes, customizing them via S1 overrides. You could add custom HTML and CSS to your “social network profile” then!

2005

I redesigned my personal site once again, but it was still using tables.
However, I made the design of the pages fully responsive! Before that, I used fixed layouts, now it was a <table> with width=100% height=100%.
I started practicing a bit more with CSS, probably closer to the end of the year. One thing I did was rewrite one random web page’s layout from tables to floats and absolute positioning. It also had text-shadows made by using duplicate content and z-index.

2006

I did not update my personal site.
I was mostly doing the themes for LiveJournal.
December 26: I decided to read the CSS2.1 specs in full.

2007

January: I started working officially as a full-time front-end web developer.

2008

February: I published my first technical website on a personal domain.

To Be Continued!

Sadly, it seems that while for some older files the timestamps are intact, for anything starting from 2006 there are not a lot of correct ones. Maybe if I could find a proper archive somewhere that did retain everything…

In 2006, I was not in a good place closer to the end of the year, quitting the university and feeling quite worthless overall. I was lucky to finally land a job and start working as a developer full-time. Things have gotten much better since then for me. I’m happy where I am now (internally; externally… not so much).

Maybe one day I will revisit this post — or write a new one — and update this timeline, adding new notes and maybe adding examples of some of my earlier experiments or LiveJournal themes. Sharing funny snippets of code here and there.

If you have your own personal website, when did you start it? How did it evolve? I think it might be interesting to revisit your old code and your old self sometimes. I would be interested in reading more people’s stories about how they started their journey with the web platform.

Let me know what you think about this on Mastodon!

Posting on a Schedule

Tue, 21 Nov 2023 00:00:00 GMT

Current drink:: Peppermint tea

I did not have an opportunity to write something useful today. So, I’ll write something random? After all, this is my less polished blog, in which I, at least initially, wanted to start posting less technical things. Well, did not do well on the “less technical” part, but so far, I actually managed to post every day of November. Surprised myself with this!

Some observations:

The later it gets in the day, the harder it is to start writing, especially if that is something technical. Like, even while publishing less polished things, I still want them to have some quality. That means that if I have a certain thing I want to share, I still need to do a bit of research, write at least one example, and so on. All this takes time, and even if it won’t take much time in reality, when it is late, I guess I’m just afraid that what if it would take too long.
That brings me to the next thought: I won’t probably attempt something like that in the future. Posting every day is exhausting! I never liked deadlines, never liked habits and traditions. It might be fun to try something like NaBloPoMo once in a while. I can see how practicing this makes it easier to just go and write something not as polished, I just don’t think the compromises I do with myself to pursue it are worth it. I think I’m capable enough to learn the things that are useful to me, and throw away what does not work.
Having things prepared in advance would help! I could go and write N small posts about different things in one day, and then just post them every other day. For some reason, I feel that as cheating. After all, that would be an effort to do all of that in one go. And, so far, I think I managed to choose topics relatively spontaneously, maybe from a list of things that I already wanted to write about, but occasionally, there were topics that randomly came into existence just on a certain day.
I think the best thing would be for me to just try and at least start writing in the morning, have some rough draft. Then, during the day, finish it. I know it about myself that it is very for me to start things. Once I get going, things go smoothly, the problem is usually to begin. So, yes, that would be probably the main lesson: just start writing as early as possible, and with whatever nonsense, I want. This post did not exist until I started writing it, before — head empty. Just an anxiety that I did not yet write a post today.
I don’t like lists with an even number of items, apparently. Though, 10 would be a nice number? I’ll need to think about this. But maybe not in this post.

That’s it for today.

Except for one final thought outside the above list: I think writing every day did also help me to just do something every day as well, outside the blog. I have a few article drafts in progress, a few projects in progress (ooh, what are they? Hmm!), and I managed to do at least something for all of them. Which is nice.

Let me know what you think about this on Mastodon!

Interop Priority Game

Thu, 16 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

Introduction

Today, Brian Kardell posted a question in his blog, in an entry named “Let’s Play a Game”, let me quote it:

It’s Interop 24 planning time! Let’s play a game: Tell me what you prioritize, or don’t and why?

In the post, he asks to try to sort a list of the proposed focus and investigation areas to our liking, alongside some commentary. That’s what I’ll do!

There are more than 90 proposals! I can’t cover them all, and I lack expertize in many areas (sure, JPEG XL sounds cool! I have no idea about image compression, how it compares to other formats and so on, so I cannot weight on it; if you can — go ahead!).

I will order things from those I need right now, needed them yesterday, and probably needed them 10 years ago, to things that would be nice to have. Likewise, I think almost all the proposals make sense and are things I’d want to see — the “game” is not trying to tell what is good or not, but to prioritize, after all. If I don’t mention something, that means that I don’t have enough to say about it, at least at the current moment.

Top Ten Interop Proposals, as Sorted by Me

1. Scroll-driven Animations

I am biased: I wrote multiple articles about them, describing the weirder use cases which become possible when using scroll-driven animations.

As I mentioned in Igalia Chats, when I first saw the scroll-driven animation specs, I did not think I would write all these articles. I did not understand at the time how powerful it is to get access to the elements’ positions and dimensions in CSS in the way scroll-driven animations allows us.

But here we are — with them unlocking so many effects and use cases! And now that they’re in Chrome Stable, let’s prioritize shipping them everywhere.

And — in an interoperable way.

There is one fear I have — with so many techniques I (and others) come up with, what are the chances they would work even when other browsers would implement scroll-driven animations? There are so many moving pieces: @property, interactions of custom CSS properties with animations, and more.

But, without shipping the scroll-driven animations in the first place, we couldn’t even come closer to all these techniques, and with them in place, arguing towards interop for @property and custom CSS properties would be easier.

2. CSS style container queries (custom properties)

Ugh, I still need to write a proper article about style container queries. In my first initial experiments around their workarounds I stumbled upon the “cyclic toggles” technique, and during “CSS Day 2023” conference many speakers did mention, and did provide very real use cases for style container queries. Having them available everywhere would unlock so much.

Maybe one reason why I’m not writing this article is that it would expose so many things I’ll need right now, that the style container queries absence would hurt even more.

3. Unit division and multiplication for mixed units of the same type within `calc()`

This is such a powerful thing! Stripping a unit from length values in CSS calculations is something I wanted for ages. This would unlock countless use cases.

Today, we have only wild hacks like the tan(atan2()) hack by Jane Ori, or have to define our values unitless. But we really require this as a native feature, available in all browsers at the same time. It might be complicated to work around interop issues in calculations, as the current atan2() issues show.

4. `attr()` support extended capabilities

An ability to get an HTML attribute, and use it not as a string, but as any other CSS value is something that would also unlock so many use cases!

Yes, it can be worked around by using custom properties, but they are much more cumbersome, especially if we’d want to just reuse the existing attributes on regular HTML tags.

And irregular as well: with custom elements, we can name our attributes as anything. Imagine if we could use them directly in CSS, as proper values? Instead of <my-component style="--foo: 10; --bar: 5"> we could do just <my-component foo="10" bar="5">. In addition to just added convenience, this would remove the potential CSS variables clashes, where right now we have to namespace them, but with attributes on custom elements we won’t have this issue.

5. CSS `element()` function

I only recently started using Firefox, so I did not yet experiment with element(), but it was for sure on my radar for a while. An ability to reuse the visuals of some element on the page? Huh? This can be so powerful! And it is almost impossible to work around otherwise (except for some very specific cases where we could use -webkit-box-reflect).

Ok, I need to confess: this element of the list is that high only because it’s related to anchor positioning. Moving the Popover API forward would mean more use cases and need for anchor positioning, which is in a much earlier stage to be present in the Interop 2024, but I want to do everything possible to move towards it.

And the Popover API is cool by itself, of course. But it would be so much cooler with anchor positioning! I just can’t stop mentioning anchor positioning. Sorry. By the way, my next article on my main site would be about them, for once, and not about scroll-driven animations! Stay tuned! That article won’t even be the last time I’ll write about anchor positioning this year, can you imagine?

7. CSS Multi-Column Layout block element breaking

I will take any improvements to multi-column layout, to be honest. One dream I have is to have Overflow In The Block Dimension For Multicol. Please? Of course, handling the element breaking is something required for mutlicol to be viable as well. Improving interop for them, giving more developer hands for multicol layout, fragmentation, all of that, would be so good!

8. Relative Color Syntax

We now have color-mix() which can cover some relative color syntax use cases (CodePen by Lea Verou), but from all of them.

Functions like fade(), darken(), lighten() and so on in preprocessors are sometimes the last reason to continue using them. Being able to dynamically adjust colors, by modifying some components, and not just replacing them, would be invaluable, especially for design systems.

9. `text-box-trim`

And, text-box-edge and other related properties, of course. I’ll take anything that allows us to improve typography and aligning things around text. The cap unit is almost here, and while it will cover some use-cases (like vertical alignment of icons near text), text-box-trim would allow for so much more precise control over how things look in relation to text.

10. Declarative Shadow DOM

I did briefly write recently about one use case for the Declarative Shadow DOM. As with many other items in this list, I look at this issue as a part of something bigger. In this case, as a path towards Declarative Custom Elements which would be so nice to have! But, yes, I’ll take Declarative Shadow DOM as well, especially given I now have at least one use case for it, with the “fully transparent” elements.

Participation Award

I could continue writing and writing, scoring and sorting the proposals, but hey, I’m doing this in my less polished blog, so I need to stop at some point! Some other notable mentions that could get into a top 15, if I’d get to write more about them:

And so many more other things. So many things I did not even mention, only from the CSS proposals, and there were even more…

Final Words

I really hope at least some of the things I did mention will get into the Interop 2024. I encourage everyone to go, read the proposals, vote for what you’ll find interesting, and provide your use cases in the issues if you have some.

Very often browser vendors do not know if developers really want the features, or if existing workarounds are enough, if the use cases were covered by something else, and so on.

I believe that by writing about what you care about, you move things forward, give a signal that that thing you wrote about is something you still need.

Let me know what you think about this on Mastodon!

Scope Selector Nuance

Mon, 27 Nov 2023 00:00:00 GMT

Current drink:: Coffee

In yesterday’s “weekly” I shared the new MDN docs page for @scope — a new CSS feature currently only available in Chromium-based browsers.

Looking at it made me remember one issue that I had with the @scope, which was actually intended. I imagine this might be something many people would stumble upon, so here I am, sharing it.

The issue might appear if you’d try to use a selector that would have a mention of a wrapper that exists outside the scope, like this:

Component is not available in RSS, visit the the site to access it.

@scope (.my-scope) {
	.inner {
		background: var(--PINK);
	}
	.outer .inner {
		background: var(--GREEN);
	}
}

<div class="outer">
	<div class="my-scope">
		<div class="inner">Hello?</div>
	</div>
</div>

The .inner element now has the pink background — not green. It might be easy to think that it would match if you’d think of scope as of something similar to a media or container query: we really care only about the target element, and the .inner is both inside our scope, and inside the .outer, right?

But the issue is: scopes behave closer to native CSS nesting: anything inside would be as if it were nested inside an implicit :scope element!

Let me quote the corresponding section from the abovementioned MDN docs:

In the context of a @scope block, the :scope pseudo-class represents the scope root — it provides an easy way to apply styles to the scope root itself, from inside the scope.

In fact, :scope is implicitly prepended to all scoped style rules. If you want, you can explicitly prepend :scope or prepend the nesting selector (&) to get the same effect if you find these representations easier to understand.

So what we get in the end is :scope .outer .inner — and, of course, we don’t have the .outer inside our scope! But we can easily confirm this by modifying HTML:

Component is not available in RSS, visit the the site to access it.

<div class="my-scope">
	<div class="outer">
		<div class="inner">Hello!</div>
	</div>
</div>

Now, the .inner element has the green background.

How can we fix this? There are, actually, multiple ways to do so, all using different ways we can create selectors:

Component is not available in RSS, visit the the site to access it.

<div class="outer">
	<div class="my-scope">
		<div class="inner inner1">With an ampersand</div>
		<div class="inner inner2">With a :scope</div>
		<div class="inner inner3">Using nesting</div>
		<div class="inner inner4">Using :is()</div>
	</div>
</div>

@scope (.my-scope) {
	.outer & .inner1,
	.outer :scope .inner2 {
		background: var(--GREEN);
	}
	.inner3 {
		.outer & {
			background: var(--GREEN);
		}
	}
	/* Not entirely correct */
	.inner4:is(.outer *) {
		background: var(--GREEN);
	}
}

The “proper” way to fix this is to just explicitly mention the scope — either by & or :scope. This way there won’t be anything implicit added, similar to how & works in native CSS nesting!

The third example is something that works because the :scope would be added to the topmost selector, so when the native CSS nesting would expand, it would become .outer :scope .inner3 essentially.

The fourth case is interesting, and not entirely a substitute to others. While it works, it is actually wider than you might think: it would also include the case when the .outer is inside the .my-scope or even if both classes are present on the same element:

Component is not available in RSS, visit the the site to access it.

<div class="outer">
	<div class="my-scope">
		<div class="inner inner4">Outside</div>
	</div>
</div>
<div class="my-scope">
	<div class="outer">
		<div class="inner inner4">Inside</div>
	</div>
</div>
<div class="my-scope outer">
	<div class="inner inner4">Mixed</div>
</div>

This is because of how what is inside the :is() does not really care about any nesting that the element already has — it just checks if the target element is also nested inside the .outer element.

While this is not a one-to-one to what we intended, knowing this behavior can be useful in other cases.

We cannot use CSS scopes right now, only play with them in Chromium-based browsers, but when they would become more widely available, hopefully knowing this nuance will help you.

Let me know what you think about this on Mastodon!

Shadow DOM on Regular Elements

Thu, 02 Nov 2023 00:00:00 GMT

Current drink:: Yunnan tea

Introduction

For some reason, I had this misconception that Shadow DOM could not be used with regular elements, I only ever tried it with the custom ones. But — thanks to Doug Parker, who did point it out to me on Mastodon, — now I know that we can actually do that.

I knew that custom elements (or Web Components) without Shadow DOM were a thing (see also a related article “Blinded By the Light DOM” by Eric Meyer from yesterday), but it never occurred to me that in the same way we could attach a Shadow DOM to a web component, we could do it just for a regular element. Sometimes it is very easy to overlook simple things!

Curiously, if only I had read the MDN docs about “Using shadow DOM” (the link Doug gave me), then I would’ve learned that.

Declarative Shadow DOM

Even more, in another Mastodon post, Doug shows how the Declarative Shadow DOM can also be used with regular elements. If only Firefox would support it! (It actually will, rather soon — they did state that the implementation will start soon! Follow this bugzilla ticket if you’d like to track this).

The Context

Where would I want to use Shadow DOM on a regular element? The case that resulted in this post was me wishing for a particular thing in HTML. Let me quote my own mastodon post:

What if we had an #HTML attribute that would make an element “invisible” for #CSS selectors?

Like display: contents, but for DOM.

Like,
<div class="foo">
	<div i-am-not-here>
		<div class="bar">
		</div>
	</div>
</div>
And then .foo > .bar would actually select the inner .bar?

I can see something like this being very useful for #WebComponents, among other things, as right now it is not possible to use them as generic wrappers without impact.

Playing with Shadow DOM and custom elements, I found two ways to achieve what I wanted.

Here are both CodePens:

The one using a custom element is a bit weird. But it works! But I probably won’t use it in production, as it looks very fragile, requires JavaScript, and is hard to make a fallback from.

The second one, with the Declarative Shadow DOM, is much nicer. It is still a bit verbose — I think I would still prefer some way of doing this kind of “transparent” element just via an attribute — but it is much less weird. If only we had Firefox support… Maybe I’ll look into using a ponyfill for this?

But what I did like is that the fallback is very gracious: the only difference outside the Shadow DOM applying is that the template stays in the DOM, impacting CSS selectors like :nth-child() etc. But any other selectors like the .foo > .bar from the CodePen would continue working.

Why Do I Want This

In short: to be able to use Web Components as something like “Higher-Order Components”, where they could provide their functionality (JS or via custom CSS properties that would get inherited into the light DOM, as seen in the example) to the nested elements, but without any impact on layout (when using display: contents) or selectors (the thing that I wanted it to be originally).

Here is another CodePen with a bit more expanded use case, though I understand that it might still not be “practical”.

But hey, this is just a quick article in which I wanted to share my observation — this is a thing that I want to start doing more of. Maybe when I play with this further, I will write another post with better examples!

Or, maybe what I shared today would inspire you to do something interesting. Let me know!

By the Way

So far, I have posted for every day in November! “Is this a ‘NaBloPoMo’?” — He asks, pointing at a butterfly. We will see! I doubt I could keep it up through the whole month, but maybe? I just need to choose a tiny topic and not be a perfectionist about polishing it completely. “Just”. See you in the next post, be it tomorrow or later!

Let me know what you think about this on Mastodon!

Slightly Updated Blog Design

Sun, 05 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

Sorry again for not posting the weekly links — I’m not feeling myself well, so I decided to write a shorter post today.

I did update this blog’s design slightly!

If you’re reading this post via RSS — you can visit the site itself.

(Note to self: It would be cool to have some way to add content that is visible only in RSS.)

The update is very simple this time (though there have been more updates since the last time I wrote about my blog’s CSS, in the first post here/): mostly colors and a few spacing ones.

I’m lazy enough to provide the before/after — but before what you can find now, I did not really have any colors, relying on the system’s default white&black colors for the text and background (though, customizing the link colors, as in Safari, in the dark mode, but with the color-scheme: light dark; the links did not change color, resulting in a bad contrast).

(Maybe I will add the before/after at a later point.)

Let me know if you spot any issues with the new design; it was very quick to implement, and I’m sure I forgot to check something.

I’m not sure when I could gather the next weekly links — probably when I would feel myself better. For the time being, I will probably continue posting these “simple” posts.

Let me know what you think about this on Mastodon!

Observation: Snappy Scroll-Start

Fri, 17 Nov 2023 00:00:00 GMT

Current music:: Robert Dallas Gray — Quartal Reels
Current drink:: Lapsang Souchong tea

Context

Two days ago, I published my previous observation: “Range Input’s Thumb and Emerging CSS”.

At the end of this post, I did write:

In the Mastodon thread about this, Bramus did also share his solution for this, also using scroll-driven animations, but in a different way. I did share another observation later, but I’ll save it for a future blog post.

Here is this blog post!

The Problem

I’ll quote Bramus, from the end of his Mastodon message that I mentioned above:

(My demo begs for scroll-start, a new property to set a non-zero starting scroll position BTW)

Two quick related links:

Here is a spec for scroll-start.
And here is the original proposal for scroll-start by Adam Argyle.

As usual, when I see something that sounds good, I always think about how we can work around the absence of this feature now.

I remember, I did already think about this at some point, but did not really try, so no old CodePen to show this time. Given I was already in the mood of sharing stuff, I shared a modified CodePen where I demonstrated my idea for a workaround.

The `scroll-start` Workaround

My thought process was: ok, we need to have a scroll to be at a certain position. Do we have something that controls the scroll position?

Scroll Snap. (I recommend Adam’s talk about it — “Oh Snap!”)

The problem: it would always apply, interfering with the scrolling.

Potential solution: one-time animation or a @starting-style? Trying the latter in Chrome, it didn’t work. Trying the former — it did! I’ve tested only in Chrome, and for the purpose of this exact demo, which already did work only in it due to the scroll-driven animations, it was enough.

Now, however, I’d want to see if it is possible to use this workaround in a cross-browser way.

Ooops. It did not work in Firefox and Safari. Why? Scroll Snap support is actually decent. Debugging time!

In Firefox, the issue was that in order to scroll-snap to work, I had to add the dimensions to an element with it. It had to be at least 1×1 pixel.
In Safari, the issue is less pleasant: for some reason, the scroll-snap does not want to work when applied from inside an animation.

I’ve tried many things! The solution I found in the end was… to add container queries?

Here is the final CodePen

And here is most of the code for this CodePen:

<div class="scroller" style="--scroll-start: 10em;">
	<div class="content">
		<div class="scroll-start"></div>
	</div>
</div>

.scroller {
	width: 10em;
	height: 10em;
	overflow: auto;
	outline: 1px solid;

	scroll-snap-type: y mandatory;
}

.scroll-start {
	position: absolute;
	width: 1px;
	top: var(--scroll-start);
	container-type: size;
	visibility: hidden;
	animation: --snap 0.01s both;
}

.scroll-start::before {
	content: "";
	height: 1px;
	display: block;
}

@container (width: 1px) {
	.scroll-start::before {
		scroll-snap-align: start;
	}
}

@keyframes --snap {
	to { width: 0 }
}

The trick was to apply the scroll-snap-align not from an animation directly, but conditionally through a container query, which changes based on an animation that runs once.

Our helper element starts with 1px width, and at this point the scroll-snap-align applies.

The animation changes the width of the helper to 0px, and the container query no longer matches, removing the scroll-snap-align.

That’s it! We get our scroll-start position, and after it applies, we can freely scroll the container.

Follow-ups

If this was an article on my main site, I would feel obliged to go and look up both the Firefox and Safari issues, check what the specs did mean, are there web platform tests, are there open bugs… Posting this as an observation here is liberating: I could still do it later (unless someone would get to do it first — you’re welcome, by the way), but for now, I could just share this, not postponing it until I’ll sort everything.

Let me know what you think about this on Mastodon!

Space Variable Placeholders

Sat, 25 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

I already posted this week once about space toggles, but today I did use a variation of the technique, where it is not strictly space toggles, but something like space placeholders. I’m not sure if I have previously seen any specific articles about this, so I decided to write about it (if you know of other articles about this — please let me know, I’ll mention them here).

The idea is: sometimes we want to make some properties extensible, which can be very useful for properties that do not have longhands like box- and text-shadow, or for properties which can accept an unlimited number of values like the same text- and box-shadow, but also content, background-image, filter, transform (which recently got an ability to specify values separately, but it might still be useful to do this with the original property) and so on.

CSS variables can be very helpful for coming up with your API, which allows controlling these properties in some very precise ways.

Here is one way I like to do this:

Component is not available in RSS, visit the the site to access it.

<p style="--em-shadow-top: var(--shadow-border),;">
	<em>First pill</em>
	<em style="
		--em-shadow-mid: var(--shadow-basic),;
	">Second pill</em>
	<em style="
		--em-shadow-top: initial;
		--em-shadow-low: var(--shadow-glow),;
	">Third pill</em>
	<em style="
		--em-shadow-mid: var(--shadow-basic),;
		--em-shadow-low: var(--shadow-glow),;
	">Fourth pill</em>
</p>

.example {
	--shadow-border: 0 0 0 1px hotpink;
	--shadow-basic: 2px 5px 4px -2px blue;
	--shadow-glow: 0px 0px 2px 5px lightgreen;
}

.example em {
	display: inline-block;
	border-radius: 9em;
	background: pink;
	color: #000;
	padding-inline: 0.5lh;
	box-shadow:
		var(--em-shadow-top,)
		var(--em-shadow-mid,)
		var(--em-shadow-low,)
		0 0;
}

There are a few interesting things going on in there which might look weird at the first glance, but allow me to explain!

In CSS, we can see the weird comma at the end of the variable name: var(--em-shadow-top,) — this is a valid way to define an empty fallback, or a space, often used in the space toggles.

I wrote a bit more extensively about this part in my article on cyclic toggles, but in short: whenever the variable in question has its initial value (or — it is not defined, or it is invalid at computed-value time), it would result in just an empty space, which is a valid thing to have in any part of any value in CSS. This is a very compact way of saying, “we can put something here, but it is also ok to just skip it”. If we don’t use the comma, the “initial” value of the variable would make the whole property invalid, so we have to have some fallback here.
The box-shadow definition ends with 0 0. If you’d look at the HTML we have, you might already guess why: we define our variables like this: --em-shadow-top: var(--shadow-border),; — note the comma at the end. Because CSS does not allow trailing commas in lists, and we don’t know in advance which variables we could define and in which order, we want to make sure any combination of them would work.

The easiest way to achieve this is by adding the comma either to our token definition (like to the --shadow-border), or to the places where we use the tokens (as in the example). With the 0 0 at the end of our box-shadow, we can be sure that if we’d add a comma for any of the values, things would still render properly. And the 0 0 is just the smallest valid shadow that does not really do anything. Other properties could have other ways of handling this, but often they would not even require this comma stuff, like for the content or transform values which are just separated by spaces.

The rest should be relatively obvious: we’re using tokens so we won’t need to define their values all the time, we can define the “default” values on the ancestors (on the <p> in our case), and then override them back to nothing (see --em-shadow-top: initial;).

This is also just one of the ways something like this can be handled, and there are various other cases where we could use CSS variables in this manner. Custom properties are powerful!

Let me know what you think about this on Mastodon!

Space Toggles for Scoping

Wed, 22 Nov 2023 00:00:00 GMT

Current drink:: Peppermint tea

Today I did encounter a bug, for which I would really want to use CSS Scopes, or Style Container Queries. But they’re not yet available in any cross-browser way. But the bug won’t wait!

The Issue

This is a rather common issue which can resurface for very complex components. Prerequisites:

A wrapper, on which we handle the modifications via toggling classes.
Some descendant element, which depends on these styles, with an unknown deepness of nesting inside our wrapper.
Ability to nest this component inside itself.

Here is a simplified example:

Component is not available in RSS, visit the the site to access it.

.section {
	max-width: max-content;
	box-sizing: border-box;
	padding: 16px;
	border: 2px solid;
}

.section-header {
	margin: 0 0 8px;
}

.section.isPretty {
	border-radius: 2em;
}

.example1 .section.isPretty .section-header {
	border: 4px double hotpink;
	border-radius: 9em;
	padding-inline: 16px;
}

<div class="section isPretty">
	<h2 class="section-header">Section Header</h2>
	<div class="section-content">
		<div class="section">
			<h3 class="section-header">Subsection Header</h2>
			<div class="section-content">
				Some content
			</div>
		</div>
	</div>
</div>

The intent of the styles above was for the .section-header to have the modified styles only when it is inside the .isPretty section. But, because the selector is selecting any descendant header inside, it also matches the header inside our nested section.

You might say: oh, but just use the child combinator! Yes, in this simplified example, .section.isPretty > .section-header would immediately resolve the issue.

However, remember when I mentioned “very complex components” and “with an unknown deepness of nesting”?

The child combinator is handy when we know the structure of our components. Ideally, we should. But in some cases, that might be complicated! Imagine we’d have a table inside our component, and we’d want to nest some element inside one of the cells. We would not want to write something like .section > table > tbody > tr > td > .our-element. Especially, if the structure could change, and the element could be present on different nesting levels, so we couldn’t even do something like .section > * > * > * > * > .out-element, as this won’t guarantee that we will select the proper element, or if we’d over-reach into a nested section this way.

Potentially, we could handle this via HTML: duplicate the modifier on every element that needs it. So, we’d have a class="section-header isPretty". This means, we will have too much logic for handling HTML. This will unnecessarily overcomplicate things.

Scopes

CSS Scopes could help us with this!

Component is not available in RSS, visit the the site to access it.

@scope (.example2 .section.isPretty) to (.section-content) {
	.section-header {
		border: 4px double hotpink;
		border-radius: 9em;
		padding-inline: 16px;
	}
}

<div class="section isPretty">
	<h2 class="section-header">Section Header</h2>
	<div class="section-content">
		<div class="section">
			<h3 class="section-header">Subsection Header</h2>
			<div class="section-content">
				Some content
			</div>
		</div>
	</div>
</div>

(HTML for this and the following examples is the same)

If you’ll look at the above example in Chrome or most other Chromium-based browsers, you’ll see that it actually works! What we did is utilize the donut scoping: defining a scope boundary, beyond which the styles won’t be applied.

We used the .section-content, but there are multiple ways we could’ve solved this, like stopping the scope on the next .scope element, or maybe not even using the donut scoping, and relying on the “closest scope” mechanism, defining two scoped styles: for non-modified styles, and modified. I did not play with the scopes enough to properly research which method would be the best, so for now, I’ll omit them.

Style Container Queries

Style Queries could also help us!

Component is not available in RSS, visit the the site to access it.

.example3 .section {
	--is-pretty: initial;
}

.example3 .section.isPretty {
	--is-pretty: 1;
}

@container style(--is-pretty) {
	.section-header {
		border: 4px double hotpink;
		border-radius: 9em;
		padding-inline: 16px;
	}
}

<div class="section isPretty">
	<h2 class="section-header">Section Header</h2>
	<div class="section-content">
		<div class="section">
			<h3 class="section-header">Subsection Header</h2>
			<div class="section-content">
				Some content
			</div>
		</div>
	</div>
</div>

Again, if you’ll look at this in Chrome or most other Chromium-based browsers, you’ll see that this works. Because of the way CSS variables are inherited, we can use this to scope things in a way similar to the native CSS scopes!

One thing I think I need to mention right away: even though those two methods look similar, we need both. In many other aspects, scopes and style container queries are very different, and this is not a place where we should choose only one over another.

But the issue with both methods — so far, they were only implemented in Chromium… Can we do something with what we have in every browser today?

Space Toggles

We can! I did come across this method when playing with the style query alternatives when going back from CSS Day 2023. The actual method I discovered is “Cyclic Dependency Space Toggles”, and is a variation on regular space toggles (about the history of which you can also read in my article).

For this post, I’ll demonstrate regular space toggles — after all, cyclic toggles are just a variation of them when we want to have more than just a binary state, and it could be applied for this as well.

Component is not available in RSS, visit the the site to access it.

.example4 .section {
	--is-pretty: ;
}

.example4 .section.isPretty {
	--is-pretty: initial;
}

.example4 .section-header {
	border: var(--is-pretty, 4px double hotpink);
	border-radius: var(--is-pretty, 9em);
	padding-inline: var(--is-pretty, 16px);
}

<div class="section isPretty">
	<h2 class="section-header">Section Header</h2>
	<div class="section-content">
		<div class="section">
			<h3 class="section-header">Subsection Header</h2>
			<div class="section-content">
				Some content
			</div>
		</div>
	</div>
</div>

Yay, it now works everywhere! Of course, the usage is much more cumbersome than with scopes or style queries. And right now, when the --is-pretty is not defined, the corresponding properties would revert to their initial values. If we’d want to set some alternative values, we’d have to define an additional variable:

Component is not available in RSS, visit the the site to access it.

.example5 .section {
	--is-pretty: ;
	--is-not-pretty: initial;
}

.example5 .section.isPretty {
	--is-pretty: initial;
	--is-not-pretty: ;
}

.example5 .section-header {
	border:
		var(--is-pretty, 4px double hotpink)
		var(--is-not-pretty, 2px solid);
	border-radius: var(--is-pretty, 9em);
	padding-inline:
		var(--is-pretty, 16px)
		var(--is-not-pretty, 4px);
}

<div class="section isPretty">
	<h2 class="section-header">Section Header</h2>
	<div class="section-content">
		<div class="section">
			<h3 class="section-header">Subsection Header</h2>
			<div class="section-content">
				Some content
			</div>
		</div>
	</div>
</div>

This method did allow me to untangle some overrides which were really difficult to work around differently without introducing some complex dynamic HTML output logic. All because of how custom properties work in CSS!

Conclusion

If you did not yet dig into how to use space toggles — I will highly recommend it! They can be a bit tricky to set up, but we’re using them for around a year in production, and so far, no complaints. And, as this post shows, they can be used to solve some complex cases, a proper solution for which we will only get with the more advanced solutions like scopes or style container queries.

But oh how I would prefer to use a more proper solution, and not a hack!

Let me know what you think about this on Mastodon!

Unlayered Styles Issue

Tue, 07 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

I did write a lengthy comment in a surprisingly (for me) closed issue about allowing authors (and users) to explicitly place unlayered styles in the cascade layer order. I won’t reproduce the comment here, so I invite everyone to read it on GitHub and participate in the discussion, provide your use cases, and so on.

(As a sidenote, I think I’ll continue sharing my bigger comments/issues in CSSWG as separate posts here, whenever I feel that they’re something that is more important/invites a discussion)

(Maybe I’ll need to add the ability to mark a post as an “external link/bookmark”? I’ll need to think about this.)

Let me know what you think about this on Mastodon!

My VS Code Monaspace Font Setup

Tue, 28 Nov 2023 00:00:00 GMT

Current drink:: Darjeeling tea

In the last “weekly” I did share a link to “The Monaspace type system”. For a few weeks, I was trying one of its fonts in VS Code. There were a few things that did not go very smoothly, so I have decided to share them in this post.

My Configuration

Below is what I have configured for the font in the editor and its integrated terminal.

{
	"editor.fontFamily":
		"Monaspace Neon Var, Fira Code, Monaco, monospace",
	"editor.fontSize": 16,
	"editor.fontVariations": "'wght' 350",
	"editor.fontLigatures":
		"'calt', 'liga', 'ss03', 'ss04', 'ss06'",
	"editor.tokenColorCustomizations": {
		"textMateRules": [
			{
				"scope": "comment",
				"settings": { "fontStyle": "italic" }
			},
			{
				"scope": "storage,entity,variable",
				"settings": { "fontStyle": "" }
			}
		]
	},
	"terminal.integrated.fontFamily":
		"Monaspace Neon Var, Fira Code, Monaco, monospace",
	"terminal.integrated.fontSize": 14,
	"terminal.integrated.fontWeight": 500,
	"terminal.integrated.fontWeightBold": 800
}

As you can see, I’m using the “Neon” font, and the variable font version, and also using the “Fira Code” font by Niki Tonsky as the fallback font — this is helpful for when the terminal has the special characters set up, like the git branch symbol and so on.

Font-Weight Weirdness

You might notice that for the editor font, I’m setting the font-weight via "editor.fontVariations": "'wght' 350", and not via fontWeight. For me, the fontWeight did result in the incorrect results for the “regular” font-weight. There is a similar issue on GitHub similar to mine.

But using the fontVariations and specifying the variable font’s value for the wght axis did work correctly for me. It seems that maybe the built-in instances for the font-weight were not set up properly? When uploading the font to “Wakamai Fondue” (a web service for analyzing fonts by Roel Nieskens), it does not even show if the font contains any built-in mappings for the regular font-weights. But I’m not an expert, and perhaps there is something else at play.

Thankfully, at least for the editor, it is possible to set up things, the integrated terminal, sadly, does not provide an ability to override the fontVariations.

As a sidenote, there is also a small issue with the minimal font width — it is a bit too wide. Would’ve been nice if it was possible to make the font narrower.

Ligatures

At first, I did try using more than three stylistic sets I ended up using; however, some ligatures were not set up properly, breaking the caret navigation and selection (“merging” the symbols into one). Thankfully, many other ligatures seem to work fine, so I found those from 'ss03', 'ss04', 'ss06' work well for me.

Basically, I did choose to keep only those ligatures that did not change how the characters displayed very drastically. Otherwise, it might be very challenging to navigate from the keyboard through the symbols when you can’t tell on which symbol you’re currently on, for example when the !== is converted into a wide ≠.

But those ligatures where things are just looking slightly different — I, for the most part, don’t mind.

Customizing Tokens

Sadly, while the Monaspace’s promo site did show how cool it would be if we could set up entirely different fonts for different semantic entities on the page, this is not supported in VS Code (apart from using some extensions that allow for more customization). The only thing we can control via editor.tokenColorCustomizations is basically only if something is italic or no (and some other very minor things).

I did, at least, set up to use italic for all code comments, except for the code bits inside JSDoc — the storage, entity, variable tokens.

But I really wish VS Code did provide more ways to customize the fonts, including all the font features for the editor and its specific highlighted tokens, and for the integrated terminal.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 3: IndieWebCamp Edition

Wed, 01 Nov 2023 00:00:00 GMT

Current drink:: Some plain water in the trains; Yunnan at home
Current location:: Started: Nuremberg → Paris; then finished at Home

Introduction

As I shared in my previous post about the things I did during IndieWebCamp, I did not have enough time to compile a list of bookmarks for the last week. I have some, but I was mostly paying attention to what was happening at the conference and the IndieWeb event. I’ll include these links in the next weekly bookmarks.

However, IndieWebCamp, especially the sessions during the first day, was full of information, which I tried to distill into a list of links that I found interesting.

Building Block Icons

I participated in a session about having an imagery for the indie web “building blocks”, initiated by Paul Robert Lloyd, in which we discussed if there should be a cohesive design language for various IndieWeb thingies.

“A cohesive and unified identity for IndieWeb protocols” by Paul — the original post that did initiate the discussion, where he proposes a starting point for a cohesive design language for the IndieWeb.
- “The poster’s guide to the internet of the future” by David Pierce — an article mentioned in the post.
- He also links to a lot of pages for various IndieWeb and related technologies, visit his post to get them! (Seriously, there are many interesting links in his post, I am myself planning to read a lot of them later.) I think both this post and the Verge article could be considered a good introduction to the IndieWeb.
“Types of Posts” — a section of the “posts” page of the IndieWeb wiki that tries to gather and categorize different types of content that might be present on personal websites.
“Building block icons” — a wiki page created by Paul after the session.
- “Category:Branding” — a wiki category page with some other interesting linked pages.

Overall, I really like the Paul’s proposal, especially how the icons for specific microformats look.

Link Rot

I participated in a session about the “link rot”, initiated by Jeremy Keith, in which we did discuss various ways to check, fix or work around the broken links that could exist in various personal blog archives.

I’m gathering the links to things mentioned in the session and outside of it into one list, providing some of my commentary:

“No more 404” by Remy Sharp — the original article that did initiate the discussion.
“The Wayback Machine” by Internet Archive — the best way to get the content of a link that did disappear.
“Stop the Linkrot” by Jeremy Cherfas — a short post about the session we had, and how Jeremy did fix problems he had with inbound links via .htaccess.
- “Broken Link Checker” — mentioned by Jeremy. I found six broken links with it (it reported 7, but one of them was one I already fixed previously, so it seems to cache these in some way).
“Link-rot and Schrödinger’s URL” by Sebastian Greger — a post about the session we had, where he looks at how he could approach this issue on his site (he uses Kirby CMS and PHP).
- “LinkChecker” — a free GPL website validator (requires Python 3.8 or later) mentioned by Sebastian in his post.
- He also mentions a bunch of other links to various APIs he is using, if you’re interested, visit his post!
Micro.blog — a blogging service that, as a part of its premium plan, includes achieving the bookmarks. A YouTube video about this feature.
“410 Gone - Thoughts on Mark ‘diveintomark’ Pilgrim’s and _why’s infosuicides” by Scott Hanselman — a post about the 410 gone HTTP status that we briefly discussed during the session.
“0 KB Social Media Embeds” by Chris Coyier — a short post about how it is a viable way to just “embed” any short-form posts as blockquotes, and thus both have a snapshot of the content in time and no chance it would disappear. We did mention this type of embed during the session, but, of course, it is only viable for anything short enough to not be annoying.

Overall, this is a very interesting and multi-faceted topic. I’ve started thinking about how I would want to implement something that helps with this on my site, and also about whether this is something that could be facilitated by the web browsers and/or browser extensions. It should be easy enough to do the “did we land on 404? Let’s look in the Internet Archive” as a feature, though this won’t work for the “zombies”.

How to stop rewriting your site and write more

I participated in a session about actually writing in your blogs, initiated by Sara Jakša, where we did discuss what is stopping us from writing in our blogs, be it perfectionism or something else.

“After session Additional Notes” by Sara — after the session, she did write down the summary and some ideas of what we were talking during the session, sharing some nice links as well.
“Extended mind thesis” shared in these notes is something I’ve already been doing for years, though not publicly: putting every idea into some notes, removing them from my head, and “freeing” some space for new ideas.
“digital garden” article stub over at IndieWeb wiki — a concept that I encounter more and more, though maybe not the one I’ll use for publishing my thoughts publicly. I’m using Obsidian for my notes now, and it is less like a garden and more like overgrown ruins. However, I think this might be a neat concept for gathering information about some topic, learning and so on.
There were some other thoughts and links in these additional notes; I highly recommend reading them, especially if you struggle with finding what to write in your blog or with the writing process in general.

If I took one thing from this session, it was that I needed to worry less about how things would be received and try to fight my perfectionism, at least in some ways.

Other Sessions

I was also present at two other sessions: “Accessible web” by Calum Ryan and “POSSE How To & Best Practices + Fediverse” by Tantek Çelik, but I don’t think I want to add any links here, as I’m less familiar with these particular topics, and would need to read much more on them in order to share something reasonable.

The “Accessible web” session was more of a free-form discussion without any specific topic; the “POSSE” is a concept that I’m not entirely sold on yet, though I really liked how “Bridgy Fed” sounds like — a way to easily connect Mastodon with your IndieWeb-powered website.

I’ll keep an eye on the various IndieWeb concepts in the future, so it is likely my other weekly bookmarks will get more links from this area as well.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 4: CSS Edition

Sun, 12 Nov 2023 00:00:00 GMT

Current music:: Neavh — Knothole
Current drink:: Yunnan

On one hand, I did miss two weeks of this “weekly” series. On the other, I did post every day from the start of the month.

With the backlog through all these past weeks (last “weekly” had only IndieWeb bookmarks, so the last time I actually posted regular ones was on October 22), I have maybe too much on my plate.

So, this time, I’m only posting links related to CSS, as well as a quick list of everything I did write in this blog since the last weekly. That means that the next weekly would have some more non-CSS links to share!

CSS Techniques, Articles, and News

“Solved by CSS Scroll-Driven Animations: Style an element based on the active Scroll Direction and Scroll Speed” by Bramus — a very wild hack around scroll-driven animations, utilizing the inheritance of values set by animations from a parent to children, with transitions, allowing to detect the velocity and direction of the scrolling.
“Control Pixel Art Sprites With CSS Scroll-Driven Animations” by James Basso — a nice application of the above technique, used to adjust the direction of the sprites based on the scroll direction.
“Why You Should Use px Units for margin, padding, & Other Spacing Techniques” by Ashlee M Boyer — an article comparing the relative and absolute units when applied to spacing. I, personally, was convinced to start doing this, but, as a rule of thumb, only for the inline direction. Block direction is trickier, in my opinion, and not as important. But real testing is the thing everyone should do to check which units to apply in their cases.
“Some use cases for display: contents” by Mayank — a nice look at the contents value of the display property. Applying it to custom elements is one thing I was thinking for a while about. And while I don’t think we’d get something like the “Light DOM slots” through CSS in the way they suggest, there is a chance we’d get a ::contents pseudo-element one day. I wanted to compile a list of my use cases for it and post it to this issue, maybe I will find time to do this finally.
“View transitions and stacking context: Why does my CSS View Transition ignore z-index?” by Nic — an interesting exploration of some view transitions’ nuances. I’ve yet to seriously try them, so it is nice to already have people looking into them and gathering workarounds to the potentially common issues.
“Workarounds for buggy gradients” by Keith J. Grant — the new color spaces in CSS are cool, but there are still numerous issues in various browsers in how they’re applied and interpolated. This article provides a workaround to some of such issues. It is also a nice example of how writing about the issues you encounter, as well as your workarounds, can help everyone — Adam Argyle did use this article as something to motivate the engineers to look into this issue.
“OKLCH for better color in the browser” by Jason Lengstorf — a brief look at the OKLCH color space, with some examples and helpful links to some resources related to it.
“What are my CSS user preferences?” by Šime Vidas — a tiny test page that can help in understanding which of the CSS-detectable user preferences are currently applied in your browser.
“Intent to Ship: :has Selector” by Mozilla — finally! I’m delighted that the :has() pseudo-class is already available in Firefox Nightly, as now that I moved to it, I can use my CSS overrides. Nicolas Chevobbe did also [email protected]/111330044743627218">share on Mastodon that they would also provide some nice touches in the Firefox DevTools, warning about the performance impact of the unconstrained :has() selectors.
“RESOLVED: The CSSWG supports this CG’s efforts in defining levels for CSS as a way for the community to understand batches of CSS features” in the issue by Jen Simmons — nice to see attempts to make CSS more “marketable”. I’m not entirely sure that the numeric naming is the best approach there, but it is good that there is at least some movement.

My Blog Posts

My previous “weekly” was on the November 1st, and I did post every day since… And I did skip all the weekly posts afterward. So, here is everything I wrote in this blog after the previous weekly!

If you did miss any of these — given them a go! Unlike the articles over at my main website, these are much shorter, haha.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 5: CSS and Web Components

Sun, 19 Nov 2023 00:00:00 GMT

Current music:: Helen Bell — Come Down and See
Current drink:: Gazpacho

I did not have to compile all the bookmarks I had for all the topics, so here is what I have decided to do: I’ll try to post at least CSS-related stuff in every weekly, but as long as I have a backlog of various things, I’ll group them by topic, and will add a section with things only related to this topic. This should allow me to go through the backlog without straining myself. Maybe.

CSS Articles and News

“Getting started with CSS container queries” by Michelle Barker — a nice introductory article about container queries.
“CSS Nesting” by Ahmad Shadeed — an article about native CSS nesting with many helpful examples. Ahmad also wrote a CSS Nesting UX in DevTools article where he shares his idea on how the browser DevTools can improve their CSS nesting support.
“About subgrid and colored grid lines” by Lene Saile — an article about using CSS grids, subgrids, and some workarounds for displaying grid lines.
“Weird Things You Missed About CSS” by Stephanie Eckles — the recording of a CSS Café talk which I announced in my second weekly, but I couldn’t attend at the time due to incredibly slow Wi-Fi on the train.
“Let’s Play a Game” by Brian Kardell — a post about the Interop 2024 proposals, with a proposal to read them and sort them. Or at least some of them. I did this, and shared in a “Interop Priority Game” post.
“20 years ago, I had an idea” by Egor Kloos — a post about creating a CSSZenGarden theme 20 years ago and reflecting on some coding decisions made at the time compared to now.
“Igalia Chats: The Power of CSS” — I was a guest on a podcast, where I chatted with Brian Kardell and Eric Meyer about some CSS stuff. You can listen to it if you’d like. Or read it — the transcript is available as well.

Web Components and Shadow DOM

In the last few weeks, there were many articles about web components, custom elements and shadow & light DOMs. I won’t link to all of them, as that would be too much, but to a snippet of them, in chronological order. Most of these articles would have links to other related recent posts — highly recommend!

“Web Components Will Outlive Your JavaScript Framework” by Jake Lazaroff — an article about how using native web components can make the code more resilient (given we won’t use any framework code inside of them).
“Blinded By the Light DOM” by Eric Meyer — an article about how we don’t have to use Shadow DOM to use Web Components, and can just rely on light DOM, progressively enhancing our regular HTML. The next day after this article, I published what can be called an inverse article: “Shadow DOM on Regular Elements” — how we can do the opposite and not use custom elements, but still use shadow DOM.
“Presentational shadow DOM” by Mayank — an article about how shadow DOM makes it harder to use the cascade, where they propose some hypothetical ways to improve this.
“HTML web components” by Jeremy Keith — an article that coins the term, and links to numerous other articles (a lot of them are not in my list).
“HTML Web Components are Just JavaScript?” by Miriam Suzanne — an article exploring some aspects of web components, as well as a very curious idea of a register-element web component to register other web components. I really hope at one point we will get the Declarative Custom Elements, but I really like an idea to use another web component to do this today!

My Blog Posts

Between the last “weekly” and this one were six days, so this section has six links today:

Let me know what you think about this on Mastodon!

Weekly Bookmarks 6: CSS, Typography and Design

Sun, 26 Nov 2023 00:00:00 GMT

Current drink:: Carbonated water with fruit juice

CSS Articles and News

There was not a lot of stuff this week on the CSS part, probably due to the Thanksgiving and all of that. But still something!

“An Interactive Guide to CSS Grid” by Josh W. Comeau — I always loved the way Josh explains things, and even though I did not have an opportunity to go through his new guide completely, what I saw has all the usual good bits: interactive examples and good examples.
“@scope MDN docs” by Chris Mills — comprehensive docs about CSS scopes, talking about its various features and nuances.
“oklch() retains perceived lightness for different hue angles” by Stefan Judis — a little exploration of how OKLCH handles the change in hue, with a nice interactive demo.
“Scroll Timeline Parallax Effect” by Michelle Barker — a small experiment that demonstrates how we can use scroll-driven animations to achieve the parallax effect in CSS.

Typograhy and Design

Continuing the “tradition” of including one more topic apart from CSS in my weekly, this time it contains some typography and design links.

“Minimalist Affordances: Making the right tradeoffs” by Lea Verou — an article about the usability of the new GitHub comment UI, where they did try to move the focus outline around the whole comment block, including other interactive elements inside. I think they might’ve gone back on this decision since? Nevertheless, the post is a pleasant read anyway, exploring the ways things become conventions.
“The Monaspace type system” by Lettermatic and GitHub Next — a new “monospaced type superfamily”. It uses an interesting and novel technique of “texture healing”, where the contextual alternates are used to adjust the position and form of the characters in a monospace context. The adjustment of the form is what differentiates it from the regular kerning. I first heard about the Lettermatic studio from their work on Pentiment game by Obsidian Entertainment, where they did also do a lot of innovative work with the fonts. I can highly recommend both reading their case study about this and the game itself.
“It’s 2023, here is why your web design sucks” by Heather Buchel — an evocative article about how the profession of “web designer” dissolved in the industry. My experience was slightly different, but there were still enough similarities, and it is always fascinating to look at how things evolved differently in other places.
“Practical Typography” by Matthew Butterick — an online book (free, but payment is encouraged) about typography. It was recommended to me in a Mastodon thread where I asked for some typography book recommendations, and going through a few sections of it, there are things to like.
“The Nevermore: The Collected Works of Edgar Allan Poe” by Joshua Mauldin — a good example of applying typography to the web in practice. Maybe one day I’ll actually read some of it!

My Blog Posts

Between the last “weekly” and this one were six days, so this section has six links today (yes, this is the same paragraph text as in the previous weekly; probably for the last time, as next week the November ends, and with it my venture into posting every day):

Let me know what you think about this on Mastodon!

CSS Scope Issues

Thu, 21 Dec 2023 00:00:00 GMT

Current music:: Mice Parade — Two, Three, Fall
Current drink:: Lapsang Souchong tea

A week ago, a “CSS @scope” article by Miriam Suzanne was published at “12 Days of Web” (curated by Stephanie Eckles).

This article did clarify a few things for me, but also made me think of one potential usage of the :scope pseudo-class: “storing” the scoping root’s selector as a reusable entity, covering the use case which is available in some CSS preprocessors: @at-root in Sass and root reference in Stylus. We don’t have anything like this with native CSS nesting, so the possibility to use scopes in this way seemed like a really neat feature.

However, when exploring this use case, I stumbled upon a few issues, one of which was the way Chromium implemented the :scope inside the :is(). I did open a PR to Web Platform Tests adding a test for this.

It is from a comment in this PR by Matthieu Dubet that I first heard about the @scope becoming stable in WebKit!

Of course, I couldn’t help myself from going and exploring how the @scope works in Safari Technology Preview.

Some things that I did found were nice (my use case with :is(:scope *) did work, unlike in Chromium!), but also some things did not work as I expected. However, my expectations for these are based more on the current Chromium implementation, rather than the specs — I think a lot of these are in the “gray area”, not yet exlicitly defined in the specs (or explained there in a not the most obvious way, allowing room for an implementation difference between Chromium and WebKit right now).

Some more explorations and thinking later, I did open four issues in CSSWG. I will not copy what I did write there here, but will invite you to read them yourself, and participate in case you’ll have something to contribute! Here they are:

I hope these issues will be clarified in one way or another, allowing me to be more sure when writing the follow-up WPT tests for the @scope issues I discovered.

Let me know what you think about this on Mastodon!

My LiveJournal Anniversary

Tue, 12 Dec 2023 00:00:00 GMT

Current music:: The Album Leaf — Eastern Glow
Current drink:: Sencha tea

Twenty years ago, I created an account on LiveJournal. As I did write in my “Personal Site Anniversary & History” post, plenty of things did bloom from this. Highly likely, without LiveJournal I won’t be here as a web developer. Without it, I won’t be as good with CSS.

From the start, LiveJournal had an ability to add custom overrides for your journal. In the “S1” system, you were able to add custom HTML snippets into a few places of the page, which, thanks to absolute positioning, unlocked almost unlimited styling possibilities. In the “S2” system that ability to add custom HTML was absent (unless you did pay and get an ability to do much more complicated things with S2), but there were built-in themes which were done without using tables for layouts! All CSS! And that made it possible to override them much easier.

Maybe one day I’ll go through my archives, and try to gather all the styles I wrote for my and my friends’ journals. It was fun, and I did learn so much, even though, occasionally, there were very wild hacks that we had to use to achieve various effects.

In 2009, I joined the company that bought LiveJournal as a front-end developer. Vadim Makeev, who is now working as a technical writer in MDN, was the person who hired me.

Eventually, social networks overshadowed LiveJournal, but I still treasure the memories I made when I was using it, and working on it.

Social networks, with all their convenience, were not the same outlet for creativity as LiveJournal. No ability to provide custom anything outside a few pictures here and there, and maybe a color scheme.

I hope, one day, there’ll be something that could fit the same niche as LiveJournal, where regular users could experiment with CSS freely. Some IndieWeb and Fediverse progress could make this possible, though it is less on the protocols, and more on the authors of software like Mastodon to provide all the tools we, as users, could need to unleash our creativity.

Imagine having a custom CSS field for your Mastodon profile?

With the recent advancements in CSS like custom cascade layers and scopes, with more strict ways of handling style encapsulation via Shadow DOM, especially with the Declarative Shadow DOM in the future, alongside some other tools, an implementation of custom styles fields was never as close and as effortless. Maybe, one day…

Finally, as a present for myself, and as a way to bring something back from the times I was using LiveJournal (there were so many things that are yet to be back in the modern social networks and blogging platforms!), I’ve decided to do one thing: bring back the “current” fields to my blog. You might’ve noticed them at the top of this page!

For some time, I was adding some metadata alongside a lot of the posts here, and now is a good time to just start showing them on every page. I’ve done it via adding a <dl> at the top of each page — not sure if that’s the best tag for the job, but I’m open to suggestions! As with almost anything else in this blog, this is a place that could benefit from improvements.

I’m not using my journal anymore, and there is no point to linking to it, but 20 years, huh.

Let me know what you think about this on Mastodon!

My year in CSS

Sun, 31 Dec 2023 00:00:00 GMT

Current music:: tricot — Laststep (Acoustic)
Current drink:: Lapsang Souchong tea

2023 was very productive for me in terms of experimenting with CSS and writing about it. I guess, escaping from reality by submerging yourself into your special interest can have positive results occasionally.

Today, I will list almost everything I published about CSS this year, and write a bit of context about some of it.

“Future CSS: Anchor Positioning”

March 15. Exploring anchor positioning was the thing that started it all. I began experimenting with it as soon as I saw its first prototypes in Chrome Canary, and spent a few months working on this article, coming up with examples, thinking about which issues to open in CSSWG, and so on.
“Future CSS: Wishes Granted by Scroll-driven Animations”

May 30. Another thing that I started experimenting with — scroll-driven animations. Curiously, I did not initially think that I write anything about them. I don’t really do promo sites these days, and, at first glance, this feature seemed like it was only useful for various long scrollable pages with elements flying everywhere. How was I mistaken! Scroll-driven animations ended up being powerful: allowing us to query elements’ positions and dimensions.
“Cyclic Dependency Space Toggles”

June 14. Going back from CSS Day on a train, I was playing with some workarounds for the container style queries when I stumbled upon what ended up being this technique. I think it is very neat!
“Fit-to-Width Text”

June 21. I think my brain was on fire after CSS Day. Thinking a lot about scroll-driven animations, one day I just woke up with this idea — and wrote a post in one day. Based on the engagement in Mastodon (the only way I can track things now that I have removed any analytics from my website), it is the most popular thing I came up with this year. I have something in the works related to it, so stay tuned!
“Position-Driven Styles”

June 28. A continuation of my experiments with scroll-driven animations, exploring the whole position aspect of them. Many things I did explore in this article I consider foundational, and I’m planning to write at least one other similarly foundational article about a similar concept.
“Scroll-Driven State Transfer”

October 16. Yet another article about scroll-driven animations, this time about a smaller technique. A bit more hacky than some other things I did explore, but still rather useful as a concept (and as a thing that can be applied to other similar cases like anchor positioning in the future).
“The Shrinkwrap Problem: Possible Future Solutions”

December 7. My second article about anchor positioning — about how it works with inline elements. This article was maybe a bit too long in the works — among many other drafts of various experiments. The technique from this article solves an issue that is impossible to solve otherwise. Which is neat, but also makes it harder to wait for the anchor positioning.
“Igalia Chats: The Power of CSS”

November 13. Brian Kardell and Eric Meyer invited me to chat with them. My first podcast in English, I was very nervous! But I always enjoy talking about CSS and was happy that there are others I can share my love with.
“Anchor Positioning”

December 14. Stephanie Eckles did accept my submission for her “12 Days of Web” advent calendar. It was a challenging topic — due to anchor positioning specs not even being finalized yet, I had to think about how I wanted to approach an “overview” article like that. I hope the result was ok! This was also the first time I wrote for anywhere besides my website, I think.
“A Peek Into the CSS Lab”

December 14. Yes, on the same day! I was invited by Christian Schaefer to give a small talk, and I chose to show some of my older experiments and some of my not yet finished ones. As it goes, I did mention many other resources during this talk — I’m still gathering the links to them, and I’m planning to post a list of them in the following weeks.

I did omit all the posts from this blog, but you can see them all by visiting “CSS” tag page. Maybe you missed some of these posts!

Other than blog posts and articles, I created numerous issues in various browser bug trackers, participated in CSSWG discussions (and was invited by Elika J. Etemad to virtually attend a session dedicated to anchor positioning at TPAC), and submitted a number of my first Web Platform Tests.

I think it could be cool to list all of these here as well, but it is a lot! Maybe one day I will gather all of my external contributions, like from the above list, and link to them in one way or another.

I want to thank everyone who spoke with me in Mastodon, be it about CSS or not. Many people did invite me to do one thing or another, which is not something I’m used to, and I’m truly thankful.

I don’t know what the next year will bring, and the only thing I wish for everyone is peace and love. See you in 2024.

Let me know what you think about this on Mastodon!

A Christmas Tree Selector: Prototyping the :nth-sibling() with CSS Nesting

Mon, 25 Dec 2023 00:00:00 GMT

Current drink:: Yunnan tea

Introduction

While working on another article, I stumbled upon a case that I never could achieve in any good way: an ability to select repeating groups of elements.

We have :nth-child(), but it only allows us to select one specific element, and while we can do things like “Quantity Queries” (article by Heydon Pickering), :nth-child() really allows us to only select a finite group of elements, or repeating sequences of a single selected element.

What I want is: to be able to select groups like A-A-A-B-B-B-A-A-A-B-B-B and so on. I’m not alone in wanting something like that: there is a CSSWG issue with comments from Amelia Bellamy-Royds and Johannes Odland thinking about a hypothetical :nth-sibling() pseudo-class that could allow us to achieve it.

But right now — we don’t have a good way to do this. However, I did spend some time trying to come up with something that could be used for prototyping it instead.

A List of `:nth-child()` Pseudo-Classes

If we were to express the above A-A-A-B-B-B-… grouping with the :nth-child(), we will have to repeat it for every element of the group:

Component is not available in RSS, visit the the site to access it.

.example1 {
	li:nth-child(6n+1),
	li:nth-child(6n+2),
	li:nth-child(6n+3) {
		background: var(--GREEN);
	}
}

Component is not available in RSS, visit the the site to access it.

It is a bit cumbersome, but it works:

First, we need to determine the periodicity — at which point does our pattern repeat? In the above case, every sixth element is the same, so we’re using the 6n inside the :nth-child().
Then, as we want to select the first three elements of every group, we have to repeat the selector for every +1, +2, and +3. And if we wish to invert the logic and select the elements from the fourth to the sixth, we could just use +4, +5 and +6.

As you can guess, if we would like to have a group of ten selected elements, we would have to repeat ourselves ten times! Which is far from ideal. This is where we can introduce native CSS Nesting.

A Christmas Tree Selector

We can omit a bit of repetition if instead of using a separate :nth-child() we will use only one of them, but then use a next-sibling combinator:

Component is not available in RSS, visit the the site to access it.

.example2 {
	li:nth-child(6n+1) {
		&,
		& + *,
		& + * + * {
			background: var(--GREEN);
		}
	}
}

Component is not available in RSS, visit the the site to access it.

Two important notes:

This is likely to be more performance-expensive than a regular :nth-child(). While performance of selectors is usually very fast these days, :nth-child() and sibling selectors can be potentially harmful for large DOM trees, especially when the nodes are added and removed dynamically.
This makes sense only with native CSS nesting: when using preprocessors, just using the repeated :nth-child() should be more performant (this is only speculation; actual testing should be done).

Why did I call this a “Christmas Tree” selector? Let’s say we will want to select the abovementioned group of 10 elements and format our code a bit differently:

Component is not available in RSS, visit the the site to access it.

.example3 {
	li:nth-child(20n+1) {
		         &,
		        &+*,
		       &+*+*,
		      &+*+*+*,
		     &+*+*+*+*,
		    &+*+*+*+*+*,
		   &+*+*+*+*+*+*,
		  &+*+*+*+*+*+*+*,
		 &+*+*+*+*+*+*+*+*,
		&+*+*+*+*+*+*+*+*+*
		         {
			background: var(--GREEN);
		}
	}
}

Component is not available in RSS, visit the the site to access it.

Yeah. Not super practical, but, in my opinion, better than a list of repeated :nth-child() where we have to adjust every number if we want to adjust how it is applied!

And it looks neat.

Maybe you could even spot an owl hidden somewhere between the branches of this tree!

Further Optimizations

When thinking about this, I thought of one optimization that we could do to reduce the number of lines of code (but not the complexity, really): combine both methods:

Component is not available in RSS, visit the the site to access it.

.example4 {
	li:nth-child(20n+1),
	li:nth-child(20n+6) {
		    &,
		   &+*,
		  &+*+*,
		 &+*+*+*,
		&+*+*+*+*
		    {
		    background: var(--GREEN);
		}
	}
}

Component is not available in RSS, visit the the site to access it.

If the count of elements in our group is not a prime number, we can express our desired “group” as a product of two or more nested selectors! In the above case, we can use just two :nth-child() and a smaller Christmas tree to achieve our group of ten, as 2×5=10.

And if we can have our group as a product of more than two numbers, things can be simplified even more, like for selecting twelve elements it can be expressed as 2×3×2:

Component is not available in RSS, visit the the site to access it.

.example5 {
	li:nth-child(24n+1),
	li:nth-child(24n+7) {
		    &,
		  &+*+*,
		&+*+*+*+* {
		    &,
		   &+*
		    {
		    	background: var(--GREEN);
		    }
		}
	}
}

Component is not available in RSS, visit the the site to access it.

Now we have just two happy little trees.

The Need for `:nth-sibling()`

As demonstrated by the above cases, even though we can try to optimize the selectors, they’re still a bit too complicated. I won’t use them in production, and won’t recommend doing so as well.

With all the goodness that we got recently in CSS, including things like CSS Scopes, CSS Nesting, :nth-child(… of …), and so on, an ability to easily select these groups of selectors seems like a big missing piece.

Over the years, I did come upon many cases when I wanted to have something like that. If you did as well — I urge you to post them to the abovementioned CSSWG issue and share your thoughts about the existing proposals and their syntax — will it apply to your cases? Is there still something missing?

Let me know what you think about this on Mastodon!

Weekly Bookmarks 7: CSS and HTML

Sun, 03 Dec 2023 00:00:00 GMT

Current music:: Huge Shark — One Day (single version)
Current drink:: Yunnan tea

Today’s “weekly” is a short one! Mostly about CSS and HTML, no bonus topics this time.

“HTMHell Advent Calendar 2023”, curated by Manuel Matuzović — a collection of articles by different authors. I highly recommend checking them out and subscribing to its RSS. I won’t include all the articles here in my weekly, even though all of them would be worthy — the joy of such calendars is the joy of not knowing what is inside, and I won’t steal it from you. Sorry, article authors, for not mentioning you!
“Web Development Advent Calendars for 2023” by Adrian Roselli — a round-up of many advent calendars related to web development. I did not find many things that I could relate to, but I encourage you to check the list out — maybe you’ll find something up to your liking!
“I restyled my Mastodon instance” by Eric Bailey — a post, showing how using BEM classes (instead of some generative or abbreviated mess) and an ability to add custom styles in an admin UI allowed Eric to modify the styles for his Mastodon instance.
“How to Use Responsive HTML Video (…and Audio!)” by Scott Jehl — an article about how support for responsive audio and video returned to Chrome and Firefox, allowing us to adjust the sources based on various media features.
“Drop a cap?” by Sarah Gebauer — a short blog post about using initial-letter in CSS, which mentions a few of the current cross-browser issues with it. In my practice, there are maybe too many interop issues with both initial-letter itself, and the :first-letter in general — I’ll need to find time to finish my research on this.
“Revealing ‘back to top’ button” by David Darnes — a CodePen with a simple way to achieve a “back to top” button’s effect. While it is simple, it relies on the link having an inline display, which, interestingly, makes the margin to affect the sticky behavior, while not applying the margin in the layout itself. Quite a curious interaction in CSS.

My Blog Posts

With the November ending, I did stop writing one post per day. Still, last week included the last four days of that productive month, so here are my last four posts from it:

Let me know what you think about this on Mastodon!

Weekly Bookmarks 8: Mostly CSS

Sun, 10 Dec 2023 00:00:00 GMT

Current music:: Delta Sleep — Camp Adventure
Current drink:: White tea with litchi, pineapple, mango, and papaya

I did not have a lot of time to read stuff outside my CSS comfort zone this week, so, once again, mostly CSS-related links.

My Experiments

“The Shrinkwrap Problem: Possible Future Solutions” — last Thursday I published a new larger article.

Anchor positioning, once again, solving one of the hardest CSS problems! Not for all the cases, but enough that when we will finally get it in all browsers, this will be a really useful technique.
“A Peek Into the CSS Lab” — next Thursday I’ll talk about some of my experiments at CSS Café.

6:00 PM CET, online, free. Everyone is welcome!

CSS Articles and News

“Baseline’s evolution on MDN” by Vadim Makeev — a short article about the changes in the Baseline and how it will be displayed on MDN pages.
“A definition update for Baseline” by Rachel Andrew, Kadir Topal, and André Cipriani Bandarra — a similar post about the Baseline update by the Google team.
“CSS Wrapped: 2023!” by Una Kravets, Bramus, and Adam Argyle — an extensive overview of many new features in CSS that Chrome did ship this year. Plenty of nice demos!
“Media Queries in HTML Video” by Adrian Roselli — a good exploration of various ways we could now use the <video> element that adapts to various media features.
“Oh no! My JSON!” by Tony Mottaz — a short post, reminding that not all small “progressive enhancement”-like features like hanging-punctuation should be applied to everything. Similar to text-wrap: balance, it is better to scope it to places you will sure need it.
“Three Decades of HTML” by Eric Meyer — a short post about how Eric wrote his first HTML document. I really like these kinds of posts: I did write a similar post around a month ago — “Personal Site Anniversary & History”.
“12 Days of Web” curated by Stephanie Eckles — starting from the next Wednesday, for twelve days, there will be one new article about the web platform posted every day. For now, if you’re wondering what there was in the previous years, I recommend to check out the archives: 2022 and 2021.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 9: CSS (as Usual)

Sun, 17 Dec 2023 00:00:00 GMT

Current music:: Some Baldur’s Gate 3 battle music
Current drink:: Mulled wine from an alcohol-free Cabernet Sauvignon

I’m a bit tired after this week — I did speak about some of my CSS experiments at CSS Café on Thursday (later there’ll be a recording), so there are not as many links today, and, as usual, mostly only about CSS.

“12 Days of Web” curated by Stephanie Eckles — I did already share a link to it in the previous “weekly”, but now there are already a few articles to check out! I highly recommend you to check them out and follow the new ones every day. I’ll list the ones from this week inside the <details>, as a way not to spoil the topics for you.
This week’s 12 Days of Web’s articles (5 links)
- “Popover API” by Ryan Trimble — an introduction to the Popover API.
- “Anchor Positioning” article by me! Coincidentally, it was published on the same day I did the CSS Café talk.
- “CSS @scope” by Miriam Suzanne — a post that lead to me finding an issue in the current Chromium’s @scope implementation, and me opening a PR to WPT for the case I found.
- “Web Components” by Mayank — an introduction to web components. Next year, I predict, will be a lot about them. There’ll be a lot more talk about them!
- “CSS animation-composition” by Tyler Gaw — an introduction to the animation-composition property. It is a very curious feature, which allows us to do some things not really possible otherwise. See also a follow-up Mastodon thread started by Christian Schaefer, with participation by Temani Afif and me, about the way the accumulate is calculated for the scale() transform.
“CSS Scroll Snapping Aligned With Global Page Layout: A Full-Width Slider Case Study” by Brecht De Ruyte — an article about how we can use CSS variables and calculations to snap elements inside a slider that escapes the container to align the items inside with the content.
“Carousel example” by Robert Flack — a prototype for the “CSS Overflow Extensions Explainer” by Miriam Suzanne, Robert, and Nicole Sullivan. It is an exploration of several interesting features that could help with creating sliders like in the above article. One of the explored parts of the proposal involving fragmentation is something I find very intriguing — I’m always for any advancements around fragmentation.
“Using date-based CSS to make old web pages look old” by Terence Eden — an article about how we could use a rarely used type of attribute selector for hyphen-separated values, as well as the :has() pseudo-class to style pages based on their publication date, targetting the <time>’s datetime attribute.
“A Mental Model for Styling the Shadow DOM” by Nathan Knowler — an article about one way we can think about the Shadow DOM styles, using the cascade for its purpose.

This week did also include an anniversary of my account on LiveJournal, and I wrote a short post about this: “My LiveJournal Anniversary”.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 10

Sun, 24 Dec 2023 00:00:00 GMT

Current drink:: Lapsang Souchong tea

It is the last week for many advent calendars. I did not have an opportunity to follow most of them — this is why I did post links from only one of them, but I will catch up in the following weeks! Regardless, there were some good articles about CSS outside of advent calendars as well.

“12 Days of Web” curated by Stephanie Eckles — now with all articles. As previously, I will put the related links inside the <details>, as a way not to spoil the topics for you.
This week’s 12 Days of Web’s articles (5 links)
- “View Transitions” by Chen Hui Jing — an introduction to view transitions. I’ve yet to properly play with them, as I’m mostly waiting for them to be available for regular page transitions. And when I did try them, I found out that they’re something that you have to design in-advance, and it might not be a good idea to try and apply them to existing web-sites without putting any thought into it.
- “CSS Nesting” by Kilian Valkhof — a round-up of various aspects of native CSS nesting. It feels so good to finally use it after years of preprocessors!
- “Scroll-driven Animations” by Michelle Barker — an introduction to some of the common use cases for the scroll-driven animations, showcasing some simple but festive examples. I did already write 4 articles about them, and not planning to stop — though I tend to explore the less common use cases.
- “Responsive SVGs” by Nils Binder — a nice exploration of how we can make the SVGs responsive. There are many interesting details, some of which I had to stumble myself when doing my examples involving SVG in my “Future CSS: Anchor Positioning” article (specifically, for the last example of the “Four Quadrants” section, and for the example in the “Using the Connections”).
- “Container Style Queries” by Manuel Matuzović — an introduction to the style queries. During this year’s CSS Day many speakers did mention style queries as something that could solve one or another problem. We need more articles about them! And we need them in all browsers as well, the sooner — the better.
Note: I did not list two posts about JS; if you’re interested in them — look for them on the website for yourself!
“The mysterious case of using CSS animation-composition: accumulate on a scale transform” by Bramus — an explanation of one curious detail from one of the last week’s “12 Days of Web” articles.
“New CSS Viewport Units Do Not Solve The Classic Scrollbar Problem” by Šime Vidas — a deep dive into viewport units, their interactions with classic scrollbars, some other related contexts, and how we can work with them.
“CSS-based state management” by Mayank — an exploration of how CSS custom properties can be used to store state, utilizing the way inheritance works in CSS.
“Border images in CSS: A key focus area for Interop 2023” by Dipika Bhattacharya — an MDN article about border-image. As the title of the article says — this property was one of the focus areas for this year, and browsers did a lot of progress on fixing interop issues with it. This is still a rather challenging property to work with, but this article does a good job of talking through its fundamentals.
“Intent to Prototype: CSS calc-size() function” by David Baron. Can’t wait to play with it! An ability to have a transition between unknown width or height is literally the most reacted to issues in CSSWG repo. For now, there is only a CSS Grids trick from Chris Coyier, but having this available natively will be wonderful.
Firefox 121.0 Release Notes — among others, I want to note two notable CSS-related features: addition of text-wrap: balance, and, more importantly — :has() selector, which is now available in all stable versions of major browsers! Maybe not yet a time to put it into production, but a time to start learning about it. There are many articles about it already (someone should make a round-up!), and at least two were written specifically due to the release:
- “Can I :has stuff?” by Sarah Gebauer — in which she explores the basics of it.
- “Locking scroll with :has()” by Robb Owen — in which he looks at one of its possible use cases: detecting when we need to “lock” the scrollbar based on some condition (I can already think of using it with :popover-open from the Popover API)
Safari Technology Preview 185 Release Notes — again, I want to focus on just two points: align-content in normal flow (which was already present in Chrome Canary, and now we could test it in Safari TP thanks to a contribution by Elika J. Etemad), and a relatively stable implementation of @scope! Here are two related articles from this week:
- “How Do You Vertically Centre an Element in CSS? (Even More) Easily!” by Michelle Barker — an overview of this new possibility.
- “CSS Scope Issues” by me — a post and links to four CSSWG issues I created after testing the @scope in Safari.

Let me know what you think about this on Mastodon!

Cap-Height Vertical Align

Wed, 03 Jan 2024 00:00:00 GMT

Current music:: Ichiko Aoba — Sagu Palm’s Song
Current drink:: Lapsang Souchong tea

Introduction

The new year is here, and, with it, a season where people put out their CSS wishlists for the future. I did already read two of them: December’s CSS wishlist from Sarah Gebauer, and today’s “Tyler’s CSS Wish List for 2024” from Tyler Sticka.

One thing I love to do when I see these wishlists is to think of all the ways we can do the things from them already. It is always a good challenge, and quite often can result in some wild experiments.

There are other things that I’d want to experiment on later, but one thing caught my attention in Tyler’s list: an ability to vertically align to the middle of the font’s cap-height.

This is something I did research in the past, and I am thrilled to report that there are at least two relatively ok workarounds available in the most recent browsers, courtesy of the new cap unit!

Two Techniques

Unknown Size, Negative Margin

The simplest way we can utilize the cap to achieve alignment to the middle of the capital letter of the font (also known as “cap-height”) is by relying on vertical-align: middle and a simple calculation:

Component is not available in RSS, visit the the site to access it.

.example1 .icon {
	vertical-align: middle;
	margin-block-start: calc(1ex - 1cap);
}

<div class="example example1">
	<span class="icon"></span>
	Nicely Aligned
</div>

Why do we subtract cap height from the x-height? When we align things with vertical-align to middle, we’re aligning things to the middle of the font’s x-height. Here is an example of how things look without our technique:

Component is not available in RSS, visit the the site to access it.

.example-broken .icon {
	vertical-align: middle;
}

<div class="example example-broken">
	x
	<span class="icon"></span>
	Not Nicely Aligned
</div>

Occasionally, this method might work, but in very rare cases where we’re certain that we’re aligning things over the lowercase letters only, with not many ascenders on the letters. Otherwise, predominantly, we want to align things to the cap height.

So, if the middle value aligns things to the x-height, but we want the cap height, the only thing we need to do is just move the element by its difference! That’s where the 1ex - 1cap comes from, and the element’s height is already accounted for by the middle value.

Known Size, Just Vertical-Align

The example above is nice but requires us to use a negative margin. There is a different way to achieve the same, but only if we know the height of the element we’re aligning:

Component is not available in RSS, visit the the site to access it.

.example2 .icon {
	--size: min(2em, 10vw);
	vertical-align: calc(0.5cap - 0.5 * var(--size));
}

<div class="example example2">
	<span class="icon"></span>
	Nicely Aligned
</div>

Our formula here is 0.5cap - 0.5 * var(--size): half of the cap height minus half of our element’s height. How is this calculated? When the value of vertical-align is a <length>, an element is aligned in a way its bottom edge stays on the text’s baseline:

Component is not available in RSS, visit the the site to access it.

.example-baseline .icon {
	vertical-align: 0;
}

<div class="example example-baseline">
	<span class="icon"></span>
	Baseline Alignment
</div>

You might ask: why use this method when it has the limitation of having to know the element’s height?

The answer: sometimes we might not know the context in which our element will be present, and if we will place our element in a context with align-items: center, it might not look good! We can easily demonstrate this by placing both examples inside a flex context:

Component is not available in RSS, visit the the site to access it.

.example-flex {
	display: flex;
	gap: 0.5em;
	align-items: center;

	& > * {
		display: contents;
	}
}

<div class="example-flex">
	<div class="example example1">
		<span class="icon"></span>
		Not Nice
	</div>
	<div class="example example2">
		<span class="icon"></span>
		Nice
	</div>
</div>

Because, in this case, we’re relying on the flex alignment, the vertical-align stops working. For our second technique, it is not relevant, as it was the only thing that handled the alignment (which is now handled by flex), but for the first technique, the margin stays, resulting in misalignment.

That means, that if we’re sure our element will always be in a regular inline flow, we can rely on the negative margin. But if we know the element’s size, then it might be beneficial to use the method that only uses vertical-align.

The Fallbacks

As I mentioned at the beginning of this post, while the cap is newly available, we should not use it in production as is. Too soon.

However, usually, it is not super complicated to work around it, at least partially.

The way to go could be to use a CSS variable and @supports, below is the same technique as in the first example, but modified to work without cap support:

Component is not available in RSS, visit the the site to access it.

html {
	/* Adjusted for Iowan Old Style */
	--cap: 0.704583em;
}

@supports (height: 1cap) {
	html {
		--cap: 1cap;
	}
}

.example-fallback .icon {
	vertical-align: middle;
	margin-block-start: calc(1ex - var(--cap));
}

<div class="example example-fallback">
	<span class="icon"></span>
	Nicely Aligned
</div>

The only thing we have to do is to replace all our cap units with a var(--cap) variable and set it via @supports to 1cap while setting it to the necessary value in em based on the font’s metrics by default.

How did I determine the value 0.704583em? It is simple! Now, with cap being available in the browsers, it is effortless to get the proportions of any font. What I did was get a square with a font-size of 1000px, and set its height to 1cap, which resulted in 704.583px, which, when divided by 1000 results in our value!

Of course, it will work perfectly only for the font I did test it with — “Iowan Old Style” in my case, which I can see on my macOS as I’m using a stack with the built-in fonts. If you’re looking at this example in a browser that does not support cap and does not have Iowan Old Style installed, the alignment could break a bit. Which, in most cases, could be fine if this is only a visual alignment issue, and should not result in the content being inaccessible.

And if you’re using a custom web font, then it is more likely it will be always present, so it is safer to embed its metrics in this way.

In Conclusion

I’m delighted that browsers improve the ways we can work with web typography. Maybe progress is not as fast as I would’ve liked (there are so many things I’d want to have!), but the arrival of cap (alongside other very helpful units like ic and lh) unlocks many doors.

As demonstrated, both techniques involving the cap rely on calculations and have their issues — that’s why I will still recommend going over the Tyler’s CSSWG issue and voting for it, optionally providing your use cases or thoughts on the desired syntax in the comments. And maybe one day we could solve this just by using a single declaration involving vertical-align!

Let me know what you think about this on Mastodon!

Notes on Using Logical Properties and Values

Sun, 07 Jan 2024 00:00:00 GMT

Current music:: The Album Leaf — Eastern Glow
Current drink:: Yunnan Tea

Adam Argyle asked today:

is it time to forget about physical properties like margin-top and left?

I have some thoughts occasionally on this, and decided to write them down as a list: maybe I’ll update it later with other related things, we’ll see. At the bottom of this post, I’ll also list several useful resources — don’t forget to check them out!

If you’re new to logical properties and values in CSS, it might be overwhelming to start using them: so much to learn! I will suggest starting slow, do not attempt to learn everything at the same time.
For myself, I found the best way to get used to how logical keywords work was to first start using only logical shorthands: margin-block, margin-inline, padding-block, padding-inline and so on. They’re tremendously useful on their own! Through the years, I often wanted to have these kinds of shortcuts like margin-x, and these logical shortcuts fulfil this. By starting using them, you will cover some of your use cases, and will get used to differentiating block and inline directions as a muscle memory, without thinking.
One way to think of the block and inline directions would be to imagine two lists: one where all elements have display: block, and another where all elements have display: inline. By default, block elements go vertically, and inline go horizontally — the same way the logical directions work as well.
After starting to distinguish between the block and inline directions, understanding start and end should be, hopefully, much easier! When looking at these keywords, the only thing we need to think about is the positions of the elements or content inside of them: what goes earlier, what goes later? The axis will be handles by block or inline, and I found that separating the parts in this way helps a lot.
While I’m mentioning trying different properties separately and getting to learn them slowly, I won’t recommend learning them this way in production. Very often, logical keywords should be all-or-nothing: by mixing them, it might be possible to break things in unexpected ways. It is always a good idea to test how things will actually work by flipping the direction or writing-mode, and seeing what happens. It is easy to make content inaccessible when you expect things to align: when one element flips its direction, and another does not — like when positioning something absolutely.
Speaking of absolute positioning: after margins, paddings, and borders it might be time to look at more “complex” (in terms of naming) properties: inset- group of properties as a logical alternative for top, right, bottom and left, and -size group of properties as an alternative for width and height.
- For inset the shorthands are very handy: the inset itself, with the inset:0 being the staple in a lot of CSS I write, and the inset-block and inset-inline joining the other directional shorthands that make it easier to learn the directions.
- The block-size, inline-size, and their min- and max- variations, on the other hand, do not bring any new capabilities, but it is important to learn them when you need to match them with other logical properties.
The names of some logical properties might be rather frightening: border-start-start-radius, border-start-end-radius, what? The way to remember which is which in this case is to remember how the two-value shorthands for margin and padding work (even though they’re physical): the first value in such shorthand is for the vertical direction, and the second is for the horizontal. If those were logical, with the default mapping of vertical – block and horizontal – inline, then for border-radius logical properties it is the same: the first keyword is for the block direction, the second is for the inline! So, in border-start-end-radius the start is in the block direction, and end is in the inline one.
On the other hand, some other cases, especially when only the values are involved, are easier: text-align: start and text-align: end are simple to remember.
We need to always check out the support of the keywords we’d want to try using with logical values. While the basic margins and paddings are well-supported, other properties could either be just arriving to the browsers (inline-start and inline-end for float and clear are supported in Chrome only from October 2023), or not well-supported (overflow-block and overflow-inline are available only for Firefox at the moment of writing this article). It is better to always check for the support yourself, and, if you have to support older browsers, provide fallbacks.
While it might be a good idea to approach CSS with logical keywords first, there are cases where we could want to use physical properties and values. For example, when we want to match something with the positions on an image, which won’t change based on the writing mode. And not everything is yet available in logical forms: transforms, backgrounds, some other cases — when there is a need to match our styles with the physical-only cases, sometimes there is no other choice than to use the physical properties and values alongside, to not create a mismatch.
However, as it is often with CSS, there are workarounds, like when using a :dir() pseudo-class (warning: started being available in Chromium-based browsers only from December 2023) and overriding things that are physical-only based on the direction.

Final thing: the above are just my thoughts on this, and I’m far from being an expert on this topic! There are many other resources and people who are much more familiar with it, and with other writing systems, who could provide more insights. I highly recommend checking out the following links (starting from references, and then listed in published order).

“CSS Logical Properties and Values Level 1” specification.
“CSS logical properties and values” — MDN page containing a list of most logical properties and values.
“CSS Logical Properties” by Adrian Roselli
“CSS for internationalisation” by Chen Hui Jing.
“Digging Into CSS Logical Properties” by Ahmad Shadeed.
“Logical Properties for Useful Shorthands” by Michelle Barker.
“Let’s get logical” by Jeremy Keith
“A long-term plan for logical properties?” by Miriam Suzanne

If you’ll have any thoughts, corrections or additions — please let me know!

Let me know what you think about this on Mastodon!

Weekly Bookmarks 11: The Backlog

Sun, 11 Feb 2024 00:00:00 GMT

Current drink:: Ginger & apple tea

Introduction

I did take a break from writing anything for the most of January. During this time, many people published tons of things, so this post will be very long. When I started compiling this list (and actually reading all the content I’m linking to), it ended up a bigger task than I anticipated, so I did also skip publishing over the first week of February. But I’m happy that so many people are writing about CSS!

Because the list of links is so long this time, I did put them into various categories: Interop 2024, Scroll-Driven Animations, Style Encapsulation, Forms and Interactions, Layout, Typography, Thoughts and Opinions, Theming, Other Articles, My Posts — feel free to skip to what you find more interesting, as there are more than 50 articles combined!

Interop 2024

Ok, the first thing I’m sharing is not from January, really. The list of focus areas was just been finalized!

“Celebrate a more interoperable web with Interop 2023” by Rachel Andrew — a post about the results of the previous year of the Interop initiative. It is very gratifying to see the possible progress when multiple browser vendors are working on the same goals.
“Interop 2024 Dashboard” — the dashboard to keep an eye on as a way to track the progress throughout the whole 2024.
All the stakeholders for this year’s initiative did post the introductory posts about it:
- “The web just gets better with Interop 2024” by Jen Simmons from Apple.
- “Interop 2024 Launch” by Lola Odelola and Lazarus Letcher from Bocoup.
- “Interop 2024” by Rachel Andrew from Google.
- “Interop 2024 Launches” by Igalia.
- “Microsoft Edge and Interop 2024” by Patrick Brosset and Dan Clark from Microsoft.
- “Announcing Interop 2024” by James Graham from Mozilla.
Some people did write about what got into the Interop 2024 list and their thoughts regarding this:
- “Interop 2024” by Andy Bell — a post about the focus areas from the initiative Andy looks forward to most.
- “Comparing Interop 2024 Choices to the Popular Vote” by Chris Coyier — a post looking at the differences between what was chosen and what people voting for the issues on GitHub wanted to be included. Personally, I think there might be a misconception over what the Interop initiative is, but that might be a topic for a separate blog post, not a sidenote in this long list of links.

Scroll-Driven Animations

While scroll-driven animations were not selected for the Interop 2024, I truly hope Safari and Firefox will ship them sooner rather than later: there are so many use cases for them!

“A Practical Introduction to Scroll-Driven Animations with CSS scroll() and view()” by Adam Argyle — a tutorial covering the basics of the scroll-driven animations (for more traditional effects on scroll, unlike the weird stuff I tend to do).
“Highlight Text When a User Scrolls Down to That Piece of Text” by Chris Coyier — a case-study of implementing an effect used by Lene Saile in her blog, but implemented using scroll-driven animations.
“CSS Scroll-triggered Animations with Style Queries” by Ryan Mulligan — an exploration of one way to have scroll-triggered animations, based initially on an observation it in Jhey Tompkins’ CodePen which implemented an effect similar to the one in the previous article, but with an addition of style container queries.

Style Encapsulation

There are many discussions about web components recently, specifically about Shadow DOM, style encapsulation, and other related topics. Here are some of the things I found interesting.

“Shadow DOM and the problem of encapsulation” by Nolan Lawson — an article looking at the problem of Shadow DOM style encapsulation, the tradeoffs of it, and some existing workarounds.
“So, You Want to Encapsulate Your Styles?” by Nathan Knowler — an article looking at the ways styles can cross the Shadow DOM boundary, and how we could use CSS layers, especially revert-layer keyword, to achieve encapsulation without it.
“Some use cases for revert-layer” by Mayank — a more precise look into the revert-layer keyword and its other use cases. Very fascinating techniques showcasing the uniqueness of this keyword and the powers of the custom cascade layers.
“half-light” by Brian Kardell — a small experimental library which allows writing special custom media-queries to inject some styles into the Shadow DOM from the outside.

Forms and Interactions

“Designing better target sizes” by Ahmad Shadeed — a long and very detailed article with many interactive examples about the target area of interactive elements, and some other related concepts like spacing and safe triangle areas for dropdown menus.
“Field-sizing just works!” by Kilian Valkhof — a practical overview of the experimental field-sizing property.
“Big, beautiful, beefy focus states with :focus-visible” by Dave Rupert — a post about how we can make the keyboard-only focus state much more prominent than the one that is also applied when using a regular :focus.
“When will Apple focus on Safari?” by Mayank — an article about how Safari mistreats the focus in CSS, where users have to jump through countless hoops to make it work, and how this is a serious accessibility and interoperability issue.
“The Most Underused CSS Media Queries: Hover & Any-Hover” by Jacob Padilla — a brief look at the hover and any-hover media queries.
“CSS knows about your mouse” by Sarah Gebauer — a similar post which also touches on the pointer media queries in addition to the hover ones.

Also, a reminder from me: cursor: pointer is a good default for any buttons. Just saying.

Layout

In this section, we have articles covering almost every layout possible in some way, maybe except for the flex layout.

“Tutorial: Four CSS Layout Modes and Their Use Cases” by Lara Aigmüller — a brief overview of four older layout algorithms: flow, float, multi-column and positioned.
“A Guide to Styling Tables” by Mads Stoumann — an article covering various ways we can style the tables.
“‘Inheriting’ grid dimensions from siblings with subgrid” by Lene Saile — an article about how subgrid children can affect the parent grid’s dimensions.
“Reality Check #3: Building out a layered hero grid layout from Dribbble” by Andy Bell — a deep dive into an implementation of an interesting layout using CSS grids.
“Always great grid - CSS grid + :has() + view transitions” by Adam Argyle — an experiment showing how we can use :has() in a way similar to quantity queries but when applied to the parent.

Typography

“Web typography: baseline grids made easy (finally!)” by Jake Giltsoff — an article about how the cap unit could help with implementing designs with vertical rhythm.
“Webfonts and layout shifting” by Sami Mäkelä — a post outlining how it might be possible to reduce the cumulative layout shift coming from the mismatch of the web font with its fallback, with a few useful resources that can help with it linked inside.
“Going beyond pixels and (r)ems in CSS - Relative length units based on font” by Brecht De Ruyte — a detailed article about font-relative units. While they can be used for non-typography related tasks, for obvious reasons typography is where they will be the most useful, and many examples in the article show this. The second part of the series looks into the viewport-relative units, which could also be used for typography, but less so.
“Using Font Variant Numeric” by Mandy Michael — an article about font-variant-numeric and all the different ways it can help in making numbers look good in text and tables by unlocking the alternative glyphs for the digits that might be present in the fonts you’re using.
“Nicer Text Wrapping with CSS text-wrap” by Will Boyd — an article about text-wrap and its two values: balance and pretty.

Thoughts and Opinions

“What’s Good?” by Brian Kardell — a question following some Interop 2024 discussions, where Brian asks us to look at things from a different angle and find what we have today and which awesome web platform features we got in the past few years.
“What’s Too Good to Be True?” by Matthias Ott — a response to the previous question.
“Is CSS alive?” by Matthias Zöchling — a related article with some thoughts about various recent CSS features and how useful Matthias finds them.
“A Call for Consensus on HTML Semantics” by Stephanie Eckles — a glimpse over how HTML semantics are not as simple and clear-cut, with many nuances making us think about the code we write.

Theming

Nothing too new in this section, but a few small things that are worth it to remember.

“Nested Dark Mode via CSS Proximity” by Jonathan Dallas — a post about how inheritance of custom properties makes them a good fit for theming.
“Use CSS accent-color to style your inputs” by Cassidy Williams — a reminder that we can use the accent-color property as a low-effort way to style the native inputs.
“Easy Theming with OKLCH colors” by Manuel Strehl — a demonstration of how we can use custom property inside an oklch() for theming purposes, achieving a similar effect as for the accent-color, but for any custom styles.

My Posts

Since last weekly, I did write just four blog posts, here they are:

Let me know what you think about this on Mastodon!

Weekly Bookmarks 12

Mon, 19 Feb 2024 00:00:00 GMT

Current music:: Heather Woods Broderick — Cottonwood Bay
Current drink:: Yunnan tea

I had a lot of fun and ideas reading this last week’s articles and posts about CSS: I’m so happy we have so many people sharing their findings!

“How To Center a Div” by Josh W. Comeau — a detailed explanation of various ways we can center things in CSS, with many interactive examples.
“Dynamic text color contrast based on background lightness with CSS/SVG filters” by miunau — an experiment about trying to get the contrasting color automatically for some other given color. Basically, what we might eventually get with the color-contrast(), but via using CSS or SVG filters instead.
“How I Solved My Font Rendering Problem” by Michelle Barker — a post about how it is important to explicitly mention the font-weight range in the @font-face rule of a variable font.
“How to fix the invisible scrollbar issue in iOS browsers” by Šime Vidas — an article about how iOS uses the top-level background color as the thing that defines the color of the overlay scrollbars, sometimes resulting in lack of contrast.
“The chaotic neutral nature of font-size” by Rasmus Fløe — an article about adjusting the size of the fonts to be more logical with font-size-adjust or its workarounds, and a few related issues.
“Scroll-Driven Animations: You want overflow: clip, not overflow: hidden” by Bramus — a post about how overflow: hidden could interact with scroll-driven animations and about one workaround for this.
“CSS-only Auto-Collapsing Mobile Menu” by Georgiana Blantin — an article about discovering a technique to detect (and use) the position of some elements in a container by using scroll-driven animations, a bit similar to the technique that I called “Position-Driven Styles”.
“The Fifty-Fifty Split and Overflow” by Ryan Mulligan — an article about one way to achieve a certain type of layout with two side-by-side columns, only one of which dictates the overall height of both.
“Playing with Infinity in CSS” by Will Boyd — an exploration of the CSS infinity constant, with a few curious notes about how it works. Last November, I explored how it could be used in clamp() as a way to remove one of the boundaries in my “Observation: Clamp to Infinity” post, though just a few days ago we got a CSSWG resolution to have a native ability to define none to achieve the same effect, thanks to Lea Verou’s proposal.
“Making the most of ligatures” by Mandy Michael — an article about the way we can control the rendering of ligatures in CSS.
“The New CSS Math: pow(), sqrt(), and exponential friends” by Daniel C. Wilson — a quick overview of a few newly available CSS math functions.
“Accent Color Access, Revisited” by Matthias Zöchling — a shot post inspired by a Mastodon post by Miriam Suzanne about the differences between accent-color and accentColor.

There were also a few articles about Tailwind and utility-first approach last week, but I don’t want to share them as is without providing my own opinion alongside, and I didn’t have an opportunity to fully work on it.

One thing, as a semi-spoiler for it: look at the above list of articles people did write about CSS in a span of a week, and think about how many things described in them are possible to achieve with today’s utility-first approaches.

Let me know what you think about this on Mastodon!

Weekly Bookmarks 13

Mon, 26 Feb 2024 00:00:00 GMT

Current music:: toe — The World According To
Current drink:: Yunnan tea

As usual, a few articles about CSS that I found interesting this week, nine of them.

“Proposal: CSS Variable Groups” by Lea Verou — a proposal and an associated CSSWG issue about an ability to have something similar to maps or arrays in native CSS. I wanted to have something like this for years, and I truly hope that this will lead to something!
“Okay, Color Spaces” by Eric Portis — a very comprehensive article about the color spaces which makes it easy to understand how they work and what are the differences between them.
“CSS :has() Interactive Guide” by Ahmad Shadeed — a detailed article with many interactive examples about what :has() pseudo-class is, and many of its use cases.
“Using container size and style queries” by Estelle Weyl — an MDN guide about container queries (both size and style ones).
“View transitions: Handling aspect ratio changes” by Jake Archibald — a post explaning how we can improve or fix view transitions in complex cases by separating the transitions to happen on multiple elements.
“Speedier tunes” by Jeremy Keith — a short post about how content-visibility can improve performance when rendering lists with complex elements (in this case, with SVGs inside).
“Changes to CSS ::backdrop inheritance” by Bramus — a post about the recent update to the ::backdrop, allowing it to inherit styles from the originating element.
“A practical guide to using shadow DOM” by Mayank — a post explaining what shadow DOM is, with a focus on the declarative shadow DOM which is now available in all major browsers.
“Declarative Custom Elements Should Take Inspiration From CSS” by Nathan Knowler — a post outlining an idea to use a CSS-like syntax for re-binding HTML attributes declaratively. It did remind me of Cascading Attribute Sheets proposal by Tab Atkins-Bittner, though I doubt we will get anything like that anytime soon.

Let me know what you think about this on Mastodon!

Two Invitations

Sat, 09 Mar 2024 00:00:00 GMT

Current music:: S — wait
Current drink:: Cinnamon Tea

In the last few weeks, I received two invitations:

An invitation to speak at the next CSS Day.
An invitation to join the CSS Working Group as an Invited Expert.

Of course, I did accept both of them:

I’ll give a talk titled “Impactful Experimentation” at CSS Day in June.
You can now find me on the CSSWG “Participants” page.

I still do not entirely believe this did happen.

I guess, I need to push my impostor syndrome away for a bit and accept that maybe after 17+ years of writing CSS as a full-time job, experimenting with it in my spare time, sharing the findings on my site, and my more recent activity in CSSWG issues did bring some fruits.

I did already participate in one weekly CSSWG meeting, and started working on the rought outline of my talk. In CSSWG I’m mostly observing how things work for now, and I’m mostly planning on continuing doing what I’m doing: keeping an eye on the emerging specs, authors’ requests, playing with the existing prototypes of the newer specs like I did with anchor positioning, and give my feedback on all of this.

Let’s see where all of this will lead next!

Let me know what you think about this on Mastodon!

Weekly Bookmarks 14

Tue, 05 Mar 2024 00:00:00 GMT

Current music:: Exist Strategy — Broken Air
Current drink:: Yunnan tea

A bit later than usual, but I did finally read all the articles and posts about CSS that I bookmarked in the last week.

“Modern CSS Tooltips And Speech Bubbles (Part 1)” by Temani Afif — an article about a technique to implement tooltips with border-image and clip-path (and a bunch of math). I wish there was some native way to do some of this (maybe I should come up with a proposal for this or something).
“Going beyond pixels and (r)ems in CSS - Container query length units” by Brecht De Ruyte — a practical article about using container query length units.
“The New CSS Math: pi and other constants” by Daniel C. Wilson — an article about the new math constants: pi, e, infinity, and even NaN.
“CSS Foundations: What is IACVT?” by Bramus — a post explaining what “Invalid At Computed Value Time” is in CSS. A good read in case you want to understand how things work on a more foundational level.
“Case Study: lynnandtonic.com 2023 refresh” by Lynn Fisher — a detailed case study about another annual Lynn’s redesign of her website. A lot of ResizeObserver usage, CSS variables, and nice tiny details.
“Retrofitting fluid typography” by Richard Rutter — a case study of using utopia.fyi to implement fluid typography with custom CSS properties.
“Menus, toasts and more with the Popover API, the dialog element, invokers, anchor positioning and @starting-style” by Ollie Williams — an article about all the new features we will have in the future to work with popovers and dialogs which outlines many aspects we need to consider when implementing them.
“The value of live web design” by Chen Hui Jing — a post about designing live in the browser, and a list of CSS properties that might be helpful to learn and apply when doing it.
“CSS-only bottom-anchored scrolling area” by Kitty Giraudel — a short post about two ways of making scrolling containers start from bottom. One of them was new to me: I did not know that using flex-direction: column-reverse did work like that!
“An HTML Switch Control” by Anne van Kesteren and Jon Davis — a post about the new switch control introduced in Safari 17.4.

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 15

Thu, 04 Apr 2024 00:00:00 GMT

Current music:: Follow The Compass — Mountains
Current drink:: Yunnan tea

First things first

I think it is obvious that the “weekly” format just doesn’t work for me: sometimes there are gaps, I don’t want to always publish on the same day, and so on. Moreover, I ended up sharing predominantly the more recent articles and posts I read, rather than some of the more archived ones, so replacing the “weekly” with “recent” makes sense.
While it was a month since the last bookmarks post, I don’t want it to be monthly, but something that I post more often.
Almost always, my bookmarks are all about CSS. This will continue, and it should be ok to just put this into the “series” name. I could still include other topics, but the main topic will be CSS. And for bigger compilations like this one, I could always add sub-categories.
Some other people have a separate category on their sites where they share bookmarks one by one, or automatically publish groups of them. For me, at least for now, it is more enjoyable to have a more curated list in the way I’m doing it. Maybe I will do something differently in the future, we’ll see.

Now, to the bookmarks themselves, 23 of them this time.

Colors and Themes

I gathered four links about colors and themes that compliment each other.

“Using relative colors” by Chris Mills — a new MDN guide to relative colors in CSS, which are currently available in Chrome and Safari, but not in Firefox.
“Creating color palettes with the CSS color-mix() function” by Michelle Barker — in contrast to the previous guide, this article is about color-mix() which is newly available in all major browsers for around a year already.
“CSS color-scheme-dependent colors with light-dark()” by Bramus — a post about two ways to handle light and dark colors: via Canvas and CanvasText keywords, and via a light-dark() function.
“Setting And Persisting Color Scheme Preferences With CSS And A ‘Touch’ Of JavaScript” by Henry Bley-Vroman — an article about using :has() for :checked <select>’s <option>s as a way to change the page’s color scheme.

Container Queries

All aspects of them, including container query length units and style queries!

“An Interactive Guide to CSS Container Queries” by Ahmad Shadeed — a detailed article about the basics of container queries with many interactive examples. And multiple non-card use cases! I particularly liked one timeline example that combines a regular container query with a style query applied via a :has() quantity selector.
“Add Superpowers to Your CSS Variables with Style Queries” by Jared White — a post about one use case for container style queries, where we could use them for reusable media query values, among other things.
“Algorithmic Functional CSS” by Nathan Knowler — a post about using algorithms that let the browsers provide inputs to them, with an example of a dynamic spacing scale based on container query length units.

Accessibility

A few articles about various aspects of CSS in relation to accessibility.

“On popover accessibility: what the browser does and doesn’t do” by Hidde de Vries and Scott O’Hara — an article about the ways Popover API interacts with accessibility of the popovers and their associated buttons.
“The problem with data-attributes for text effects” by Mandy Michael — a post advising against using content property with attr() to get a duplicated text due to potential accessibility issues.
“You Want border-color: transparent, Not border: none” by Dave Rupert — a post about an important aspect of styling borders (or absence of them) accessibly with the forced-colors mode in mind.
“The Case for Defining Base Font-size” by Mike Mai — a post about not using absolute units for the font-size on the root of your document, and a way to ensure this with CSS layers.

Grids

Ok, just two articles, but I just wanted to have a section for them. Grids are cool.

“Building a Rock Solid Auto Grid” by Nils Binder — an article that goes step-by-step over a creation of a customizable grid, combining multiple CSS grid aspects.
“Making room for long list markers with subgrid” by Noah Liebman — a post about how we can use subgrids to style lists in a way that will accommodate markers of any length.

Future CSS

Things that are not available in all browsers, but, hopefully, will be soon. Some of them could be used as a progressive enhancement, some of them — not.

“What You Need to Know about Modern CSS (Spring 2024 Edition)” by Chris Coyier — while this compilation contains some things that are newly available in all major browsers today, many of these can be still tricky to use in production. Overall, a good summary of what CSS will allow us to do in the future.
“Steal this popover code” by Adam Argyle — a post about a way to animate the entry and exit states of a popover via discrete display and overlay transitions, as well as a @starting-style rule.
“How to Kill the Cascade” by Robin Rendle — an article describing one way to isolate the styles of some element in the light DOM by using an implicit @scope and all: revert-layer.
“Animating clip paths on scroll with @property in CSS” by Brecht De Ruyte — an article about using scroll-driven animations for complex clip-path() that use multiple CSS variables.

Everything Else

These cover so many topics! I could probably spend more time thinking about how I could put these into different boxes as well, but oh well!

“Modern CSS Tooltips And Speech Bubbles (Part 2)” by Temani Afif — a continuation of the article about doing speech bubbles with border-image and clip-path, this time making things more complicating as a way to solve having a border on the tooltips that goes continuously around the tooltip’s tip, solves via pseudo-elements and some math.
“Some little ways I’m using CSS :has() in the real world” by Andy Bell — a post with several examples of how :has() can be used to solve various practical problems.
“CSS Button Styles You Might Not Know” by David Bushell — a post about a few not very common things that can be used to adjust the button styles.
“Creating 3x5.pics” by Anne Sturdivant — a case study for a specific index card blog design, using properties as aspect-ratio, text-orientation among more regular flex and grids, and describing the thought process behind some design and tech decisions.
[email protected]/112138741731168637">“Pure CSS element distortion (flattened 3D skew with matrix3d())” by Ana Tudor — a StackOverflow answer and a CodePen demonstration of a way to get a trapezoid transformation for an element by using a flattened 3D transform.
“aspect-ratio Gotcha!” by Matthias Zöchling — a blog post about aspect-ratio in relation to images, and one aspect of it related to their dimensions explicitly set in the HTML attributes.

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 16

Sat, 18 May 2024 00:00:00 GMT

Current music:: Every Gentle Air — The Sower
Current drink:: Sencha tea

Another big batch of CSS bookmarks: more than a month worth of them. As usual, with that number of them (32!), I grouped them into eight sections.

Colors and Themes

“On compliance vs readability: Generating text colors with CSS” by Lea Verou — a detailed article about a technique that uses the relative color syntax to approximate the future color-contrast() function.
“Recursion! In the stylesheet” by Noah Liebman — an article about how we can use color-mix() to retrieve some color from a specific point in any linear-gradient, using recursively nested color-mix() for more complex cases.
“What I’ve learned about CSS color-scheme and friends.” by Anne Sturdivant — a detailed post about how she did set up light and dark mode in her blogs.
“CSS Color Modules and Changes, Part I” by Anne Sturdivant — a compilation of information about various color features, new and old, with some thoughts around them.
“What if you had real control over Light Mode / Dark Mode on a per-site basis?” by Bramus — a post about the experimental Web Preferences API and a Chrome extension Bramus did create that allows to use this API to switch between themes on sites that support them. Hopefully, browsers will provide this natively — I too think that it is the job for the browser to provide controls for changing themes, similarly to how it provides control over the font-size and zoom.
“What’s Going On in Dark Theme / Light Theme Land” by Chris Coyier — a post with some thoughts and links (including those two above) about theming and scheming.

CSS Layouts

This month is full of talks about the future of CSS “Masonry” layout. There is a prototype implementation in Safari and Firefox, and an alternative proposal from the Chrome team. Both sides did post their posts presenting their arguments, and asking for the developer feedback in the CSSWG issues. It is a lot!

“Help us invent CSS Grid Level 3, aka ‘Masonry’ layout” by Jen Simmons — an article by the WebKit team, asking many questions, and providing multiple masonry use cases.
“An alternative proposal for CSS masonry” by Rachel Andrew — an article from Chrome’s team, explaining their alternative proposal.

Masonry was not the only layout-related topic in the last month, there were some other articles as well.

“Printing music with CSS Grid” by Stephen Band — an article about using CSS grids to create a layout for music sheets. I don’t agree with the choice of using data-attributes to pass data to CSS (inline styles and custom properties are a much better choice), but otherwise a nice approach to an unusual use case.
“Handling The Indentation of a Treeview Component” by Ahmad Shadeed — a post with an exploration of several implementations of nested tree lists, specifically, how spacing was done in them.

Typography

“Use CSS to boost the font size of emoji with no extra markup” by Terence Eden — a post about how we can modify some font parameters by applying a unicode-range to a @font-face, with an example of emoji fonts and changing their size while not affecting other typefaces.
“One line of CSS to make San Francisco more accessible” by Mike Mai — a post and a CodePen about how it is possible to apply stylistic alternates to a font (if it provides them) to make it more accessible. Only some fonts will provide this as an option, and there are some alternative ways to do the same mentioned in the thread.
“Are Web-Safe Fonts still relevant in 2024?” by Oliver Schöndorfer — a post about how the old concept of “web-safe fonts” cannot be applied today, especially due to which fonts are available on the popular mobile platforms.
“‘Multiplexed’ Fonts Have a Cool Superpower” by Chris Coyier — a post about multiplexed fonts and how they can be used in places where we could want some dynamic font feature’s change not result in a layout change.
“Fluid Design with CSS Round” by George Francis — a post about one use-case for a round() function for a dynamic line-height that conforms to a certain grid.

Future CSS

“Time-based CSS Animations” by Yuan Chuan — an article about how we could use transitions on the registered custom properties to create a timer which could be used as the source for transitions and animations. @property is almost here, and with it so many of different techniques, including this one!
“Introducing the CSS anchor positioning API” by Una Kravets — a detailed article about anchor positioning in the state it is shipping in Chrome 125.

Selectors

“Combining CSS :has() And HTML <select> For Greater Conditional Styling” by Amit Sheen — an article about how we can style things based on the value of some select using the :has() and other selectors in combination with it.
“Testing HTML With Modern CSS” by Heydon Pickering — a post about how we can use complex CSS selectors to visually highlight various issues in HTML.
“How would you build Wordle with just HTML & CSS?” by Scott Jehl — a post presenting one way we could use form validation selectors to approach building a Wordle clone.
“Misconceptions about CSS Specificity” by Bramus — a post explaining a few things people often misunderstand in relation to specificity.
“Superior Range Syntax” by Matthias Zöchling — a post about how the new syntax for container and media queries allows for more precise and reliable comparisons.

Shapes and Effects

“The Modern Guide For Making CSS Shapes” by Temani Afif — an article with an impressive collection of different shapes and descriptions of how to achieve them in CSS, including many useful tricks and explanations for some of the trigonometry that frequently goes with them.
“CSS Tricks To Master The clip-path Property” by Temani Afif — an article presenting one good way to approach the clip-path’s polygon() value by always starting from a rectangle.
“Things That Can Break aspect-ratio in CSS” by Chris Coyier — a post with an overview of different things that could “break” the aspect-ratio property’s effect in CSS.
[email protected]/112401133828751625">“Pure CSS halftone effect in 3 declarations” by Ana Tudor — a thread about a technique to achieve the halftone effect by overlaying gradients and using a contrast filter on them, with multiple live examples.

Everything Else

“Your page can’t change media features” by Kilian Valkhof — a post about one important aspect of how media queries work, and how the page itself will never change them (yet).
“The slow death of CSS vendor prefixes” by Ollie Williams — a post about how even though modern browsers stopped introducing new prefixes for properties and values, some of them are still necessary for achieving some effects that do not yet have a more standard implementation.
“Chill Scroll Snapping: Article Headers” by Chris Coyier — a post about an idea to use scroll-snap for snapping headers. Not sure the mandatory is the best choice there, but I can see a case for optional snapping in some designs.

My Articles

I did publish three articles on my main site in April:

“Layered Toggles: Optional CSS Mixins” — an article about a technique where we can use @layer, rever-layer and cyclic toggles to create reusable CSS mixins.
“Alternating Style Queries” — an article about a technique using container style queries that allows us to alternate some styles based on their nesting.
“Self-Modifying Variables: the inherit() Workaround” — an article with a technique based on the one described in the previous article that allows us to use style queries as a way to implement something similar to the inherit() function.

If you did miss any of them, I highly recommend you to check them out.

Let me know what you think about this on Mastodon!

Custom Properties and CSS-Wide Keywords

Wed, 19 Jun 2024 00:00:00 GMT

Current music:: Husking Bee — カナリア
Current drink:: Yunnan tea

Introduction

Recently, my blog feels a bit lonely and sad, I need to write more things that are not “Recent CSS Bookmarks” (although, I need to get to the next post of those).

What I want to try (will it work? Who knows!) is to write about things I do more. I did some of that during the last November, but then kinda burnt out on writing so much. Let’s try not to make a schedule out of this, but just write about things that, I think, could be interesting. Here is what I did at the beginning of this week!

I did some tests with custom properties in CSS, and how they work (or don’t) with the CSS-Wide Keywords (initial, inherit and unset, revert and revert-layer).

The Specs

I invite you to read all the related specs yourself, but I will note a few things related to what I tested:

In theory, there should be no difference if we use a CSS-wide keyword for a regular property, or for a custom one. Here is a quote from the css-variables spec:

The CSS-wide keywords can be used in custom properties, with the same meaning as in any another property.
The note right after this paragraph points towards one important aspect: how we cannot really pass down such keyword through a custom property — it will be applied when the custom property will be defined:

Note: That is, they’re interpreted at cascaded-value time as normal, and are not preserved as the custom property’s value, and thus are not substituted in by the corresponding variable.
The only way we could apply such a keyword conditionally is via the fallback value of a var(). Here is how the spec defines it:

If a declaration, once all var() functions are substituted in, contains only a CSS-wide keyword (and possibly whitespace), its value is determined as if that keyword were its specified value all along.

It also provides an example showing the fallback behavior (though with a less-useful initial value):
Example 14: While a var() function can’t get a CSS-wide keyword from the custom property itself—if you tried to specify that, like --foo: initial; , it would just trigger explicit defaulting for the custom property—it can have a CSS-wide keyword in its fallback:
```
p { color: var(--does-not-exist, initial); }
```

The Tests

Initially, I did my tests as a CodePen, but then when I saw the results, I decided to write some Web Platform Tests, and opened a PR adding them (and also fixed some minor test descriptions that I found when looking for existing tests).

Here is a summary of the results:

Chrome handles all the cases as expected and as specified.
Firefox failed in 5 out of 30 tests I wrote in WPT. I did open a bug about these in Mozilla’s Bugzilla. I did test in Firefox Nightly — in the current stable version of Firefox there are eleven failures, but as it does not support registered custom properties at all, this is expected (though there as a failure with a revert-layer fallback in an unregistered custom property as well). Notably, all the Nightly failures are related to registered custom properties.
Safari failed in 8 out of 30 tests I wrote in WPT. I did open a bug about these in WebKit’s Bugzilla. There was no difference between the stable version of Safari I tried and its latest Safari Technology Preview. Five of those tests were related to the fallbacks of the unregistered custom properties (basically, all CSS-wide keywords do not work there), and the rest were related to revert-layer.
If we were to count tests that succeed in all the latest versions of three major browsers, then it will be 19 out of 30 tests, with 11 total tests failing in at least one browser, two of them failing in both. So, the “Interop” score for this will be around 63%.

What Does It Mean?

Main thing: revert-layer is currently cross-browser only when used for non-registered custom properties directly, like --foo: revert-layer. This is still good news, as this means my “Layered Toggles: Optional CSS Mixins” technique works!
Fallbacks are very unreliable right now for CSS-wide keywords. However, we can use the unset, revert and inherit values, but only if we will register our variables with inherits: true. Doing so will make them work in Safari, and for stable Firefox it won’t make a difference, as those fallbacks work with unregistered properties anyway.
CSS-wide keywords apart from revert-layer work fine for non-registered custom properties, but that’s a rather obvious thing.

Overall, I hope browsers will fix the bugs they currently have, so we will unlock more of the use cases for both the revert-layer keyword, and for registered custom properties.

Some Context

In one of the CSS Working Group’s latest face-to-face meetings last week, we did resolve to start working on a native conditional if() function in CSS. I recommend reading the “Inline conditionals in CSS?” article by Lea Verou if you want to know about it, but an important part in relation to my tests is that as the result we’re focusing more on custom properties, as they will be a big part of those conditionals.

Lea did ask me to look into one weird issue with how fallbacks are applied, and as a result of it she did open an “Are fallbacks provided for registered properties validated by the CP syntax?” issue in CSSWG GitHub.

Most of my tests were in response to her inquiry (and partially continued some of my earlier tests for my Layered Toggles article).

A Future Technique

Initially, I wanted to open another CSSWG issue about adding some way to pass down the CSS-wide keywords and then somehow apply them in-place on either regular properties or on variables, as right now, it is not possible to do it.

However, thinking about it more, the if() could be a viable solution for this: instead of passing a CSS-wide keyword itself, we could pass some ident, like --revert-layer, and then use if() to apply it when necessary!

.foo {
    background: if(
        style(--foo: --revert-layer)
            ? revert-layer
            : var(--foo)
    );
}

A condition like this will check if the variable’s value is some dashed ident, and will apply the actual CSS-wide keyword in-place!

Of course, given all browsers will implement the CSS-wide keywords inside the conditions in the same way they should work with custom properties — and if they won’t, I will write some Web Platform Tests.

And you should try doing so too!

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 17: Layouts

Sun, 11 Aug 2024 00:00:00 GMT

Current music:: This is The Kit — Two Wooden Spoons
Current drink:: Sencha tea

Oops, more than three months without sharing bookmarks. My excuse: I spoke at CSS Day, and went to a CSS Working Group face-to-face in A Coruña, and then rested for a bit. And then the backlog of articles to read grew and grew, becoming unmanageable.

Instead of trying to go through the whole backlog in one go, I grouped all the bookmarks, and will post them group-by-group.

Today, it is all about layouts.

“Learn Grid Now, Container Queries Can Wait” by Miriam Suzanne — a call to start using CSS grids more, as they’re already available for quite a long time, and are very cool. Use them.
“The Gap” by Ahmad Shadeed — an article about the history of how we used margin property in the past, and how the gap property in flex and grid layouts eliminates many pain points of margins.
“CSS Grid Areas” by Ahmad Shadeed — a deep exploration of how grid areas work, with many interactive examples and use cases.
“Modern CSS Layouts: You Might Not Need A Framework For That” by Brecht De Ruyte — an article about four reusable and configurable layouts based on CSS flex and grid modules.
“Responsive bar charts in HTML and CSS” by Mathias Schäfer — a case-study of migrating a chart built with SVG to HTML&CSS as a way to make it responsive, with the help of a CSS grid layout, including using subgrids and logical properties.
“Absolute positioning with CSS grid” by Elaina Natario — a post about one useful aspect of CSS grids: an ability to place elements into overlapping areas, either fully reusing the same grid area, or create intersecting ones.
“In defense of asymmetric grids” by Robin Rendle — a short post about how CSS grids allow us to have any grids we want and not just a common 12-columns one (which is still effortless to do with them).
“Fluid Breakout Layout with CSS Grid” by Nathan Long — an article about how we can set up a complex grid with many defined grid lines that allow us to create complex breakout layouts. It defines the lines using grid-template-columns, which, in my opinion, is a bit cumbersome, so I invite you to also look at my old “Grid Projection Naming” article about how we can use grid-template-areas to simplify this.
“Yet another take on layout breakouts” by Noah Liebman — a post about another way to do simple breakout layouts by using negative margins and max-inline-size.
“Request for developer feedback on reading-flow and elements with display: contents” by Rachel Andrew — a post about the property previously drafted as reading-order-items, its current status and a call for feedback over how it should work with display: contents.
“Let’s make a floating button sign up form pattern” by Andy Bell — a case study of creating a micro-layout for an input+button pattern, going into numerous nuances related to accessibility and responsiveness related to it.
“Fit-to-Width Text: A New Technique” by me — while it is not really about layouts, this technique uses flexbox inside, as a workaround for not being able to apply container query to an element with an intrinsic width.

If I missed something you wrote, or if you saw something else about CSS layouts that I did omit, but you found interesting, — you are always welcome to send links my way.

Let me know what you think about this on Mastodon!

Querying the Color Scheme

Thu, 29 Aug 2024 00:00:00 GMT

Current music:: The Album Leaf — Dust Collects
Current drink:: Lemongrass, Ginger & Black Pepper tea

Introduction

Media queries are nice: they allow us to query different features, like the prefers-color-scheme one, which allows us to get the user preference and switch some styles between light and dark themes.

For many things, we don’t even need the media queries themselves: there is this great CSS property color-scheme. If we set it on the root like this:

:root {
    color-scheme: light dark;
}

Many things in our page will automatically adapt to the user’s color-scheme:

Built-in UI elements: scrollbars, inputs, buttons.
Some system colors: for example, Canvas and CanvasText.
The built-in light-dark() function, which accepts two colors and returns the first one when the theme is light, and the second one otherwise.

Adapting to the User Preference

By providing both possible schemes: “light dark” to the color-scheme, we tell the browser that it is ok to adapt to one of those themes that matches the user preference. The example below should adapt to the color-scheme you’re using in your browser:

Component is not available in RSS, visit the the site to access it.

.example1 {
    color-scheme: light dark;

    & p {
        padding: 1em;
        background: Canvas;
        color: CanvasText;
        border: 2px solid light-dark(hotpink, pink);
    }

    @media (prefers-color-scheme: light) {
        .dark-only {
            display: none;
        }
    }
    @media (prefers-color-scheme: dark) {
        .light-only {
            display: none;
        }
    }
}

<div class="example1">
    <p>I should adapt. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
</div>

We can see how everything — the light-dark(), the Canvas & CanvasText and the media queries — adapts to the current scheme.

Enforcing a `color-scheme`

But what if we will set only one value?

Component is not available in RSS, visit the the site to access it.

.example2--light {
    &,
    & *  {
        color-scheme: light;
    }
}

.example2--dark {
    &,
    & *  {
        color-scheme: dark;
    }
}

.example2 {
    & p {
        padding: 1em;
        background: Canvas;
        color: CanvasText;
        border: 2px solid light-dark(hotpink, pink);
    }

    @media (prefers-color-scheme: light) {
        .dark-only {
            display: none;
        }
    }
    @media (prefers-color-scheme: dark) {
        .light-only {
            display: none;
        }
    }
}

<div class="example2 example2--light">
    <p>I should be always light. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
</div>
<div class="example2 example2--dark">
    <p>I should be always dark. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
</div>

While system colors and light-dark() applied according to our color-scheme, we can’t change the media query from our CSS. It just tells us what is the user preference.

The light-dark() itself is very useful, but can only be used for things that expect an actual CSS <color> type. But what if we’d want to adapt other, non-color things?

We can work around this by using something different as the source of truth, like CSS scopes or style queries. I recommend reading the recent “Page and Component Adaptive Light/Dark” post by Adam Argyle about these.

But what if we’d want to use the color-scheme as the source of truth?

Single Source of Truth

With the style queries and registered custom properties, we could! Here is how:

Component is not available in RSS, visit the the site to access it.

.example3--light {
    color-scheme: light;
}

.example3--dark {
    color-scheme: dark;
}

@property --captured-color {
    syntax: "<color>";
    inherits: true;
    initial-value: white;
}

.example3 {
    --captured-color: light-dark(white, black);

    & p {
        padding: 1em;
        background: Canvas;
        color: CanvasText;
        border: 2px solid light-dark(hotpink, pink);
    }

    @container style(--captured-color: white) {
        .dark-only {
            display: none;
        }
    }
    @container style(--captured-color: black) {
        .light-only {
            display: none;
        }
    }
}

<div class="example3 example3--light">
    <p>I should be always light. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
</div>
<div class="example3 example3--dark">
    <p>I should be always dark. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
</div>

Here, instead of using media queries, we register a --captured-color custom property, then assign two different values to it using the light-dark() function. Because the property is registered, the function is properly applied, resulting in the corresponding color changing based on the color-scheme.

Then, instead of relying on the prefers-color-scheme, we use a container style query to query this registered custom property, which allows us setting any properties for anything inside the element that defines the color-scheme!

Downsides

The main downside of this method (outside the browser support) is the fact that the style queries apply to the elements inside the element with the color-scheme, but the color-scheme changes the styles on the element itself. Unless we’ll get some way to conditionally apply styles on the element itself, we will need to make sure we never style anything on the element with the color-scheme.

And, of course, it is not as intuitive with the container style queries targeting some variable with some abstract values.

Not the User Preference

In the most recent “Web-Standards podcast” (in Russian), Vadim Makeev mentioned a good point: there is a big difference between the user preference and a color-scheme property. Occasionally, it might be alluring to use the color-scheme as a switch for the components’ theme, but we need to consider that even when we do so, we could still want to listen to the prefers-color-scheme to understand which theme the user prefers, and make adjustments to both the light and dark themes we’re applying via color-scheme.

For example, if the user prefers the dark color-scheme, and we’re overriding it to light on some inner component, we could want to not just invert the colors there, but also make them not as bright, as in not to make it stand out too much. We might even want to adjust the overall theme based on it if we have the built-in color scheme switch: dim the light one when the user prefers the dark color scheme, and make the dark more contrast if the user has it as light, as otherwise UI elements could be overshined by the bright browser chrome.

The Future

I did not find a dedicated issue about this yet, but in one of the other issues about color-scheme many people did express their desire to have a dedicated style query for this. I imagine it will work very similarly, and potentially have the same downside of not matching with the color-scheme, unless there will be some specific handling implemented that will prevent any circular dependency issues.

The abovementioned issue itself is about the problem where a <meta name=color-scheme> in HTML does not reflect on the prefers-color-scheme @media. In my opinion, this is the way it should work: I think the user preferences should stay that way, and it is not correct to change it based on the current color scheme, regardless of where it is defined — in HTML or CSS.

This technique (or a potential style query) will solve the issue described in the issue well enough: just apply it on the html or body element and use it instead of the @media itself.

Conclusion

Registered custom properties are powerful in their ability to capture some value on the element itself, rather than passing it down to be applied later. I got the idea to apply it to the light-dark() function when playing with the tan(atan2()) technique as a part of my experiments for the “Fit-to-Width Text: A New Technique” article, and after playing with the style queries for my “Self-Modifying Variables: the inherit() Workaround” article.

As always, I am fascinated by what we can achieve by combining different CSS features: in this case we rely on three of them together. I hope this post will encourage you to experiment with all the new things in CSS as well, and will give you ideas about how we could use them in other unusual ways.

Let me know what you think about this on Mastodon!

Captured Custom Properties

Mon, 02 Sep 2024 00:00:00 GMT

Current music:: toe — 風と記憶
Current drink:: Yunnan tea

Introduction

In a few of my latest experiments and articles (“Fit-to-Width Text: A New Technique” and “Querying the Color Scheme”), I used one naming pattern for registered custom properties that I think worth highlighting in a separate blog post.

Registered custom properties are invaluable, as they unlock many things previously not possible.

Among other use cases (I recommend reading the Providing Type Definitions for CSS with @property article by Stephanie Eckles), there are two useful effects we can use registered custom properties for:

Enabling animations of some custom property.
Capturing the value of the custom property on the element itself.

The use case for animations is rather obvious, but the capturing one can be harder to wrap your head around.

Regular Custom Properties

By default, regular custom properties have their computed value as “specified value with variables substituted”. The serialization rules for custom properties state:

Custom property names must be serialized as the exact code point sequence provided by the author, including not altering the case.

Specified values of custom properties must be serialized exactly as specified by the author. Simplifications that might occur in other properties, such as dropping comments, normalizing whitespace, reserializing numeric tokens from their value, etc., must not occur.

Computed values of custom properties must similarly be serialized exactly as specified by the author, save for the replacement of any var() functions.

So, when we define some custom property, the only thing that happens is the substitution of variables inside. But the actual values will be evaluated only when used on particular elements.

Here is a simple example:

Component is not available in RSS, visit the the site to access it.

.example1 {
    font-size: 0.666em;
    --font-size: 1.5em;

    & span {
        font-size: var(--font-size);
    }
    & .inner {
        font-size: 2em;
    }
}

<div class="example1">
    <em>Outer:</em> <span>Foo</span>
    <div class="inner">
        <em>Inner:</em> <span>Bar</span>
    </div>
</div>

Here we can see how we define the --font-size on the wrapper, and then use it on different children. One <span> is placed right inside our wrapper, but another have an .inner wrapper that changes the font-size to be bigger.

The 1.5em from the --font-size custom property is evaluated on the <span> itself. When it is defined, it does not calculate the em inside, and just passes the value as a code sequence to be applied when it will be used.

Let’s see what will happen if we will register a custom property.

Registered Custom Properties

The only difference in this example is that we register our custom property, note the font-size of the .inner > span element compared to the regular custom property example.

Component is not available in RSS, visit the the site to access it.

@property --registered-font-size {
    syntax: "<length>";
    initial-value: 0px;
    inherits: true;
}

.example2 {
    font-size: 0.666em;
    --registered-font-size: 1.5em;

    & span {
        font-size: var(--registered-font-size);
    }
    & .inner {
        font-size: 2em;
    }
}

<div class="example2">
    <em>Outer:</em> <span>Foo</span>
    <div class="inner">
        <em>Inner:</em> <span>Bar</span>
    </div>
</div>

By registering our custom property, the value is now evaluated at the definition, so instead of passing down the abstract 1.5em, we now pass down the exact value of the 1.5em as calculated on the .example2 element!

This is defined in the spec for the registered custom properties, in a “Computed Value-Time Behavior”.

Many other things will be evaluated in the same way, like almost any calculations (they can’t involve a percentage) or colors. And, as we will see from the use cases, this can be useful not only when using the inheritance.

The Naming Pattern

In the above example, I named the custom property --registered-font-size. But is it the best way to name this property? Naming it based on the property it is used for does limit how we can use it. What if we could make it more generic?

In my latest experiments, what I ended up doing is creating a reusable registered custom property, at least one per type.

In this case, the custom property is responsible for capturing the <length> value, so a better name could be --captured-length:

@property --captured-length {
    syntax: "<length>";
    initial-value: 0px;
    inherits: true;
}

And if we’d want to capture a color, then it would be --captured-color. Integer? --captured-integer, and so on.

In my practice (see the use cases), most cases require having just a single registered custom property per type on an element. By having a generic reusable property, we make it much easier for us to work with the styles: we no longer need to register many custom properties with the same syntaxes and different names, most of which won’t be used at the same time.

Multiple Instances

But edge cases exist: what if we’d want to capture not one <length> on an element, but multiples of them?

My solution for this is simple: just introduce another registered custom property like --captured-length2.

Of course, this will only work if you control all the styles for your project, as well as the way they’re applied. When designing independent components, we’d want to prefix these names with something related to the component itself, but I still think the best way to name these custom properties is by what they do.

Do We Need Inheritance?

As a matter of habit, I was using inherits: true for these, but I was thinking for a while if we really need to do so.

A recent video “Turning off inheritance on custom props is more useful than I’d thought” by Kevin Powell did remind me of this, and, in our case, I think we can safely make these custom properties non-inheritable.

In the example with the --registered-font-size we had inherits as true because we were using that value on a nested element, inheriting it there. But we can work around this. Here is the same example, but using a non-inheriting --captured-length custom property:

Component is not available in RSS, visit the the site to access it.

@property --captured-length {
    syntax: "<length>";
    initial-value: 0px;
    inherits: false;
}

.example3 {
    font-size: 0.666em;
    --captured-length: 1.5em;
    --example-font-size: var(--captured-length);

    & span {
        font-size: var(--example-font-size);
    }
    & .inner {
        font-size: 2em;
    }
}

<div class="example3">
    <em>Outer:</em> <span>Foo</span>
    <div class="inner">
        <em>Inner:</em> <span>Bar</span>
    </div>
</div>

Here we are using the non-inheriting --captured-length as a way to retrieve the value, but then we save it to another, non-registered custom property that we are free to name as we want.

Because custom properties are replaced when serialized, the --example-font-size will get the computed value right away, and then will be inherited to the inner elements.

This feature allows us to use the same --captured-length property on different nested elements, saving its value into various other custom properties (or using right away), without the need for it to be inherited.

I am not sure if there is a big (if any) performance gain due to this, but I can see how the prevention of inheritance and requiring to save the value into a different custom property can be beneficial. It will reduce the potential confusion if any of the nested elements will be using the inherited --captured-length: where would it get from? A variable with a proper name will be more explicit and expressive.

Use Cases

In my “Fit-to-Width Text: A New Technique” article, I used this technique four times: --captured-length on three different elements, and also --captured-length2 for the optional case fixing the optical adjustment.

In my recent “Querying the Color Scheme” post, I used a single --captured-color custom property.

Interestingly, there were four different reasons across these five use cases, demonstrating how crucial this technique can be.

Detecting `@property` Support

For a more graceful fallback in my “Fit-to-Width Text: A New Technique” article, I use a variation of the “Feature detect CSS @property support” technique by Bramus, but instead of registering the --support-sentinel custom property, I reused the --captured-length one:

.text-fit {
    --captured-length: initial;
    --support-sentinel: var(--captured-length, 9999px);
}

When the browser supports @property, the --captured-length will be registered with the initial-value equal to 0px, making the --support-sentinel get that value.

But if the browser does not support it, the --support-sentinel would get the value from its provided fallback — 9999px.

Named Container Query Length Units Workaround

In the same article, I used the --captured-length to store the value in container query length units, as I wanted to have two different nested containers, and thus couldn’t access the outer one from within:

.text-fit {
    container-type: inline-size;

    & > :not([aria-hidden]) {
        container-type: inline-size;
        --captured-length: 100cqi;
        --available-space: var(--captured-length);

        & > * {
            /* Also using the 100cqi */
        }
    }
}

In the future, we will have a way to access the container query length units from any named container, see the “Reference named containers for cq units” issue by Una Kravets, but if we’d want to get them today, then registered custom properties do the job! I actually presented this use case in the comments to this issue in March 2023, though at the time the browser support for registered custom properties was worse, so I did not write about it elsewhere.

If you’re using container query length units often — take a note of this workaround, as you could find many use cases where it could be helpful.

Working Around Type Limitations

The third time I used the --captured-length in the same article was to also assign 100cqi to it — but for an entirely different reason.

Instead of capturing the value to pass it to the descendant element, I used it as a workaround for the tan(atan2()) technique’s issue: at least in Chrome, we cannot use container query length units directly inside the tan(atan2()) for some reason.

So, to use the 100cqi there, we first had to convert it to what tan(atan2()) would understand, which allowed us to calculate the ratio based on it and the --available-space value which we inherited:

.text-fit {
    & > :not([aria-hidden]) {
        --captured-length: 100cqi;
        --available-space: var(--captured-length);

        & > * {
            --captured-length: 100cqi;
            --ratio: tan(atan2(
                var(--available-space),
                var(--available-space) - var(--captured-length)
            ));
        }
    }
}

This example demonstrates how useful it is to have a generic registered custom property: it is used for different purposes, and we didn’t have to register it several times. The second time we used it, we also did not have to name it, as we could use it directly.

The last usage in the same article was also for working around the type limitations when assigning a value to the font-variation-settings property, for which we also had to use the tan(atan2()) technique:

.text-fit {
    & > :not([aria-hidden]) {
        & > * {
            --captured-length: 100cqi;
            /* … */
            --font-size: clamp(
                1em,
                1em * var(--ratio),
                var(--max-font-size, infinity * 1px)
                -
                var(--support-sentinel)
            );

            &.text-fit {
                --captured-length2: var(--font-size);
                font-variation-settings:
                    'opsz'
                    tan(atan2(var(--captured-length2), 1px));
            }
        }
    }
}

Here we had to use it on the same element, so we had to introduce the --captured-length2 property, and we could also use the value directly, without the name to inherit it or rename.

There are many other similar use cases, where we can use a registered custom property to overcome the typing limitations. Knowing how to solve them effectively allows us to use this powerful tan(atan2()) technique, so I will highly recommend you to read the original article about it by Jane Ori — “CSS Type Casting to Numeric: tan(atan2()) Scalars”. She also mentions this usage of registered custom properties in her article, but without creating a pattern out of it.

Unlocking Style Queries

The last use case is from my other post — “Querying the Color Scheme”.

This time, I am defining a --captured-color as a way to convert the value returned by light-dark() function to something a container style query could accept:

@property --captured-color {
    syntax: "<color>";
    inherits: true;
    initial-value: white;
}

.example3 {
    --captured-color: light-dark(white, black);

    @container style(--captured-color: white) {
        /* … */
    }
    @container style(--captured-color: black) {
        /* … */
    }
}

Although, in this case I did not rename the property, which could’ve been better (although, a bit more awkward: instead of comparing to the values of white and black, we would need to compare to rgb(255, 255, 255) and rgb(0, 0, 0) — the actual values the --captured-color will compute to).

This kind of value conversion could be useful in many other cases involving style queries, normalizing different values, or calculating their value, allowing us to compare the computed values rather than strings of tokens.

Other Use Cases

There might be many other use cases for this feature of registered custom properties, and for this technique, and I think I saw it in several recent articles, but can’t remember where exactly. If you’d know of any — throw them my way!

One other potential use case (which I did not try) could be to have another set of generic custom properties for animatable values. So, --animatable-length, --animatable-color and so on, allowing to create reusable @keyframes with them. I did not yet do so, but I feel there is a potential to craft something like that.

Conclusion

I love custom properties, and I feel we’re only scratching the surface of what is possible with the registered version of them.

While we probably should not use them in production just yet (Firefox supports them only from version 128), if your use cases work well with graceful degradation, or if you want to experiment with them — I highly recommend you to do so.

I find myself reaching for this naming pattern more and more, and I hope you will find it useful as well. I can see a list of these registered custom properties be in the boilerplate for most of my future projects, and maybe libraries like Open Props by Adam Argyle would also eventually get something like them from the box.

Let me know what you think about this on Mastodon!

Some Plans

Fri, 01 Nov 2024 00:00:00 GMT

Current music:: This is The Kit — Inside Outside
Current drink:: Peppermint Tea

Guess what? It is November. Last year, I went all out and published one post a day for the full month.

On one hand, that was hard, and took its toll on me. On the other, I did publish a bunch of stuff that would usually stay in the drafts.

I don’t know if I will manage to do the same this month — but I want to try again.

What

One thing I would like to try to do: make this a bit more of a blog. A few months ago, I started writing down weekly notes at my work, and found it to be a good way to track what I did achieve.

And, as I look back, many of last November’s posts were also just that: documenting my bug reports, WPT tests, CSSWG issues.

I need to find a good workflow to document and post stuff like that, and maybe a bit more of personal things, like posting photos from the walks, sharing my favorite music, my setup, or just anything else.

Next Week

Next week I will attend two things:

beyond tellerrand conference in Berlin.
IndieWebCamp after it.

I already have many plans about what I want to do with my website and this blog, and having both of these events to think more about it feels convenient.

While I could only visit the first day of IndieWebCamp, I’ll try to hack on my website during my travel back for the second day.

Bookmarks

As it is often the case for me with periodic things: I tend to always drop them. Well, as I have written in the latest bookmarks post, the backlog of the bookmarks I gathered is unmanageable!

I’ll try to come up with a better workflow for it, one that would actually work for me.

With me giving up on posting the bookmarks weekly, and the need to write up one post a day in November, I could always share one or two bookmarks as the fallback.

Experiments

Is the backlog of my experiments and article drafts is as big as for my bookmarks? Well, maybe not that big, but I have many things brewing in my lab.

I even managed to finally publish “Possible Future CSS: Tree-Counting Functions and Random Values” — an article about some of my experiments that I started last year.

There is more in the works. Nothing is fast when each time I touch some code, a browser bug crawls out of it and crashes the party. Or the browser. Had two of these last month alone!

More Plans

Or, actually, fewer? After starting writing this post, I have so many things I want to share. But: I will have the whole month for it. Nice.

Let me know what you think about this on Mastodon!

Current Music

Sat, 02 Nov 2024 00:00:00 GMT

Current music:: Husking Bee — ハイブリッドニューモード
Current drink:: Peppermint Tea

If you have read any posts in this blog, you might’ve noticed the “Current music” field at the top. This is something I adopted back from when I was using LiveJournal. Some of the apps that allowed posting there supported a way to detect what is currently playing in your audio player (likely, Winamp). Or maybe there was even a last.fm integration?

Anyways, that was fun! When I started this blog, one of the reasons was because of the nostalgia for these times, and that’s why I added the “Current music” metadata field, and why I am filling it manually for every post I write here.

Until today, it was displayed just as a string. Today, I made it into a proper “category”: if I shared some artist more than once, its name will become a link to the list of all posts that share it. Why? Well, why not?

I already have some ideas over how I could improve this. For example, it would be nice for every artist who appears twice or more, to add some info over on their category page, with links to their official pages, bandcamps and whatnot.

So, yeah. I listen to a lot of music, of many genres, and I always wanted to share some of it a bit wider. This could be a good way to start doing so! And if you’re curious more about my tastes — feel free to peek over at my last.fm profile. I “scrobble” what I’m listening to for over 18 years now, wow.

This post’s “Current music”, if you’re curious, is from the band that I listened the most to when I started using last.fm in 2006. One member of this band sang the vocal parts for the main character in Beck anime — I found this band through it.

Let me know what you think about this on Mastodon!

Embedding Pixelfed, part 1

Sun, 03 Nov 2024 00:00:00 GMT

Current music:: tricot — E
Current drink:: Peppermint Tea

Introduction

One of the things I planned for the November: to not do a lot of coding on the weekends, and try to post more personal stuff, keeping more technical stuff for the weekdays.

Well, for today’s post I wanted to share some photos, and I started to wonder how I should do this. In the end, it will involve code, but today I was mostly doing some exploration and planning.

I already have a Pixelfed account, and I wondered if I want to implement some IndieWeb pattern like “Publish Elsewhere, Syndicate (to your) Own Site” or “Publish (on your) Own Site, Syndicate Elsewhere”.

In the end, I think I will go with neither: I don’t want to have automation just yet, but I still would like to reuse what I post to Pixelfed in one way or another.

My thought process: the photos are already uploaded to Pixelfed, alongside associated alt texts. I don’t need to duplicate the images to my site: I already have the source file locally and with a backup in the cloud. Can I just reuse some stuff from it by using its API, and build some kind of gallery locally as a part of my Astro blog?

I don’t have anything ready just yet, but I wanted to demonstrate my process a bit, by documenting what I did and what I am planning to do.

What I Already Did

One thing I want to do, if I can: hotlink the images from Pixelfed. I tested if it is possible: and, for now, it appears that it is. My blog won’t ever be that popular to make this an issue for my Pixelfed instance, and not having to duplicate the effort of storing the image in multiple places sounds good.
I looked into Pixelfed API to understand if I could work easily with it. Unlike Mastodon API, where many things are available without authorization, Pixelfed API requires providing a “Personal Access Token” with each request. So, I’ll probably need to have some env variable for this.

I tested if the API works by creating this token and requesting one of my posts’ data via its API, while providing the token. I did something like this and it worked:

fetch(`https://pixey.org/api/v1/statuses/${id}`, {
    method: 'get',
    headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${ACCESS_TOKEN}`,
    },
})

I definitely don’t want to access this API on the client side (due to this token requirement), and I don’t want to call it that often while building the blog locally. That means that I need some kind of caching solution. Looking quickly if there is anything built-in in Astro (or a plugin), I did not find anything aside from a few issues about it (like “astro: cache core component”). I’ll probably implement the caching solution from scratch: it should be trivial enough.

Plans

Implement a way to store and use the API token as an environment variable. I don’t think I want to provide it in the CI, as I am planning to always just build things locally, even though Netlify which I am using allows doing this easily.
Implement a wrapper around the Pixelfed API that would cache all the necessary data I need to cache. It should be trivial enough:
1. Check if I already have a cached .json, if so, just use it.
2. If there is no such cache yet, call the API, get all the data from it, store it as a file near the source page. I will add this cached info to source control: this will be a good way to back up at least some info, like the alt texts etc, making the content more independent of Pixelfed.
3. That’s it?
Create an Astro component that would render an image with its alt in some way. I’ll need to come up with the design for it first, though.
I’ll likely want to include multiple images from multiple Pixelfed posts on one page, so I’ll need to also come up with a design for the gallery. And think if I need a separate whole category in my blog for this, or make it just a part of regular posts?

Just Starting

Aside from some experimental code to try out the API, I did not write any code for this. But I already started thinking about it, and planning what I want to do — a good first step.

I’ll continue working on this mini-project, and, hopefully, one day could start sharing my photos as a part of my blog (and backfill what I have published earlier in some form as well).

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 18: 12 Days of Web CFP, CSS Resets, and Selectors

Mon, 04 Nov 2024 00:00:00 GMT

Current music:: Helios — Coast Off
Current drink:: Ceylon tea

After a large gap, I am continuing reading and sharing the recent bookmarks I gathered. I’ll mostly go through more recent ones, but I’ll include one section with a few older ones as well.

The order in every section is from the older to newer articles. Sorry if I missed something you posted!

12 Days of Web CFP

Speaking of new articles. For the first bookmark, I wanted to highlight this year’s 12 Days of Web.

Stephanie Eckles opened a Call For Proposals, which will be open until November 10, with articles due by December 5.

I highly recommend participating (I did so last year). If you don’t yet know the topic you’d want to write about: the CFP has a list of them for you to choose from.

CSS Resets

It is always interesting to look at what other people consider their best “default” styles. Recently, many authors shared theirs. Interestingly, I do not use such a reset myself!

“Introducing TODS – a typographic and OpenType default stylesheet” by Richard Rutter — a detailed article about typography-focused CSS defaults, going through many OpenType features and proposing a better default value for some of them.
“How I Built ‘The Monospace Web’” by Oskar Wickström — a post with a few details about how the author built “The Monospace Web” exploration. It is not just a “reset”, but the main idea is very similar: to have some particular default styles for all elements.
“My Modern CSS Reset” by Jake Lazaroff — an article with an explanation of what and why goes into the author’s CSS reset, as well as what they put into a “classless framework”.
“You are not a CSS dev if you have not made a CSS reset” by Mike Mai — another post about a CSS reset, with an inflammatory title, and a few other opinionated bits.
“Your CSS reset should be layered” by Mayank — a post with a simple advice to put your reset into an @layer and a few arguments for doing so.

Many of these articles link to older articles by other authors about their resets, which could be a good read if you’re interested in reading even more about this topic.

Selectors

Continuing from CSS resets — one of the main aspects of which are selectors — I’ll also mention some bookmarks specifically about them. This section will contain a few “older” links from my backlog as well, as a way to try to manage its size.

“Ignore and acknowledge class attribute on elements in CSS” by Amit Merchant — a short post that names a concept of ignoring or acknowledging the presence of some attribute, like the [class] one.
“MacOS-like dock effect with a ‘previous-sibling combinator’” by Kevin Pennekamp — a post about how :has() selector allows us to select previous siblings with a dock-like effect as the example.
“CSS :has(), the God Selector” by Bruce Lawson — another post about how :has() could be used separately from the actual element we’re selecting, and how powerful this could be. If anyone remembers the “subject selector” — it was replaced with :has(), which is, indeed, much more versatile.
“CSS ‘Quantity Queries’ are a thing now” by Matt Fantinel — a post that looks at how we can now use :has() for quantity queries. (Term coined by Heydon Pickering.)
“Day 108: the of S syntax in :nth-child()” by Manuel Matuzović — a post that focuses on the optional selector argument of :nth-… pseudo-classes, which is a mighty new feature of them.
“Double your specificity with this one weird trick” by James Nash — a post about how multiple mentions of the same class selector in CSS still bumps up the rule’s specificity. While using the same class is a way to do so, in similar situations I prefer to use the before mentioned acknowledgement selector. So, .foo[class][class] instead of .foo.foo.foo. Although, with :where() and @layer, hacks like these, hopefully, will eventually go away.
“:nth-next-sibling? No need.” by Christopher Kirk-Nielsen — a post about a neat hack with the selector argument of a :nth-… family of pseudo-classes. I disagree with the title: the hack itself allows us to only select a finite span of elements, while a hypothetical :nth-next-sibling() would be able to select repeated sequences of them — something I explored in my “A Christmas Tree Selector: Prototyping the :nth-sibling() with CSS Nesting” post.
“I wasted a day on CSS selector performance to make a website load 2ms faster” by Trys Mudford — a post about how Chrome performance profiler’s “CSS selector stats” can only show the relative performance of selectors, with the actual numbers it will show being impacted by all the added instrumentation.
“Possible Future CSS: Tree-Counting Functions and Random Values” by me — while the topic itself is about future functions, the article focuses on the way we can prototype them today by using complex selectors, including those based on quantity queries. Speaking of selectors’ performance: my experiments in this article crashed Safari. We must be careful when using both :has() and native CSS nesting.
“Making content-aware components using CSS :has(), grid, and quantity queries” by Eric Bailey — a post about a real-life use case for quantity queries based on :has() for switching a position of some elements inside a CSS grid. In my opinion, ideally, for cases like this one, we’ll need something that would allow us to detect when things wrap in CSS, like what I prototyped with scroll-driven animations in my “Position-Driven Styles” article.
“Select the first occurrence of an element in the whole document” by Temani Afif — a clever trick that combines :has(), :nth-child(of …), and :not() pseudo-classes for selecting a first or last element similar to the way querySelector() does it in JS. Based on my experience, I’ll be a bit wary of its potential performance implications, especially in Safari, so if you try using it, test it extensively.

Let me know what you think about this on Mastodon!

Observation: Forced Wrapping

Tue, 05 Nov 2024 00:00:00 GMT

Current music:: Ling Tosite Sigure — キミトオク
Current drink:: Plain Water

Introduction

Back in August, I saw a Mastodon thread by Anne Sturdivant about how she was styling titles, in which she described a wish for a certain wrapping behavior:

I’m finding myself wanting a variant of text-wrap: balance where you can specify a minimum number of lines for the text to wrap so that it would never appear on one line without having to insert a <br> element.

Curiously enough, I remembered one interesting aspect of flexbox that could help to achieve what she wanted, and I shared it with her.

For quite a while, I wanted to write an “observation” post about it — and, finally, here we are! Maybe you’ll find it useful one day too.

The “Forced Wrapping” Technique

The code behind this technique is very short:

Component is not available in RSS, visit the the site to access it.

.forced-wrapping {
	display: flex;
	max-inline-size: max-content;

	&::after {
		content: "";
		flex-basis: 0.1px;
	}
}

<div class="example">
	<h3 class="forced-wrapping">Hello!</h3>
	<h3 class="forced-wrapping">Some Title</h3>
	<h3 class="forced-wrapping">And a Much Longer Title With Many Words That Would Wrap Anyway</h3>
</div>

Yep, that’s just four declarations, with one for adding a pseudo-element!

display: flex — first, we must make our element a flex container.
max-inline-size: max-content — then, we need to tell our element that it should size itself in the inline axis based on the maximum intrinsic size of its content.
content: "" — we need a pseudo-element that will go after our text content. That could be an actual element, the main requirement is for it to go after the text. Otherwise, when the content wraps, it will take up the space at the beginning.
flex-basis: 0.1px — finally, we make this pseudo-element to have some tiny positive flex-basis value. I found values less than 0.1px to not work well with certain values of browser zoom, but 0.1px seems to work consistently across all browsers.

Why Does It Work?

So, what happens here? Let’s peek at some definitions. First, for max-inline-size: max-content:

The box’s “ideal” size in the inline axis. Usually the narrowest inline size it could take while fitting around its contents if none of the soft wrap opportunities within the box were taken.

In other words, if our text doesn’t wrap, and there is nothing else near it, our container will be sized to fit the text inside. Let’s look at two headers: one without the forced-wrapping class, and another with it:

Component is not available in RSS, visit the the site to access it.

<div class="example">
	<h3 style="max-inline-size: max-content">Some Title</h3>
	<h3 class="forced-wrapping">Some Title</h3>
</div>

You might’ve noticed from the initial example that the second title had an unusual width. In this second example, you can see why: that is the inner text’s max-content value!

If we now look at the “Flex Layout Algorithm”, specifically at the second step, “Line Length Determination”, we will find this:

if that dimension of the flex container is being sized under a min or max-content constraint, the available space in that dimension is that constraint

This means that the space available for all our flex items is calculated based on the max-content (in our case) before any of the flex properties will be applied. So, when we calculate that max-content, we only look at the original, non-flex dimensions of our elements, and our ::after is empty; thus it contributes 0px to the “max-content constraint”, with the actual text being the only real contributor.

The flex-basis on the pseudo-element enters the algorithm later. What happens next is that, with a positive value, it is subtracted from the available space from our text’s anonymous box. From the flex-basis description:

This component sets the flex-basis longhand, which specifies the flex basis: the initial main size of the flex item, before free space is distributed according to the flex factors.

And, because our container was sized with our text’s size, subtracting anything results in the text wrapping! Of course, unless it was wrapping already — in which case the tiny size of the ::after won’t have any visible impact.

Things to Note

As mentioned in the original thread, this looks the best with text-wrap: balance. It is not present in the code I showed, as it is not strictly required for the technique to work, but it is applied from my general blog’s CSS.

If some of the text inside the title would need to have an additional element somewhere in the text, we’d need to wrap the whole text into a span, otherwise, due to the flex context, things won’t look as expected:

Component is not available in RSS, visit the the site to access it.` becomes its anonymous box.”>

<div class="example">
	<h3 class="forced-wrapping">
		Some <em>Nice</em> Title
	</h3>
	<h3 class="forced-wrapping">
		<span>Some <em>Nice</em> Title</span>
	</h3>
</div>

So if you want to use this with unknown content, it might be better to have this extra wrapper present. But maybe one day we’ll have the :contents pseudo-element which we could use to add an explicit wrapper around everything.

Sometimes, a title could look better when it stays on one line, in which case a non-breaking space could help:

Component is not available in RSS, visit the the site to access it.

<div class="example">
	<h3 class="forced-wrapping">
 		A Title
	</h3>
	<h3 class="forced-wrapping">
		A&nbsp;Title
	</h3>
</div>

Conclusion

There is a chance I explained something incorrectly. Still, the general idea should be clear: when working with a flex-basis, it does not have any impact on the intrinsic size of the flex container, so we can first size things based on the regular dimensions, and then adjust them.

When I first encountered this, I treated it as a bug, until I noticed that this behavior is consistent across all browsers, and seems properly specified.

It was fun finding an interesting use case for this behavior and applying it there. There are still areas of the flex algorithm that I do not understand completely, and I will need to return to it and explore it more.

And if you find other curious use cases for this flex-basis behavior in tandem with intrinsic sizing — please, let me know!

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 19: Container Queries

Wed, 06 Nov 2024 00:00:00 GMT

Current music:: Phoebe Bridgers — I Know the End
Current drink:: Hot Cocoa

I originally wanted to write about something else today but, for some reason, did not have any motivation for it.

But hey, let me then do the best thing I could do otherwise: share some other people’s articles. It is always nice to think that there are others, who are interested in the same thing you are.

In this post, I gathered 15 bookmarks about container queries (and some other queries as well). This time, the order is from the more recent to the older ones. I’m still playing around with how I want to do these bookmarks.

“A Friendly Introduction to Container Queries” by Josh W. Comeau — a lengthy article with many interactive examples with an overview of container queries: why we need them and how to apply them.
“Feature detect Style Queries Support in CSS” by Bramus — a post about how we can use space toggles for the style query feature detection.
“Resolving Issues from Unexpected Changes to container-type: inline-size in Chrome 129” by Michael Charles Aubrey — a post about a recent change to layout containment (see “Weaker form of layout containment for container queries” CSSWG issue by Ian Kilpatrick), which is already shipped in Chrome, and is also present in the latest Firefox Nightly and Safari Technology Preview.
“Is the sticky thing stuck? Is the snappy item snapped? A look at state queries in CSS” by Brecht De Ruyte — an article with an overview of two experimental scroll-state queries which are currently available for testing in Chrome Canary. I, personally, still think that scroll-driven animations produce a much better result for at least the “stuck” use case, but I can also agree that they’re much harder to work with, and for more simple use cases state queries will be much easier to apply.
“Logical Properties in Size Queries” by Michelle Barker — a post about one difference between container queries from media queries when using logical properties in them.
“Building a breakout element with container units” by Andy Bell — a short case study about how container query length units can be useful for implementing breakout layouts. I used a similar approach a few times and can attest that this is a good use for them.
“Querying the Color Scheme” by me — a post about how we could hack around the light-dark () function, registered custom properties and style queries to implement a way to detect the color-scheme on children of any element.
“‘Smart’ Layouts With Container Queries “ by Kevin Powell — an article that shows just how much better container queries are compared to media queries, including showing some of their uncommon but useful aspects.
“What if you used Container Units for… everything?” by Chris Coyier — a post about an experiment with container query length units, and some things we can learn if we try to apply them to everything.
“How to use container queries now” by Philip Walton — an article with an extensive look over the different steps we can take if we need to support older browsers when using container queries, including working around their absence with a ResizeObserver.
“Opting into CSS container queries for an existing design system” by Georgie Cooke — a post that takes a banner example to demonstrate how container queries can be used in practice today, outlining one pitfall that we can fall in when applying container queries in a design system context.
“Field Testing CSS Containment for Web Performance Optimization” by Brian Louis Ramirez — a post about using containment (without queries this time, but with content-visibility) as a way to improve the rendering performance of web pages, with a few field tests and their results.
“What Are CSS Container Style Queries Good For?” by Juan Diego Rodriguez — an article with a basic overview of container queries and style container queries, with a few examples and explanations of how they work.
“Responsive posters in CSS” by Robin Rendle — a post about how we could use aspect-ratio and container query length units to create fully resizable “posters”.
“We’ve Got Container Queries Now, But Are We Actually Using Them?” by Chris Coyier — an article looking at the current usage of container queries, arguing that we could want to start using them more, and presenting several good examples.

That’s it for today. Be safe.

Let me know what you think about this on Mastodon!

Beyond Tellerrand: Quick Notes on Physicality

Thu, 07 Nov 2024 00:00:00 GMT

Current music:: Veltpunch — killer smile
Current drink:: Hot Cocoa

I spent the whole day at the first of two days of beyond tellerrand conference in Berlin, so I did not have an opportunity to work on a proper post here.

I met many nice people! New and old faces, good talks.

I have made many notes, and have many thoughts, but wanted to just quickly jot down one of them, mostly as something that I have been thinking about for quite a while already.

That thing is — physicality.

Being someone who is staring at the pixels all day every day, I often wonder: is there something that is possible to do for me outside of the screen?

The problem is: I am kinda bad with physical stuff? My hands cannot draw, they cannot write, just the whole process of keeping physical notes is not something that I can or want to do. But I can see how being limited by the rectangle (or a few — with multiscreen setup) can be restrictive. How absence of a touch, of a feel, a texture, an ability to interact with things in real life is something I miss.

In my childhood, I used to play with LEGO a lot. In the present day (present time hahahaha), a lot of my days are spent fidgeting with any random small items I have on my work desk.

Is there anything that can be done that could fascilitate my experiments with CSS, but that would involve physical objects?

When I first learned about Dynamicland — a project by Bret Victor and some others — I was looking at it from a rather sceptical point of view. For my experiments, I am mostly working alone, the collaboration of these physical interactions is not something I need, or even want. Not everyone is comfortable working like that!

But maybe there is something that even I could find with this. Just as a way to augment the reality, but not in a digital way, but recursively, with other real things.

When Linda Liukas started the first talk of the day — about bulding an actual kids’ playground to fascilitate learning through play — I was immediately reminded of Dynamicland. And was delighted to see it mentioned on one of the slides as an inspiration.

Three other talks today also mentioned physicality in one way or another:

Jan De Coster did talk about his robots — actual physical objects.
Craig Black works with physical paint and uses the actual physics of acrylic paint to achieve some kind of generative art.
Jessica Hische mentioned how she copes with the uncertainty that AI brings today by doing more things in the physical realm, with her actual shop and studio in Oakland.

Everyone is touching their own medium, and I am a bit jelous: what about me? I don’t have anything like that.

Or do I? Maybe I just did not discover it yet. Maybe, one day I would wake up, and my brain will combine some puzzle that would show me the picture of how I could do it.

Maybe, one day, I could leave the wired world, and come back to reality.

Let me know what you think about this on Mastodon!

Moving to Firefox: the First Anniversary

Fri, 08 Nov 2024 00:00:00 GMT

Current music:: Sigur Rós — Sæglópur
Current drink:: Peppermint Tea

One year ago, I moved to Firefox. I’m still using it (the “Nightly” version).

Mozilla has made some questionable moves since then.

But, each time I look at the alternatives, I am not entirely sure if there is any reason — for me — to move to something else.

I don’t want to use anything based on Chromium, as I don’t want to use an engine with the biggest market share.
Each time I try Safari, I find it lacking in many areas I care about.
I want to use the latest version possible, so I don’t want to use anything that is based on Gecko, as it would be guaranteed to not be the latest. If I were to use Chromium — I’d use Canary, if Safari — then Technology Preview.
And I don’t think Servo is ready (but this is probably the one engine I’ll be looking at more closely when it comes closer to being feature-complete).

And like there is no ethical consumption under capitalism, there is no ethical browser development under it. If we’d follow the money trail of almost all browser development, what would we find? Likely, Google’s money.

If Google were to just stop giving money to Apple and Mozilla for the default search, and they would stop updating their engines, would they be added killedbygoogle.com?

Monopoly bad, capitalism bad, and I have no idea what the answer to all of this is.

Of course, there are boundaries that Mozilla could cross which will make me reconsider it. For me, they’re not there yet.

Thankfully, I changed browsers so many times, that if the need to move will arise, I will just move. But there are already so many things to worry about, and the theoretical purity of a browser engine is not something I have spoons to tackle right now.

Not that I have that many of them left. Initially, I wanted to write about Firefox plugins that I’m still using, and those I deleted. Or about my custom CSS overrides for Firefox’s UI. Not today. I’m too tired.

Let’s hope that Mozilla won’t do anything else, and I will write another post about all of this in one year.

Let me know what you think about this on Mastodon!

My Mastodon Starter Pack

Sat, 09 Nov 2024 00:00:00 GMT

Current music:: jizue — atom
Current drink:: English Breakfast Tea

Introduction

Sometimes, I invite someone to join Mastodon, and I end up sharing the same links and information repeatedly.

Following the “manual until it hurts” IndieWeb practice, after repeating the same things a few times, it is time to “automate” it. Well, in this case, just put everything into one blog post, I guess.

Why I’m only talking about “Mastodon”, and not about “Fediverse”?

While I have other Fediverse accounts — on Pixelfed (@[email protected]) and BookWyrm (@[email protected]) — the main account I’m using is on Mastodon (@[email protected]).

This means that I know much more about it specifically.

</details>

Why join Mastodon?

I’ve been using Mastodon actively for more than two years now: on November 6th, it was my second “fediversary” (last year, I wrote a “My First ‘Fediversary’” post). In that post, I described why I joined. I’m pretty happy there!

If I did send you a link to this post, that means I would be happy if you would join. I am not on any other social network, and I would love to stay connected with you.

That is the main reason.

Why not other social networks?

In short: they’re not decentralized. Even if their protocol is (at least in theory), there is usually a single entity that controls everything, backed by venture capital of questionable origins. I’ve been on the Web for more than 20 years, and I’m tired of services changing owners and going away.

If a single instance goes away, you can always move to another. If something happens with Mastodon itself, the Fediverse is still there.

There is a critical mass of people who care, and while moving servers can sometimes be painful, it is possible, and you can continue following everyone you did before.

</details>

Which Instance to Choose?

If I sent this link to you, it is likely I already sent you an invitation to join the same instance I’m on: front-end.social — an instance created by Miriam Suzanne (@[email protected]).

At this point, if you’re a front-end web developer, this instance gathered so many good people already! Of course, there are many other good instances. For example, fedidevs website by Anže Pečar (@[email protected]) has a page with a list of a few more popular ones.

But if I look at my stats (via the helpful “followers by instance” tool by Joseph Rocca (@[email protected])), I follow many people from a few smaller instances:

toot.cafe (directory)
indieweb.social (directory)
typo.social (directory, choose the “From typo.social only”)
tech.lgbt (directory)
social.lol (directory)
vis.social (directory)

Not everywhere is the registration open, though. If you know someone from an instance with a closed registration, they could usually send you a personalized invitation.

Why not to choose the “default” instance?

If you really don’t want to think, and you don’t have any friends, whose Mastodon accounts you know, you can join the mastodon.social instance.

However, I strongly recommend you find a smaller home. You will still be able to follow people from other instances — that’s the main point of decentralization — and you’ll have a smaller and neater neighbourhood, with better moderation and people who will more likely share your interests closer to you.

I did also omit some other larger instances like hachyderm.io and fosstodon.org, as, in my opinion, they are already too big.

</details>

Whom to Follow?

First, look at the front-end.social’s “directory”: it shows everyone who opted-in to be present there. If you had followed people from the front-end community before, you’ll likely see some familiar faces. And if front-end.social won’t be enough for you: look at the directories for other instances I posted above, as well as at the fedidevs directory that I already mentioned.

And — always a good way to find people — go to the “following” tab on anyone’s profile, and, if they did not hide it, you could also find someone to follow there. For example, here is my “following” list.

Which Mastodon Client to Use?

By default, the official web-app might not be ideal. As soon as you find its UX confusing, I highly recommend checking out one of many other third-party apps, in particular:

Phanpy by Lim Chee Aun (@[email protected]) — “A minimalistic opinionated Mastodon web client”. This is the main app I’m using both on the desktop, and the mobile. It is great! So many innovative features! The best part? It is just a static (!) web app — you can fork it, and then use it either just from localhost, or host it yourself on any of the free services — GitHub pages, Netlify, or anything else. See, for example, my fork — I added some CSS overrides just for myself.
Ivory by TapBots — an iOS app from the creators of “Tweetbot”. I am not using it, but I have warm memories of using Tweetbot back in the day, and if this is the experience you’re missing as well — you can try it! (but it is paid and has a subscription model).
Elk — I did not try it, but I heard many good things about it. It might look very familiar to you, and if this familiarity is what you’re craving — you can try it!

What is the Basic Etiquette?

I have no idea! Various instances have differences in how people use Mastodon. Before choosing an instance, I recommend carefully reading out their Code of Conduct and other rules they might have.

If I were to briefly mention something, it would be this:

Fill up your profile: userpic, name, links, etc.
Write an #introduction post. You can search for it in Mastodon to see how others do it, for example: https://front-end.social/tags/introduction
Start following people! Now, people could recognize you, or just understand who followed them, and not look at a newly created account with the default avatar, not knowing what to expect.
Start using Mastodon! Read what people write, and post your own stuff.
I recommend not to post links and advertise yourself right away. In general, self-promotion is welcome on most servers, but it is better to first acclimatize a bit to how things work, introduce yourself, show that you’re an actual person, and only then plug your work.
Similarly, I don’t recommend jumping into replies to everyone, especially if you do not agree with the other person, or have “not a question, but a comment”. Read first, think second, and only then decide if you can contribute to the conversation tactfully and responsibly. You know, be a decent, empathic person.
When posting something, do it accessibly: add proper alternative descriptions to images. I recommend “My Approach to Alt Text” by Adrian Roselli (@[email protected]), and do not use “fancy characters” and unusual markup, as it can be frustrating to get read to you if you’re using a screen reader.
Mastodon allows using the “Content Warnings” to hide some content behind a disclosure widget. Different corners of Fediverse have different etiquettes about this: consult your instance’s rules; it is usually mentioned there. Note that “CW” can be used for other purposes as well: not only for hiding NSFW content but also just anything topical that you feel can be distracting or triggering to other people, or even for longer threads, so they take less space in the timeline.

This is not an extensive list. Think with your own head, follow the Code of Conducts, and be a good human.

Managing Bookmarks, part 1

Mon, 11 Nov 2024 00:00:00 GMT

Current music:: Yvette Young — A Map a String a Light, Pt. 2
Current drink:: Lapsang Souchong tea

Introduction

I have so many things I want to do with my blog! I’m already thinking about having a good way to embed Pixelfed images, and now I’m also wondering what could be the best way to handle bookmarks.

Currently, I’m just posting them as compilations, manually marking them up in Markdown lists with links, writing descriptions, and then categorizing them.

I considered doing what some others do: posting bookmarks one by one, but I don’t think I like this approach. I enjoy reading articles in bunches, and usually on the same topic. It is interesting to make connections and look at how different people approach similar themes from different angles.

But the way I do it now is too limited: it is too manual, and it is difficult to build on top of it.

What I Want

Here is an approximate list of things that I want to do:

Make it easier to attribute people. Today, it’s a lot of manual work looking if I already posted something by some author, then copying their name & URL, and later their mastodon handle for mentioning there. I plan to save the common metadata, and then be able to easily access and compile it.
Sort things based on the time posted. Right now, I’m doing this manually, and do not really save this information anywhere, just using it to manually reorder bookmarks in the list. I wish to store the date, as it could be very useful in the future, as it will allow building a timeline of events for a specific CSS feature across multiple months.
Have better categories. Sometimes, I post bookmarks with too many different topics, not categorizing them at all. Often, I put some sections with a title around a list of them, but this allows me to have only one list. What I want to do is have the ability to add multiple tags per link, and then when I would like to publish a bookmarks post, make it easy to find the common themes.
Sometimes a post is a “reply” to something else or mentions other articles. For now, this is something I have to mention manually in my descriptions, but what if this could be another point of metadata added to every bookmark? It could allow the creation of something like a graph view of articles, showing how concepts evolve.
With tags, authors, and all the other metadata, I can see endless possibilities of providing different views over all the already posted bookmarks. I will need to fill out all that metadata, yes, but the result should be worth it.
If I detach saving the info on some bookmarks from publishing them, I could work on them more iteratively. I could easily separate published bookmarks from those not yet published and have an easy way to compile groups of them for my bookmarks posts.

Well, that’s a lot!

What I’m Planning

As I’m using Astro, I wondered how should I approach this. I think content collections sound the best.

I’ll need to come up with a good structure for everything.

How do I store the common metadata? In separate .json files per metadata type, with the bookmarks aliasing things to mention them? Or should I do it the other way, and gather things from the bookmarks instead?

How do I want to store a single bookmark? Should they be also in .json? One file per bookmark? Or maybe they could even be .mdx, allowing to add more elaborate descriptions, potentially with examples, if needed?

Do I want to store the description of a bookmark alongside its metadata, or only in the compilation posts?

Do I want to have some basic CMS that could simplify adding bookmarks significantly? Or just have some simple template and then just copy and paste stuff?

Should the list of bookmarks exist inside my blog’s repo, or should I maybe even create a separate package for them?

As you can see, I’m not a stranger to feature creep, haha.

Perhaps, I could start small, and work iteratively on something that is good enough from the get-go, and later build on top of it.

What Do You Think?

I’m planning to document how I iterate on this in my blog, with this being the first post in the series. As usual, I’m open to any feedback!

Do you read the lists of bookmarks that I post? Do you like the way I do it now? Am I too ambitious with what I want to do?

Do you post links in your blog? Is there something you are using to keep track of them? Would you change something in how you do it?

Let me know what you think about this on Mastodon!

I Will Not Delete My Twitter Account

Tue, 12 Nov 2024 00:00:00 GMT

Current music:: Haisuinonasa — transformation
Current drink:: Peppermint Tea

I was working on a different post today, but I got too deep into looking for a good example, realizing a bit too late that I won’t finish it today. So let me just improvise a quick post about a thing I have been thinking about for quite a while.

Here it is: I won’t delete my twitter account.

For a few years now, twitter is not a place you want to be at. Some people left it a long time ago. Some, for some reason, are fleeing it only now.

Many people talk about how they delete their accounts there. That’s ok! But that’s not what I will do.

I will not contribute to the link rot.

That’s one of the principles that I try to follow. We need to keep the Web interconnected. With over two decades on the Web, I saw many social networks die, their owners closing them up and removing all the content. I’m sick of it.

Twitter might as well die. In many senses, the links to it are already dead: a required sign-in, non-existent API. I removed all links to it from my site more than a year ago. I stopped linking to it, I stopped reading it. I stopped posting there.

If twitter goes away completely — so be it, but I won’t contribute to these links breaking.

The contribution of me deleting my account — whatever it could be — is not worth the harm that will be there from the broken links.

Yes, I have an archive of all content there, and I could host the content on my site (and, maybe, one day I’ll do so), but that won’t change a thing.

So, no, I won’t delete my account, but I am ok with it dying.

And if you’re planning to delete yours: I understand, but I recommend reading into how to do it properly before doing it haphazardly.

I don’t have any links about this (I will gladly add them if anyone shares them with me), but the general idea is that if you delete it, the username will become free, and anyone could take it up. The more followers you have, the higher the chance this will happen, with your username’s prominence being abused for spam, harassment, or even social-engineered attacks. There might be a good way to get rid of it but reserve the name — but, again, I don’t know the details. Send them to me!

Let me know what you think about this on Mastodon!

Observation: Inherited Visibility Transition

Wed, 13 Nov 2024 00:00:00 GMT

Current music:: Mammal Hands — Quiet Fire
Current drink:: Peppermint Tea

Introduction

Do not use transition: all in CSS. Just don’t (unless you are prototyping something, and will 100% remove it later). I won’t go into all the details today about why it’s bad (if I want to write about it well, I’ll need to do more research), but I will share one of the many issues it can cause.

Let’s quickly focus on its interaction with the visibility property, specifically how transitions work with its inheritance.

The Problem

Look at this example, and focus or hover the button inside, then unhover or blur it.

Component is not available in RSS, visit the the site to access it.

.example {
	& > button:not(:hover, :focus-visible) + span {
		visibility: hidden;
	}
	em {
		transition: all 2s;
	}
}

<p class="example">
	<button type="button">Hover or focus me!</button>
	<span>Some <em>hidden</em> text!</span>
</p>

If you’re not familiar with how visibility property works, this could be confusing. Like, shouldn’t it be not visible when the parent is not? Well, I wrote an article about this two years ago: “Obscure CSS: Restoring Visibility”.

In short, unlike display or opacity, it is possible to restore the visibility on the descendent elements! And because visibility is an inherited property, when the parent’s value changes, it inherits onto all the elements inside it.

What happens with a descendent element that has transition: all? That inherited value will be animated!

Animating Visibility

And due to the particular way a transition for visibility works, it will be visible for some time after we move the hover/focus away from the button in the example. Let me quote the specs:

For the visibility property, visible is interpolated as a discrete step where values of p between 0 and 1 map to visible and other values of p map to the closer endpoint; if neither value is visible then discrete animation is used.

That means that while the transition is happening, the element is hidden only when the value is right at zero, and is visible at all other times.

What Should We Do?

Not use transition: all. Use only the necessary list of properties you need to animate.

If you need to have many of them, instead of repeating the easing, duration, and delay, omit the property and then add the transition-property longhand:

em {
	transition: 2s 0.3s linear;
	transition-property: color, transform, opacity;
}

There is More (But Later)

There are many other reasons why transition: all is bad, but a proper explanation would need more research and would result in a bigger post: thus this is an “observation”.

As it goes, I did also stumble upon a potential browser bug that I’ll need to research, and then fill that is related to this observation.

I’ll try to do both of these later at some point. I hope even this shorter post will be useful to you.

Let me know what you think about this on Mastodon!

A good way to hide non-defined custom elements

Thu, 14 Nov 2024 00:00:00 GMT

Current music:: BimBamBoom — Shinzo BakuBaku Ochokochoi
Current drink:: Peppermint Tea

Introduction

This is a very short post about a thing that I have wanted to share for quite a while. I am pretty certain that someone already wrote about this at some point, but hey. There is so much content everywhere that it might be useful to repeat stuff, making it more likely someone will stumble upon a solution to their problem. And if you know other articles about this topic: please, let me know!

The Problem

Let me show the problem in an example (refresh the page if you want to see how the slow element is defined with a delay).

Component is not available in RSS, visit the the site to access it.

.example1 {
	& fast-element,
	& slow-element,
	& undefined-element {
		&:not(:defined) {
			/* Bad; don’t do this. */
			visibility: hidden;
		}
	}
}

<div class="example1">
	<p>
		Fast:
		<fast-element>Fallback</fast-element>
	</p>
	<p>
		Slow:
		<slow-element>Fallback</slow-element>
	</p>
	<p>
		Undefined:
		<undefined-element>Fallback</undefined-element>
	</p>
</div>
<script>
	class MyCustomElement extends HTMLElement {
		connectedCallback() {
			this.attachShadow({ mode: 'open' });
			this.shadowRoot.textContent = 'Defined!';
		}
	}
	customElements.define(
		'fast-element',
		MyCustomElement
	);
	setTimeout(() => {
		customElements.define(
			'slow-element',
			class extends MyCustomElement {}
		);
	}, 2000)
	// Nothing for the undefined one, duh.
</script>

All three have the same styles applied to them, and you can see how it works. Or, rather, it does not.

Without a fix, if an element is never defined, the fallback content will never be shown. This could happen for many different reasons: starting from any random JS error that prevents it from happening, and ending in a user having JS disabled in their browser. Or, in my case, just forgetting to define the element.

And when an issue like this happens — the element ends up being not visible and not accessible.

Animated Solution

One possible fix that I like: use an animation that would start from the element being hidden, and then, after some delay, it will reveal the fallback regardless (refresh the page to see the example in action):

Component is not available in RSS, visit the the site to access it.

@keyframes --not-defined {
	from { visibility: hidden }
}
.example2 {
	& fast-element,
	& slow-element,
	& undefined-element {
		&:not(:defined) {
			animation: --not-defined 0s 3s both;
		}
	}
}

<div class="example2">
	<p>
		Fast:
		<fast-element>Fallback</fast-element>
	</p>
	<p>
		Slow:
		<slow-element>Fallback</slow-element>
	</p>
	<p>
		Undefined:
		<undefined-element>Fallback</undefined-element>
	</p>
</div>

I saw other approaches to that, like having something what detects if JS is enabled, but these kinds of approaches will not help with the JS error edge case.

Future Alternative `@starting-style`

In the future, when @starting-style will be more widely available, we could use it instead: the following example will work only in browsers that support it. And when they do boot support it, the styles won’t apply at all, which is also ok, as I always see this technique of hiding contents until defined as an enhancement, everything will still work without it, it just won’t be as pretty.

Component is not available in RSS, visit the the site to access it.

.example3 {
	& fast-element,
	& slow-element,
	& undefined-element {
		&:not(:defined) {
			transition: visibility 0s 3s;
			@starting-style {
				visibility: hidden;
			}
		}
	}
}

<div class="example3">
	<p>
		Fast:
		<fast-element>Fallback</fast-element>
	</p>
	<p>
		Slow:
		<slow-element>Fallback</slow-element>
	</p>
	<p>
		Undefined:
		<undefined-element>Fallback</undefined-element>
	</p>
</div>

Final Words

This case is a thing that I often see people not doing: not considering the failing states of something they implement.

It is always a useful habit: to ask yourself “What is the worst-case scenario?” when doing something as drastic as hiding content.

I am in no way an expert in custom elements. If you know any downsides of my approach or a better way to shove the same: please, let me know!

Let me know what you think about this on Mastodon!

The Problem of Embeddable Interactions

Sat, 16 Nov 2024 00:00:00 GMT

Current music:: Novo Amor, Gia Margaret — No Fun
Current drink:: Peppermint Tea

What I’m Talking About

When I created this blog, I implemented the same thing I did on my main site: a custom element that links to the mastodon post where I shared the link to the post, and which also shows the number of replies, favorites, and boosts.

It is very primitive (so there is no real point in sharing its code yet), but I have some plans to improve it.

One thing I do not plan: embedding the comments and userpics of the people who reacted to the posts.

I did think about this for quite a while. I saw others implement this: pulling as much data as they can, showing all the comments people leave to their Mastodon posts, showing all the faces of people who “liked” the post. Now, people are also adding the same for reactions on bluesky as well.

I won’t do it.

Why not?

For me, this is an issue of expectations and consent.

I see a difference between publishing something on a website, and an interaction that is happening in a social network.

When I look at some post in Mastodon, I do not usually consider that a reply to it, or me boosting or favoriting it, will be broadcast to everyone. Personally, I do not care much, but I can see how someone more concerned with their privacy could not expect their userpic be shown under someone’s post. In most cases, this can be harmless. But what about the edge cases?

It is easy to be ok with your name under someone’s post in Mastodon — where it is visible only if you’d explicitly go look who did interact with it.

Compare this with your userpic or username clearly visible on the page with some content.

Yes, the information about the interaction is public, but I can see the difference in the perception of privacy, and the potential impact.

If your interaction is automatically displayed this way, often you won’t even know about it. Most Mastodon posts that are used to pull these interactions do not have anything stated in them about this.

Can We Improve This?

Comments

When I was thinking about whether there is a good way to display comments this way, I decided that if I did it, I would use the boosting feature in Mastodon.

Basically, by default, no comments are pulled into the post. If you boost it from your account — only then it could be included. By boosting it in Mastodon, you’re communicating that you’re sharing the comment further.

This makes it also a good pre-moderation tool: comments are not displayed by default under your post, and require your explicit action to be added there. “Favorites” could also be used this way, but it feels a bit too easy to misuse.

Another thing that could be considered: respecting the “quiet public” (as Mastodon calls it now, previously “unlisted”) privacy setting.

Even with boosting, I probably won’t ever display an unlisted post — after all, their author explicitly opts out of it being too public.

Favorites and Boosts

With favorites and boosts, it is much harder to gauge when they can be safely displayed. The closest thing to use could be the “discoverable” flag from the account data, likely, alongside the “noindex” one, and probably the “locked” one.

If I were to implement something like that, I wouldn’t show the interaction if there is any indication that the author didn’t want their content to be shared more widely. Actually, this is likely something that could also be considered for displaying comments as well.

With this in mind, the number of favorites and boosts could be displayed as “N likes, including from this person and that person”.

Final Words

Even though I did propose some ways this feature could be implemented in a slightly more respectful way, I will likely not do it for my blog (and maybe even remove the interaction counters whatsoever).

But if you’re already displaying others’ Mastodon and bluesky interaction on your blog — I recommend you to think about it, and see if you could consider what I wrote about above.

Also, perhaps it is just me overthinking things, as usual, but hey. If you also ever had thoughts about this, or felt a bit uncomfortable when seeing these integrated interactions — I’ll be happy to hear your ideas about it!

Let me know what you think about this on Mastodon!

Repetition and Attribution

Sun, 17 Nov 2024 00:00:00 GMT

Current music:: Tenniscoats — 風の歌
Current drink:: Peppermint Tea

Introduction

Today, I want to talk about two things, in the context of writing articles and sharing knowledge in general. One of them we don’t need to be afraid of, and another we need to do as often as possible.

The first one is repetition. The second one — attribution. It could seem like an odd pair, but I’ll try to explain how they are connected.

Repetition

We should not be afraid to repeat others and ourselves. When thinking about an idea for a blog post, article, talk, or anything else, often a stray thought can appear: what if someone did this already — and did this better, so why bother?

This is the wrong way to think about ideas and knowledge. A question like this can have two answers:

“No, no one did write about it.” If you can verify it, this is a great answer! But a boring one. Well, in the context of this article: if you know that what you’re going to share is novel, there should not be any hesitation. Go ahead and do it!
“Yes, someone did already share it.” Ok, but that does not mean that it should stop there. This is a much more interesting position to be, and a big part of what I want to talk about.

Unknowingly Repeating

It might happen that you could not find prior art and decided to share something. It is totally fine if you discover later that someone did do the same thing! “Multiple discovery” is possible, and even if someone did come up with the same concept before, it is rarely expressed in the same way. Everyone is different, and you’ll likely still contribute something.

Take the “space toggles” as an example. Multiple people discovered them at different times, and shared them in one way or another. I compiled a timeline of this in the “Was This Always Possible?” section of my “Cyclic Dependency Space Toggles” article.

Don’t be afraid to publish something just because you’re afraid that someone in the past already did so.

If they did — and you will later get to know about it — you can always, you know, attribute them, and then spend some time looking at what they did, and how it is different from your perspective.

It is always fun to look at these differences, and look at the same thing from others’ perspective. Often, an unexpected angle could bring a new insight.

Continuing the Work

Occasionally, you can get this insight based on others’ work and don’t think much of it. You can read someone’s article, see a small potential for improvement, and think that this is too small of a thing to share.

But there is no such thing as a “too small to share”. At the minimum, you can share it on your social network. Or — explore the idea further. If the author missed this small part, what else could there be? What if you played with their code more, tried to understand it, and maybe integrated it into your work?

All of this could lead to more discoveries or new use cases. Often, some articles can be too theoretical, with not many practical examples. It can explain why some techniques work, but not go into details of when they can be applied, or how they can fit into your workflow. By exploring it, you can, at least, share it as a case study. Or you will eventually discover something more interesting!

Many discoveries have others’ work at their foundation. You don’t have to be that foundation, but you can use it to build something new on top of it.

Rephrasing

Even if you don’t have anything new at all to say, rephrasing the common knowledge can be really useful!

A radical example is a translation: the same meaning is made accessible for a bigger slice of the world population.

But even without translation, there are multiple ways we can repeat something. Everyone is different and has various mental models of the world, and ways they like to consume information.

Your sources can be too technical or too dry, but you can always reword things, presenting them in a way you like to receive them. Take some CSS specs or an MDN article, and try to think how you would describe it to your friend. Which examples could you make? What specific parts talk to you more than others?

You can focus on one aspect, and dig deeper into it, or you can do the opposite and generalize the text by giving an overview.

Even if you don’t introduce much new, in today’s work with the constant flood of information, a repetition can bring something to someone’s attention that they could’ve missed otherwise.

You can just share that you’ve learned something, and describe it in a few words. For example, you could stumble upon a CSS feature from recent years that you somehow missed. You know what? Others could’ve missed it too! If you write about it — even without adding much new — someone else will now stumble upon it too.

Attribution

I hope it is obvious to you, but let me be explicit here: when doing all of the above — reading others’ works, sharing what we learned, and building on top of it — we must attribute our sources.

In today’s world, where information is so often processed through a grinder into a uniform soulless mess, attributing the sources is something that could make your work stand out.

When you mention another person, you create a connection. Hyperlinks — they’re cool. They provide context, they allow others to read the same thing you read, and they allow others to discover something new.

If you share some links, don’t do it blindly: find out who the author is. Do they have a personal website? Do they have a Mastodon account? What else do they write about? Can you subscribe to their RSS feed?

You have the power to bring attention to others — use it. Now that you know someone by their work, you can elevate them, and multiply the force they put into their work by sharing it with attribution.

If someone did write something, they might have had doubts and anxieties about whether it was worth it, whether their work was novel, and whether anyone was interested in it. When sharing a work with an attribution, you’re not just sharing a link; you point at someone and say, “Look at how this person did a cool thing!”.

I can assure you, that brings joy, and I wish I saw others do this more. I think we’ve gotten much better at it in the last few years.

Final Words

Do not be afraid to share what you learned. Use others’ works as an inspiration, and give it back by attributing them properly. If you missed something — you can always edit it later. If someone reminds you about it or shares a link to a similar thing — thank them, attribute it, and consider that you’re in such good company. Others are interested in the same thing that you are!

Let me know what you think about this on Mastodon!

Writing About Experiments

Mon, 18 Nov 2024 00:00:00 GMT

Current music:: Haley Heynderickx — Gemini
Current drink:: Peppermint Tea

In Response To

I often see complaints about people hyping up new web platform features while they’re not yet ready for wide use. Like, developers getting tired of hearing about all these shiny new things, and not being able to apply them to their production sites.

One recent article that mentioned this was “New CSS that can actually be used in 2024” by Thomas Loreille from this March. In it, he tries to look at various wider supported features instead. Ironically, in some enterprise environments, even these features you couldn’t, actually, use.

A few days ago, Rachel Andrew wrote about this (and also mentioned Thomas’ article) in her post “When is the right time to share our excitement about new web features?”, where she looks at this issue from a browser DevRel perspective.

As someone, who regularly writes about the emerging specs and their experimental implementations, I also was on the receiving end of similar complaints.

What I Do

I am not a browser DevRel. However, I am now a member of CSSWG (previously: an invited expert, now a member on behalf of the company I am working in — Datadog — as it joined W3C), but I am trying to look at things in the same way I did before, and write about them in the same way.

When I publish my articles, I always have plenty of things in mind, not necessarily a set of rules, but rather guidelines and directions that I follow.

In this post, I cover some of them, and if you want to experiment as well, consider thinking about them too.

Browser Support

This is the most obvious thing: when writing about something that is not widely supported, we must warn others which browsers support something, and if the feature is experimental.

I am not only talking in terms of Baseline, but I am glad we are working on standardizing the way we can share this in articles.

Current Experimental Version

When I write about some experimental feature, not only do I mention that it is such, but I prefer to mention which exact browser version I am using.

Both specs and experimental implementations change — it is not guaranteed that the code I share will work after I publish an article.

We always should have a date somewhere on the page with a post we share, but having an exact browser version is very convenient too, especially if you’d want to later report a regression.

Adding Screen Recordings

When sharing live examples of the new code, I almost always provide a screen recording of them, which is shown if the reader is looking at the page in a browser that does not support the required CSS feature. This fulfills multiple things:

A user without a browser with the feature in question can still see how it works. This can be especially helpful on mobile devices, where you can’t easily switch the browser to the experimental one with some feature flag turned on.
It records the way something works in case it changes. Even if the code example breaks due to the implementation change, it will still be possible to see how the example was intended to work. You can also consider it to be a kind of visual regression testing: if something breaks or changes, it will be possible to use the recording for comparison. And with the exact browser version, it can be used in browser bug reports.
Finally, a minor bonus: for highly interactive examples, a video like this provides an alternative way of experiencing this interactivity. By watching the video, you’ll know what I wanted to show with the added interactivity, and it can be helpful if that interactivity is inaccessible otherwise, like with the resize CSS property on a mobile device (where you’d likely also won’t have enough space to test the responsiveness). I am even thinking of maybe adding this to articles that do not have browser limitations, but as this is extra work, I never find extra spoons for this.

Not Writing Tutorials

I rarely intend the code I share in my articles to be easy to copy. Usually, I display only the necessary parts to explain what they do, and I do not always work on making it reusable.

As Rachel writes:

You often don’t need to write huge guides, how tos, and tutorials for experimental things.

I do not consider myself a good teacher, and I am not the best at organizing things. I adore people like Stephanie Eckles who can distill some technique into a nice reusable snippet, or Josh W. Comeau who can explain things in plain language with great interactive examples.

Me? I like to poke at the code with a stick, see what happens, and then share it alongside my thoughts about it.

This is something where I can often agree with the critics of the experimental features hype: we should not present new tech as “tips”. If something is a foundational CSS feature but does not work everywhere, you cannot, with good conscience, recommend it as a solution.

I notice that many authors play the “algorithm” by sharing very obnoxiously experimental demos as “CSS Tips”, and I find it misleading and harmful. Don’t do this, please.

Thinking About the Future

When I write about new features, I always look into the future. A day will come when we will be, finally, able to use all of this new goodness in production.

By experimenting with all of that today and writing about it, I believe I am bringing this day a bit closer.

Browsers implementors and spec editors need feedback from authors from many different angles:

Is there someone who needs this feature?
Are there issues with the way the feature works?
Is its API convenient?
How does it play with other features?
What are edge cases?
Could we change something small, and get a quick win while we’re in the context of working on this feature?
Is there something that it can unlock that was not possible before?

If you read my articles about anchor positioning or scroll-driven animations, you’d likely see how I try to cover most of these questions with what I write.

I experiment, fill browser bugs, provide feedback in CSSWG issues, and share the potential techniques that will be possible with the new experimental features.

When the future becomes the present, we will have it in better shape — and with all these techniques ready to be applied. After all, some techniques that use existing features can take years to discover, my “Fit-to-Width Text: A New Technique” or “Layered Toggles: Optional CSS Mixins” being good examples.

Final Words

The last few years were very productive for CSS: both in terms of what goes into specs, and what browsers implement. Some authors look at all of this and think that it is too much. Some are frustrated that we cannot use all of this today.

We are in an interesting spot: after these years of progress on CSS, much of it started to become wider and wider available.

My hypothesis is that many people have a delayed response — and a habit — of being frustrated about the limited capabilities of CSS.

I am only excited. With each day, browser support for container queries, :has(), @layer, @property, and countless other “newly available” CSS features improve.

And as someone who tries to follow almost everything that authors write about CSS, as features become more available, we get more articles about them.

When a feature lands in all browsers, people write about it. The longer a feature is available, the more people start using it in production and also write about it.

It is a long process, and we can be frustrated that the bright future is not there yet. But it will be there. I believe in it, and in us, who are trying to bring it closer.

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 20: Just Three Links

Tue, 19 Nov 2024 00:00:00 GMT

Current music:: Haisuinonasa — Mirror
Current drink:: Peppermint Tea

Writing one post a day is hard! I had an idea for an observation but did not have an opportunity to write it up properly. Come on, me, these should not take that long!

That means I am falling back to the idea I reserved for cases like this one: where I cannot quickly come up with a post on the spot. That is: share just a few recent bookmarks!

Here they are! This time, they’re ordered from longer to shorter.

“Overflow Clip” by Ahmad Shadeed — an article explaining the clip value of the overflow property and where it can be used. Fun fact: the ideas for some of my experiments with scroll-driven animations, that later became “Fit-to-Width Text” and “Position-Driven Styles” articles, came from me reading the specs for overflow: clip, specifically its difference from hidden. The clip value is cool, and well-supported — play with it!
“The stretch keyword: a better alternative to width: 100% in CSS?” by Ollie Williams — a post about the new standard sizing value, which is now implemented in Chrome, and will come as a replacement for -moz-available and -webkit-fill-available (and could be potentially used in more contexts).
“How to correctly use steps() with animations” by Temani Afif — a quick tip about the steps() easing function for CSS animations, specifically its jump-none value for <step-position>. This is something I did not play much, so it was new to me! And I can already remember how some places where I struggled before could’ve been solved by this tiny trick. I recommend reading the specs for steps() — there are some nice animations that demonstrate how its different values work!

I wonder: have you noticed a common theme between these three bookmarks? Please tell me if you did spot it!

Let me know what you think about this on Mastodon!

Transitions of Inherited Properties

Wed, 20 Nov 2024 00:00:00 GMT

Current music:: Stage Kids — The Seven Pillars of Gulu
Current drink:: Peppermint Tea

Introduction

When I shared my “Observation: Inherited Visibility Transition” post, I mentioned that there was a CSS bug I encountered that I wanted to research and maybe fill later.

Well. I thought it would be a quick thing, making into a quick post. Apparently, not!

The Problem

In that post, I talked about visibility and inheritance. The bug that I wanted to report was related to how values are inherited: I noticed a difference between how Firefox does it, and how Chrome and Safari do it.

When there are multiple nested elements with a transition for an inherited property, Firefox applies the transition immediately for all of them, while other browsers stagger it.

Looking if this is already reported, I found the following:

A Webkit bug report “CSS inheritance delayed when transition duration on parent and child elements” from 2010 by Sidney San Martín.
A Chromium bug report “CSS transitions inherit incorrectly when specified both an element and its ancestor” from 2013.
“Undesired behaviour - transition of inherited value happening in sequence” CSSWG issue from 2020 by Meir Cohen. Meir also opened two bug reports alongside it:
- A Chromium bug report “CSS Transition of inherited value sequenced across children elements”.
- A WebKit bug report “CSS Transition of inherited value sequenced across children elements”.
A Chromium bug report “CSS font size transition is slower if the element inherits it” from 2024.

Almost in every case, people seem to prefer the way Firefox handles it (applying immediately across all elements), rather than how Safari and Chrome do it (restarting the transition of the inherited property on every frame).

Not a Bug?

The bigger problem: this might not be a bug, even though this might be a significant interop issue. It is obvious that multiple people have stumbled upon this over the last 14 years. If I would not look up for existing bug reports, I would be another person reporting the same issue.

But is it a bug? This is one of those cases, where CSS specs explicitly say that the browsers can do whatever they want:

This specification does not define when computed values are updated, beyond saying that implementations must not use, present, or display something resulting from the CSS cascading, value computation, and inheritance process without updating the computed value (which means merely that implementations cannot avoid meeting requirements of this specification by claiming not to have updated the computed value as part of handling a style change).

[…]

Since this specification does not define when a style change event occurs, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others.

So, according to specs… this is not a bug?

Still a Problem

Looking into the history of the transition specs — this last part was there already in 2009. Here it is from CSS3 specs:

When the value of an animatable property changes, implementations must decide what transitions to start based on the values of the transition-property, transition-duration, transition-timing-function, and transition-delay properties at the time of the change. Since this specification does not define what property changes are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others.

This was even before CSS animations were a thing! Not mentioning what we have today, and what is planned (view transitions, scroll-driven animations, and so on).

Maybe it is time to revisit it?

Given the interop inconsistency is there for so many years, on one hand, it might be tricky to change, on the other — different browsers already treat it differently, and the world did not explode.

If anything, I think I could even prefer having a separate property that would control how such a transition happens! I still think that the way Firefox behaves is the correct one, but I can also see how what Safari and Chrome do today can be potentially used in some techniques.

Let’s Reopen the Issue

After thinking about this, I decided to reopen the issue that I mentioned in the beginning. I don’t like to have inconsistencies like that in the web platform, and the longer we keep them, the higher chance they will impact something in the future, making it much harder to implement new things consistently and in an interoperable manner.

Please participate in this issue if you did also stumble upon this in the past!

Let me know what you think about this on Mastodon!

Recent CSS Bookmarks 21: Anchor Positioning

Thu, 21 Nov 2024 00:00:00 GMT

Current music:: toe — グッドバイ
Current drink:: Peppermint Tea

Anchor positioning is cool! And there were many articles and posts about anchor positioning since I last mentioned it in my bookmark posts. Here they are!

“Let’s hang! An intro to CSS Anchor Positioning with basic examples” by Brecht De Ruyte — a good introductory article about anchor positioning that compares two different ways we can achieve the same thing, and looks into some other details.
“Anchoreum” by Thomas Park — a fun game that teaches anchor positioning. I did not yet finish it, but it might be a good way to learn how some of its aspects work if you’re not yet familiar with it.
“Layered positioning” by Christoph Päper — a CSSWG issue about how we could make an anchored element match the layer of its anchor. I commented there today with two small proposals, the ideas for which I got after a mastodon thread started by Mayank. Check out the thread itself for a demo of another anchor positioning use case: animated focus ring. I mentioned this use case in my CSSDay talk, but did not have an opportunity to finish a draft of an article about it yet.
“Anchor Positioning Is Disruptive” by James Stuckey Weber — a post about an interesting use case for anchor positioning, a bit similar to the one with the sidenotes. See also “Another Anchor Positioning Demo: Multiple Anchors” by Michelle Barker, Nuclear Anchored Sidenotes by Eric Meyer, and the “Sidenotes Layout” section of my old “Future CSS: Anchor Positioning” article.
“Custom Range Slider Using Anchor Positioning & Scroll-Driven Animations” by Temani Afif — an article about how we can target pseudo-elements of the range slider with both scroll-driven animations and anchor positioning. The result is very impressive and even uses the technique from the “Solved by CSS Scroll-Driven Animations: Style an element based on the active Scroll Direction and Scroll Speed” article by Bramus. I am glad that we now have a proper exploration of this concept, which I shared a year ago in my “Observation: Range Input’s Thumb and Emerging CSS” post.
“Custom Progress Element Using Anchor Positioning & Scroll-Driven Animations” by Temani Afif — a continuation of the previous article, this time applying this method to the <progress> HTML element.
“Front-End solution: Eyebrow heading dots” by Andy Bell — a post about a challenge for placing elements on two sides of a wrapping element with a solution that builds on top of my “The Shrinkwrap Problem: Possible Future Solutions” article that I shared with the author.
“Anchor Positioning and the Popover API for a JS-Free Site Menu ” by Michelle Barker — an article that looks at various aspects of how we could use anchor positioning with popover API, including a site menu use case.
“Progressively Enhanced Popover Toggletips” by Michelle Barker — an article about using anchor positioning to progressivly enhance footnotes.
“Web components + anchor positioning + popover API = I love the platform” by Jim Schofield — a post that looks at how we could build a popover with anchor positioning as a custom element.
“Flow Charts with CSS Anchor Positioning” by Cory Rylan — a post that looks at the flow charts use case for anchor positioning. See also: the “Using the Connections” section of my old “Future CSS: Anchor Positioning” article.

Let me know what you think about this on Mastodon!

Managing Bookmarks, part 2

Fri, 22 Nov 2024 00:00:00 GMT

Current music:: ・・・・・・・・・ — shiduka no umi
Current drink:: Camomile & Lavender tea

I spent this evening thinking a bit more about what I want to do with my bookmarks.

Nothing really done, but this time I experimented with Obsidian to see if it could be a good way to store them, add metadata to them, and so on.

I tried a few plugins and, at first glance, managed to get rather close to a good starting point. No code to share yet, but I’ll mention the plugins that I tried:

Templater plugin by SilentVoid13 is nice, and allows (among other things) setting up a default template per folder, so creating a file in it could fill it with some default metadata. And, potentially, run some scripts. Some other plugins can build on top of this one.
JS Engine plugin by Moritz Jung is fun, and allows running arbitrary JS right inside Obsidian. It is required for some other plugins.
Meta Bind (also by Moritz) is one such plugin that depends on JS Engine and allows adding various inputs, like buttons, right inside your documents.
MetaEdit plugin by Christian Bager Bach Houmann. I wanted to see if there is an easy way to modify the frontmatter of any current file, as by default Obsidian does not seem to provide a built-in API for this. At first, I encountered a few issues with how it works: I tried using the MetaEdit’s API inside a js-engine fenced block, but it was bugging out. Then, I tried it with Meta Bind — and it worked inside of it!

At this point, what I am planning to do: create a default template with some metadata fields and a button. Then, I could create a new bookmark file, paste the bookmark’s URL into one of the fields, press the button, and it would try and fill the remaining fields automatically for me. In theory.

When I’ll get to something that would work, I’ll post another update. Stay tuned, I guess!

Let me know what you think about this on Mastodon!

Idea: Self-Boosting Image Mastodon Bot

Sat, 23 Nov 2024 00:00:00 GMT

Current music:: MindaRyn — SURVIVE
Current drink:: Peppermint Tea

Introduction

Every so often I write down various non-CSS ideas in my notes, which I know I likely won’t ever implement (or maybe will do, but I never know when). This is one example of such an idea: perhaps it could be worth sharing them in the blog.

There is such thing as picture bots that post images every hour. I subscribe to a few of these that post red pandas, raccoons, and opossums. They’re all cute! Though, with the botsin.space instance going away, I’ll likely need to find another source of these.

The Problems

While I like these kinds of bots (they bring some positivity to a sometimes too sad or technical timeline), I noticed several problems with them:

Digital waste. These bots can regularly post the same image, over and over. While you could set up automatic deletion of old posts, this is still not ideal for various reasons.
No way to know whether you saw some image or not. You have to rely on your memory: is this a new picture? Or you saw it, but forgot about it? As the same image can be randomly reposted, that post will be a new one, so you couldn’t use likes or bookmarks to mark those that you already saw.
It is difficult to identify an entirely new image. When a new one is added to the dataset, you won’t know if a new random post takes an image from the archive or if that image is a sparkling fresh.
The randomness algorithm is frequently flawed, commonly reposting the same image too close to others, or not giving some image a chance for a while.

One Potential Solution

If I were to implement a similar bot (or if you’re thinking about one), here is how I’d try to approach it.

Each image from the dataset should be posted only once. No deletion, and no duplicates.
On every iteration, if there is an image in the backlog that was never published, it is published as a new post. If there are multiple images in the backlog, a new one is chosen randomly.
Crucial part: once all images from the backlog are published, instead of reposting the old ones, the bot starts boosting old posts. It must boost only an image that it never boosted before, and select one randomly.
It should never pick to boost a newly published post until a certain grace period passes.
The same grace period is used to un-boost the old boosted posts, making them enter the stack of possible posts to boost next.

We can think of the posts as of multiple stacks of cards: they never duplicate, and we just shuffle them around, making sure we keep things fresh for the duration of the grace period.

Benefits

Because the images are never duplicated, this should be much lighter for the servers and the infrastructure. No need to upload duplicate images, as the old ones could be just used.
All the interactions stay with the image: if you boosted, liked, or bookmarked a post, you’ll know when it comes again.
As even comments will stay, this can allow people to add their input to the posts: add better alternative descriptions, sources, and attribution.
Bot authors could use these interactions to improve the posts: the data in them can become the source of truth, and the images could be easily updated with the better descriptions and attribution, or retired if found problematic for some reason.
New posts will stand out, as they won’t have the “self-boost” visual. Even more: you could always disable boosts from the bot account, and only receive new images if you’d want to.
It might be easier to implement the algorithm, and maybe even keep it for boosting only, while allowing posting new images outside the regular schedule manually. This way, all the necessary data for the algorithm can be contained in the bot’s timeline, making the bot much more simple.

Final Words

I never wrote a Mastodon bot. So take my idea with a grain of salt. But I have been sitting on this idea for a few months already, and I still think that it is a good one. Maybe I am wrong! Please let me know if so. And you are welcome to try implementing it — the last time I touched Mastodon API, it was rather simple.

Let me know what you think about this on Mastodon!

Embedding Pixelfed, part 2

Sun, 24 Nov 2024 00:00:00 GMT

Current music:: This is The Kit — No Such Thing
Current drink:: Sencha tea

Look at this squirrel!

Introduction

Since my last post about this, I did some progress on embedding Pixelfed images in my blog. Here is what I had to write in this post’s markdown to get this photo displayed:

![](pixelfed:739971733249250140/3)

That’s it. You might notice that in the markdown there is no alt provided. But it is still present in the actual HTML, as I am retrieving it from the one I submitted with the photo when uploading it to my Pixelfed instance.

The src for this image in Markdown contains two things: first the lookup string — in this case the post’s ID, and then the index of the image in the post.

There are still many things I want to implement before I could start using this properly, but this seems like a good checkpoint in my work on the feature.

What I Did

Looking at the “Plans” section of my previous post, this one covers most of what I wanted to achieve so far, except for the design/CSS part.

For now, I am using the dotenv NPM package for storing the API token. I know, there is likely a way to do this without depending on a package, but I’m lazy to explore this, ok?

Update from 2025-01-24: actually, Astro has build-in support for env variables, so now I’m using it.
I implemented fetching and caching the data for my Pixelfed posts. It is likely far from optimal, but it works. I’ll only fetch things when doing local development, then what I receive from the API is saved as .json files, one per post, so there won’t be any fetching done neither in the CI nor on the client (aside from the image’s src, of course).
I added a wrapper around the MDX img component that checks if it uses the fake pixelfed: protocol in the src. If not, it falls back to the original Astro’s Image component, but otherwise it will do everything necessary to get the src, alt, width, and height for the image from the cached/fetched data. See my “Astro MDX Components” post on how I substitute the built-in HTML tags rendered by MDX with custom Astro components.
I added some very basic CSS for the photos:
```
img {
	max-inline-size: 100%;
	height: auto;

	&.photo {
		display: block;
		width: auto;
		max-block-size: min(100vh, 100cqw);
		margin-inline: auto;

		p:has(> &) {
			container-type: inline-size;
		}
	}
}
```
Nothing special; mostly trying to make images always fit into the viewport, and make it so horizontal and vertical images will have roughly the same area. I will likely redo this, but it works for now.

To Do Next

Here is what I am planning to do next:

Come up with the design for a <figure> around a photo, and for how I want to display its caption. As I wrote in the beginning, I already have the alt coming from the Pixelfed API, so I am thinking of reusing the markdown’s alt (![this part]()) to provide an additional caption for a photo.
Find a good way to display a gallery of photos, optionally with the thumbnails and a way to see one in full.
Refactor the code behind how I fetch and display the images. Currently, it is a mess. I want it to be less of a mess. When I do so, I might write about what I’m doing here, but I don’t want to share my suboptimal code just yet.

That’s it for now! I have many other ideas as well: somehow getting the Exif metadata from my photos that I have locally, displaying it, and so on. But that’s likely for much further in the future.

Final Words

I am pretty happy with what I did so far, and with what I’m planning to do in the future.

Fun fact: I just ordered a new lens for my camera. I’m a bit frugal with my setup, and rarely buy new stuff in general, but as I managed to do quite a few (for me) photo walks this year, I decided that it might be time to add another lens to my very tiny collection. Maybe one day I’ll write about my setup.

But for now, I’ll need to continue working on an ability to embed photos in this blog, so I could properly share what I capture.

Let me know what you think about this on Mastodon!

Observation: Sticky Anchor Navigation

Mon, 25 Nov 2024 00:00:00 GMT

Current music:: Paranoid void — The end of the travel,The beginning of the world
Current drink:: Camomile tea

Introduction

When I updated how I am doing scroll markers for the table of contents in this blog, I stumbled upon one curious interaction that I previously did not think deeply about.

That interaction: how anchor navigation behaves with elements that have sticky positioning.

Look at this example, and try clicking on the “Go to” links, including clicking the same link multiple times.

Component is not available in RSS, visit the the site to access it.

.scrollport {
	overflow: auto;
	overflow-x: hidden;
	scroll-behavior: smooth;
	height: 200px;
	outline: 1px solid var(--GREEN);
}
.test {
	position: sticky;
}

<div class="example">
	<nav class="example-nav">
		Skip to:
		<a href="#A">A</a>
		<a href="#B">B</a>
		<a href="#C">C</a>
		<a href="#D">D</a>
		<a href="#E">E</a>
		<a href="#F">F</a>
		|
		<a href="#top">Top</a>
		<a href="#bottom">Bottom</a>
	</nav>
	<div id="top"></div>
	<div style="height: 200vh"></div>
	<div id="A" class="test" style="top: 0">A</div
	><div id="B" class="test" style="top: 100px">B</div
	><div id="C" class="test" style="top: -100px">C</div
	><div id="D" class="test" style="bottom: 0">D</div
	><div id="E" class="test" style="bottom: 100px">E</div
	><div id="F" class="test" style="bottom: -100px">F</div>
	<div style="height: 200vh"></div>
	<div id="bottom"></div>
</div>

For example, when on the top, try going to “B”, “D”, “E”, or “F”, multiple times in a row.

Or, go to “C” when at the bottom.

</aside>

Isn’t this curious?

What’s Going On?

This behavior is (mostly) interoperable across all browsers, and is defined in the specs, in the “Scroll Position of Sticky-Positioned Boxes” section of the “CSS Positioned Layout Module Level 3” specification:

For the purposes of any operation targeting the scroll position of a sticky positioned element (or one of its descendants), the sticky positioned element must be considered to be at its offsetted position.

The spec also provides this non-normative example:

For example, if a user clicks a link targeting a sticky-positioned element, if the element’s nearest scrollport is currently scrolled such that the sticky positioned element is offset from its initial position, the scroll container will be scrolled back only the minimum necessary to bring it into its desired position in the scrollport (rather than scrolling all the way back to target its original, non-offsetted position).

When we want to scroll from some position in the scrollport to some element, essentially, we need to have two points: start and end.

What the spec says: both points are considered regardless of the element’s original position. Instead of using the original position, the browser will pretend that everything is static, but as if the current visible position of elements is the truth. Then it will look at the difference between the element’s current position in the scrollport, and calculate the distance we’d want to scroll to put that element to the target position (“scroll snap area”, which is affected by scroll-margin, for example).

Can This Be Useful?

Initially, this behavior baffled me, and I considered this a bug. After discovering that this repeats across all browsers, I had to dig a bit deeper, which resulted in this post.

But I wondered: are there any legit use cases for this weird behavior?

I came up with one: something like a “page down” and “page down” links for some scrollable element. Or, in the below example, “page left” and “page right” — I implemented this for horizontal scrollport because navigation to elements inside nested scrollports is even weirder, and is outside the scope for this post.

Component is not available in RSS, visit the the site to access it.

.example2-scrollport {
	overflow: hidden;
	overflow-x: auto;
	container-type: inline-size;
}

#page-left {
	position: sticky;
	left: -100cqw;
}

#page-right {
	position: sticky;
	right: -100cqw;
}

<div class="example2">
	<a href="#page-left">Page Left</a>
	<a href="#page-right">Page Right</a>
	<div class="example2-scrollport">
		<div id="page-left"></div>
		Start
		<span class="spacer"></span>
		End
		<div id="page-right"></div>
	</div>
</div>

This kinda works? I am unlikely to use this in production, and won’t recommend you as well, but hey.

The way it works is simple: if we know the “size” of a page, we can use a zero-sized sticky element in the corresponding direction, and then set its inset to a negative value equal to this desired page size.

What If I Don’t Want It?

In my case, this was not a desired behavior. What I wanted was to scroll to the original position of the element. Can we somehow achieve this while keeping the sticky positioning?

We can, using one of my recent favorites: a one-time animation. Below is the first example, modified to keep the sticky position, but with its navigation to now properly scrolling up to the original position of such element.

Component is not available in RSS, visit the the site to access it.

@keyframes --unstuck {
	from {
		position: static;
	}
}

.example--fixed {
	&:not(:active) .test:target {
		animation: --unstuck 0.01s 0s both;
	}
}

<div class="example example--fixed">
	<nav class="example-nav">
		Skip to:
		<a href="#A2">A</a>
		<a href="#B2">B</a>
		<a href="#C2">C</a>
		<a href="#D2">D</a>
		<a href="#E2">E</a>
		<a href="#F2">F</a>
		|
		<a href="#top2">Top</a>
		<a href="#bottom2">Bottom</a>
	</nav>
	<div id="top2"></div>
	<div style="height: 200vh"></div>
	<div id="A2" class="test" style="top: 0">A</div
	><div id="B2" class="test" style="top: 100px">B</div
	><div id="C2" class="test" style="top: -100px">C</div
	><div id="D2" class="test" style="bottom: 0">D</div
	><div id="E2" class="test" style="bottom: 100px">E</div
	><div id="F2" class="test" style="bottom: -100px">F</div>
	<div style="height: 200vh"></div>
	<div id="bottom2"></div>
</div>

This mostly helps: clicking on one of the links scrolls the page to the correct place. The only issue is with the “B” element, which might visually jump for a split second. This is because, for positive top value, in this case, the element will never be at its original position. So, when we temporarily disable the sticky positioning, it “returns” there, but then immediately goes back to being sticky. Could this specific issue be the reason this aspect was specified the way it is?

Of course, we could also just throw away sticky when the element has :target, but then for any scroll following this navigation the element won’t be sticky, which is usually not what we expect.

Final Words

I hope that now, if you stumble over a similar issue in your project, you will know why it happens and how it can be potentially fixed.

There are still so many things that are weird about anchor navigation, especially with nested scrollports, with many interop issues. But that’s a topic for another post.

Let me know what you think about this on Mastodon!

Every :has() in my Blog’s CSS

Tue, 26 Nov 2024 00:00:00 GMT

Current music:: Soft Blue Shimmer — Prism of Feeling
Current drink:: Peppermint Tea

In Response To

Miriam Suzanne asked in Mastodon:

What are your favorite little day-to-day use cases for the CSS :has() selector? Anyone using it in their reset yet?

While I don’t have “day-to-day” cases at work (:has() falls outside our browser support for now, and we’re careful around its performance issues), I am using it in a few places for my blog’s CSS.

So, I decided to list all the places in my blog’s styles with brief explanations why I’m using :has() there.

My `:has()` Usage

Adjusting the Grid

.root-grid {
	&:has(.aside-wrapper, aside > details) {
		--min-aside-width:
			calc(var(--ASIDE-WIDTH) * var(--has-aside));
	}
}

The --min-aside-width custom proprety is used in two places: for the CSS grid itself, and for the min-inline-size of the .aside-wrapper. While for the latter it is not necessary to use the :has(), I am just reusing this variable. Why I am using it: to adjust the layout when there is a secondary column present, changing how responsiveness works.

When there is enough space on the page, the main content is always centered. But when there is not enough space, this behavior kicks in. Without aside. The content will continue to be centered, but when it is present, content will shift aside. Five years ago, I wrote a post about a similar layout: “My Grid Layout” — layout there relies on the intrinsic dimensions of things inside columns.

I find :has() to be very convenient for adjusting various aspects of CSS grids. Sometimes, as with the article above, it might be possible to hack around with intrinsic values and comples minmax() and repeating columns, but for simple cases we can often just use :has(). It is more convenient and expressive.

Modifier Shortcut

header {
	&:has(> h1) {
		--ratio: 1;
	}
}

On the main page, h1 is inside the topmost header. On inner pages, it is moved inside the <article>. I could add a class to the header based on the layout, but eh, why not just use :has()? I won’t use this in an enterprise production code, but for my blog? Why not.

The --ratio here just changes some dimensions somewhere, its style is not that important.

Indented Paragraphs

:is(article, blockquote) > p:not(.starts-with-tag:has(> img:only-child)) {
	&,
	& + .aside-wrapper {
		& + p:not(.starts-with-tag:has(> img:only-child)) {
			margin-block-start: calc(-1 * var(--gap));
			text-indent: var(--text-indent);

			& > * {
				text-indent: 0;
			}
		}
	}
}

Ok, this one might be overcomplicated. The idea is to style p + p to have an indentation instead of a gap. Yes, inside my article I am using a CSS grid with gap which defines the basic distance between any elements inside.

But for consecutive paragraphs, I really like the indented text look.

There are a few things going on:

The first :has() is used to check if our paragraph is not one containing just a singular image. In this case, it would be just some illustration, and it should not be considered an actual paragraph.
The .starts-with-tag is there because in CSS all the :NNN-child does not care about text nodes, and I have a custom Astro component for paragraphs in MDX that looks at their content, and if it does not have text nodes in the beginning, adds this class. There is a CSSWG issue about this by ExE Boss — if you want to have a native way to do so as well, please, share your use cases there.
The &, & + .aside-wrapper in the middle is there because we might have an optional .aside-wrapper, which usually interrupts the flow and goes into a sidebar. In that case, we would like to treat the paragraphs that are separated by it as consecutive. This does not work for narrow screen for now; maybe I will fix that case one day.
Because text-indent is an inherited property, and my content can have inline-blocks etc, I need to reset it for anything nested: & > *.

Different Types Of Lists

li + li {
	margin-block-start: 0.25lh;
}
li:has(p) + li {
	margin-block-start: 0.5lh;
}

In some flavors of Markdown, there is a difference whether your list items have an empty line between them or not. Those that care about this difference tend to put the content of more sparse items inside paragraphs. I am using :has() here to modify the margin to replicate this spacing in Markdown.

Hanging Punctuation

:is(ul, ol):has(
	> li.starts-with-tag > a.has-left-overhang:first-child,
	> li.starts-with-tag > p.starts-with-tag:first-child > a.has-left-overhang:first-child
) li {
	padding-inline-start: var(--overhang);
	margin-inline-start: calc(-1 * var(--overhang));
}

li.starts-with-tag:has(
	> a.has-left-overhang:first-child,
	> p.starts-with-tag:first-child > a.has-left-overhang:first-child
) {
	& > a.has-left-overhang:first-child,
	& > p.starts-with-tag:first-child > a.has-left-overhang:first-child {
		margin-inline-start: calc(-1 * var(--overhang));
	}
}

I have many thoughts about hanging punctuation, and I am not talking about the highly restricted and limited hanging-punctuation. Even if it was wider available, I would probably not use it. Well, I would, but also keep all the other similar stuff I’m doing.

This specific example was made specifically for my “bookmarks” posts: they contain lists with links, and I wanted to adjust their styling just a bit.

I don’t know if you ever noticed this when looking at them, but hey. If you did — nice.

Conditional Container

img {
	&.photo {
		max-block-size: min(100vh, 100cqw);
		p:has(> &) {
			container-type: inline-size;
		}
	}
}

I already showed this as a part of my “Embedding Pixelfed, part 2” post, but I did not explain what it does.

I am using a CSS grid where all content goes inside a middle column. But for images inside a lonely paragraph, I want to limit their width by the width of the content area, so I need to have a container on the paragraph. While I could apply the containment to all paragraphs, I decided to do it only for these that need it.

Bleed Layout for Images

p.starts-with-tag:has(> img:only-child) {
	margin-inline: calc(-1 * var(--content-padding));
}

I already mentioned this case where I excluded paragraphs with lonely images, now we target them and use the custom property for the content padding to make them go full-width. For an example, you can peek at the beginning of my “Embedding Pixelfed, part 2” post that I already mentioned above.

Figure Decorations

figure {
	&:not(:has( > figcaption))::after {
		inset-block-end: 0;
	}
}

The way I style <figure> and <figcaption> probably deserve a separate post, but in short: when there is a figcaption, I draw a border via an ::after pseudo-element, making it wrap everything except for the figcaption. When there is no figcaption, I need to adjust the position of the bottom edge of this decorative element.

.table-of-contents {
	&:hover,
	&:has(:focus-visible) {
		z-index: 1;
		opacity: 1;
	}

	&:has(> details[open]) {
		--toc-margin: var(--DOUBLE-PADDING);

		transform: /*…*/;

		&:hover,
		&:has(:focus-visible) {
			transform: /*…*/;
		}
	}
}

My table of contents also deserves an extra post for sure. In this case, the :has(:focus-visible) works basically like non-existent :focus-visible-within. But hey, look at this CSSWG issue by David Baron. You know what to do if you want this as well.

And another usage here is for checking if my ToC contains an opened <details>

Conclusion

Most of my usage for :has() are shortcuts for something that could, potentially, be done either by manually hardcoding the modifiers, or by ~~parsing~~ regexping the content and adding classes similar to .starts-with-tag.

But :has() allows doing this declaratively from CSS. Which is nice, but can have performance issues. Still good enough for a hobby project.

The only cases above that cannot be done without relying on JS are for anything dynamic: the :has(: focus-visible) and :has(details[open]). These are prime use cases for :has(), and even though in some cases JS could still be more performant, these are very fun to apply from CSS.

Let me know what you think about this on Mastodon!

Observation: CSS Math Eval

Thu, 28 Nov 2024 00:00:00 GMT

Current music:: how to count one to ten — news paper
Current drink:: Peppermint Tea

This is just a quick idea that I had recently, and decided to write down. Look at this:

Component is not available in RSS, visit the the site to access it.

<css-math>
	<input type="text" value="2 + 2" />
	=<output></output>
</css-math>

<css-math>
	<input type="text" value="sin(90deg)" />
	=<output></output>
</css-math>

<css-math>
	<input type="text" value="(pi - 1) * 2" />
	=<output></output>
</css-math>

This is a calculator? I guess? If you wonder: “What is special about it” — there was one problem that I wanted to solve.

That problem: evaluating some math expression from user input in a very safe way. I know, there exist external libraries people did already write which could do this job well enough. But I wanted something minimal and with no dependencies. And hacky.

Enter CSS, registered custom property, and calc():

Component is not available in RSS, visit the the site to access it.

<script>
	CSS.registerProperty({
		name: '--css-math',
		syntax: '<number>',
		inherits: false,
		initialValue: 0,
	});
	class CSSMath extends HTMLElement {
		getResult(el) {
			this.style.setProperty(
				'--css-math',
				`calc(${el.value})`
			);
			return getComputedStyle(this)
				.getPropertyValue('--css-math');
		}
		connectedCallback() {
			const input = this.querySelector('input');
			const output = this.querySelector('output');
			setTimeout(() => {
				output.value = this.getResult(input)
			}, 0);
			input.addEventListener('input', ({ target }) => {
				output.value = this.getResult(target);
			});
		}
	}
	customElements.define('css-math', CSSMath);
</script>

This is far, far, far from being a good implementation. Among other things, it accepts only what CSS can: 2 + 2 works, but 2+2 does not.

I imagine, it might be possible to throw a quick regex that would normalize the input to be easier accepted by the thing, but hey, this is just a quick idea, and a quick post.

If you’re wondering what’s going on inside, we register a custom property in CSS, then put our user input inside a calc(), and set this property on our element. And then read the resulting value: because the custom property is registered, we will get the already calculated value!

The main problem of this method is that it is slow. After all, you have to set a property, and then run a getComputedStyle() on it.

But I still think that this is neat: calc() is so powerful in CSS today, and allows throwing many different things into it, and is continously improved.

While writing this post, I got an even wilder idea about how this could be “improved”, but, I guess, let me save it for another observation-type post.

And, maybe, before that, you could tell me: how wacky is this? Do you wish we had a safe native way to evaluate math expressions in JS, without eval(), new Function() etc? Do you know a better way to achive the same, which would be as full of features as math in CSS?

Let me know what you think about this on Mastodon!

Short Lines, Bad Breaks, and CSS

Wed, 27 Nov 2024 00:00:00 GMT

Current music:: Daughter — Dandelion
Current drink:: Peppermint Tea

The Problem

In today’s CSSWG meeting, there was one issue about the new value of text-wrap-style property — avoid-orphans (originally by Simon Owen, in the agenda regarding an addition of it to the spec by Florian Rivoal).

When going through the list of issues in the agenda before the meeting, I saw this issue, and it reminded me of one typographic thing that I had been thinking about for quite a while: the weirdness of the “widows” and “orphans” terms.

I never could remember them, even when people mentioned various mnemonics. And then, whenever in some typographic context people mentioned “eliminate widows”, without that context, it sounded pretty bad.

I was glad that I am not the only one who did not like this term: this year I bought the third edition of Ellen Lupton’s “Thinking with Type”, and was pleasantly surprised when she brought this up in the “Short Lines” chapter (starting from page 128):

In English, short lines are often called widows and orphans. When used as epithets, these terms are sexist and insensitive. Neutral descriptions like “short line” or “bad break” are respectful and easy to understand.

I read the whole book, and can happily recommend it to everyone, by the way.

Beyond the terms being insensitive, there is another problem that I mentioned in the beginning: these terms are just plain confusing. If you go to the Wikipedia page about them, here is what you will find in how it defines these terms:

Widow (sometimes called orphan)

A paragraph-ending line that falls at the beginning of the following page or column, thus separated from the rest of the text. Mnemonically, a widow is “alone at the top” (of the family tree but, in this case, of the page).

Orphan (sometimes called widow)

A paragraph-opening line that appears by itself at the bottom of a page or column, thus separated from the rest of the text. Mnemonically, an orphan is “alone at the bottom” (of the family tree but, in this case, of the page).

Runt (sometimes called widow or orphan)

A word, part of a word, or a very short line that appears by itself at the end of a paragraph. Mnemonically still “alone at the bottom”, just this time at the bottom of a paragraph. Orphans of this type give the impression of too much white space between paragraphs.

Just look at these parentheses! No wonder, I was confused for so long: likely, I looked at different sources inconsistently calling the same thing different names.

Even more: if we look at the definitions of “widows” and “orphans” in this Wikipedia article, we’ll see that the proposed avoid-orphans is about neither! It is about the third case, which in this article is called “runts”. And, which, unsurprisingly, also can be used as a derogatory term (see third definition). This was also the first time I heard this term in a typographic context, so I just flipped through a few books on typography from my bookshelf and did not find it mentioned there.

Opening Issues

Anyway, stumbling upon this issue today made me remember this grip I had with the terms, so I both commented on the issue, and then later brought all of that up in the discussion.

There was agreement that we should look for a better name, and open a separate issue about this, which I did. Spoiler: my suggested name for this value is avoid-short-lines, but if you have a better name (or just agree) — please, participate there.

In the discussion, it was mentioned that CSS already has two other properties: orphans and widows. Oh wow, I completely forgot that we had these! Likely, because their support is still not there, with Firefox missing, and in browsers that claim to support them, it appears to be uneven. See this test example by Peter-Paul Koch and compare how things render in Safari vs Chrome. There was also an Interop 2023 proposal related to this by Scott Kellum.

After some thought, I decided to open an issue about renaming (and maybe reimagining?) them too: “Rename and/or reimagine widows and orphans”. Given that they’re not interoperable today, we could retire them (well, keep them deprecated by “working” where they do now), and come up with both better names, and perhaps better behavior (if needed).

Final Words

Let me copy the last two paragraphs from that second issue:

This could be a good opportunity to discuss these differences, why they’re there, and if we could come with a consensus which all browsers could agree on, so we could move forward.

Both avoiding short lines, and avoiding single leading or trailing lines in fragments are something I (and many other developers) wanted to have for a while, so it would be great to get closer to it.

Do you have an opinion about this? Were you also confused about these terms? Did you want to use them in your code? Please let me know, or — even better — comment in these issues.

Let me know what you think about this on Mastodon!

CSS Math Eval, now Better and Weirder

Fri, 29 Nov 2024 00:00:00 GMT

Current music:: Uchu Conbini — 体温
Current drink:: Peppermint Tea

A Better Solution

After the yesterday’s “Observation: CSS Math Eval” post, I got a mastodon reply from Valtteri Laitinen (in a reply thread started by Kilian Valkhof):

Seems that you can use
CSSNumericValue
	.parse(`calc(${el.value})`)
	.to('number').value
instead of the custom property and getComputedStyle(). That isn’t supported by Firefox though.

When I was experimenting for my original post, I briefly looked at the CSSOM, but did miss the .to('number') method! I suspected that it should provide something similar, and I am happy that it exists, and that Valtteri pointed it out to me!

For browsers that support CSSNumericValue, this is a much better solution, as it does not require getComputedStyle(), and thus should not cause a layout recalculation.

Here is the example from the last article, now using CSSNumericValue when it is available:

Component is not available in RSS, visit the the site to access it.

<css-math-2>
	<input type="text" value="2 + 2" />
	=<output></output>
</css-math-2>

<css-math-2>
	<input type="text" value="sin(90deg)" />
	=<output></output>
</css-math-2>

<css-math-2>
	<input type="text" value="(pi - 1) * 2" />
	=<output></output>
</css-math-2>

<script>
	CSS.registerProperty({
		name: '--css-math-2',
		syntax: '<number>',
		inherits: false,
		initialValue: 0,
	});
	class CSSMath2 extends HTMLElement {
		getResult(el) {
			if ('CSSNumericValue' in window) {
				return CSSNumericValue
					.parse(`calc(${el.value})`)
					.to('number').value
					+
					' (using CSSNumericValue)';
			}
			this.style.setProperty(
				'--css-math-2',
				`calc(${el.value})`
			);
			return getComputedStyle(this)
				.getPropertyValue('--css-math-2')
				+
				' (using getComputedStyle)';
		}
		connectedCallback() {
			const input = this.querySelector('input');
			const output = this.querySelector('output');
			setTimeout(() => {
				output.value = this.getResult(input)
			}, 0);
			input.addEventListener('input', ({ target }) => {
				output.value = this.getResult(target);
			});
		}
	}
	customElements.define('css-math-2', CSSMath2);
</script>

A Better Fallback

However, if we’re talking about fallbacks, my original method was still far from being perfect: after all, registerProperty has a worse support.

Can we have a better fallback for it? Yes, if instead of using a registered custom property, we will use a regular property that accepts a <number> syntax:

Component is not available in RSS, visit the the site to access it.

<css-math-3>
	<input type="text" value="2 + 2" />
	=<output></output>
</css-math-3>

<css-math-3>
	<input type="text" value="sin(90deg)" />
	=<output></output>
</css-math-3>

<css-math-3>
	<input type="text" value="(pi - 1) * 2" />
	=<output></output>
</css-math-3>

<script>
	let propertyToCheck = 'border-image-outset';
	if ('registerProperty' in CSS) {
		propertyToCheck = '--css-math-3';
		CSS.registerProperty({
			name: propertyToCheck,
			syntax: '<number>',
			inherits: false,
			initialValue: 0,
		});
	}
	class CSSMath3 extends HTMLElement {
		getResult(el) {
			if ('CSSNumericValue' in window) {
				return CSSNumericValue
					.parse(`calc(${el.value})`)
					.to('number').value
					+
					' (using CSSNumericValue)';
			}
			this.style.setProperty(
				propertyToCheck,
				`calc(${el.value})`
			);
			return getComputedStyle(this)
				.getPropertyValue(propertyToCheck)
				+
				` (using ${propertyToCheck})`;
		}
		connectedCallback() {
			const input = this.querySelector('input');
			const output = this.querySelector('output');
			setTimeout(() => {
				output.value = this.getResult(input)
			}, 0);
			input.addEventListener('input', ({ target }) => {
				output.value = this.getResult(target);
			});
		}
	}
	customElements.define('css-math-3', CSSMath3);
</script>

Just for fun (and because it is unlikely to clash with anything usually), I used the border-image-outset property. Did you know about its existence? It is there for as long as calc(), which we also need for things to work.

A Weird Solution: Calculated `initial-value`

Before I got to know about CSSNumericValue, I was playing with various ways to improve the performance of my initial method. I found a thing about which I did not know about, but which seems obvious in hindsight.

We can use calculations for initial-value of registered properties! Here is my original example which uses this method:

Component is not available in RSS, visit the the site to access it.

<css-math-weird>
	<input type="text" value="2 + 2" />
	=<output></output>
</css-math-weird>

<css-math-weird>
	<input type="text" value="sin(90deg)" />
	=<output></output>
</css-math-weird>

<css-math-weird>
	<input type="text" value="(pi - 1) * 2" />
	=<output></output>
</css-math-weird>

<script>
	const mathCache = new Map();

	class CSSMathWeird extends HTMLElement {
		getResult(el) {
			const result = mathCache.get(el.value);
			if (result) {
				return result;
			}
			const name =
				`--css-math-weird-${mathCache.size}`;
			CSS.registerProperty({
				name,
				syntax: '<number>',
				inherits: false,
				initialValue: `calc(${el.value})`,
			});
			const value = getComputedStyle(this)
				.getPropertyValue(name);
			mathCache.set(el.value, value);
			return value;
		}
		connectedCallback() {
			const input = this.querySelector('input');
			const output = this.querySelector('output');
			setTimeout(() => {
				output.value = this.getResult(input)
			}, 0);
			input.addEventListener('input', ({ target }) => {
				output.value = this.getResult(target);
			});
		}
	}
	customElements.define(
		'css-math-weird',
		CSSMathWeird
	);
</script>

Ok, this one is very inefficient: we need to maintain a cache for the values (so we won’t attempt to register the same custom property twice, which is prohibited), and I don’t even want to know how the browser will behave if we will suddenly register hundreds of unused custom properties.

But hey, it works! Not sure what can be the practical purpose of this, though.

Room for Improvement

There are still many things that something like this will require for it to be a viable reusable solution.

But now I know about CSSNumericValue! I hope we will get it in all browsers, eventually. Mozilla is positive about CSS Typed OM, so, hopefully, someone will eventually implement it there.

It is fascinating how by implementing a powerful feature like this one in CSS, we unlock it not only there, but also for JS as well. Can it be viable to propose a native JS method for evaluating CSS math?

I’m also happy that I wrote the original post, even though the idea was very wild and unpolished. It might help someone (like Kilian), and now we know more about CSS and its API.

Let me know what you think about this on Mastodon!

Embedding Pixelfed, part 3

Sat, 30 Nov 2024 00:00:00 GMT

Current music:: Haisuinonasa — Forest and lighting
Current drink:: Lapsang Souchong tea

Since Last Update

While I did not do everything from the “To Do Next” of my last update, I did most of it.

Now, if I provide a caption in the markdown, like this:

![A horizontal photo](pixelfed:740944759087514268/4)

It will render as a <figure> with a <figcaption>:

“A horizontal photo” (image is not available in RSS, visit the the site to access it.)

It will also work with vertical photos, in which case I am trying to make either have similar dimensions, as if I would just stretch a vertical photo to the content width, it will overwhelm everything around it.

“A vertical photo” (image is not available in RSS, visit the the site to access it.)

You might’ve noticed a “See details” link under both, and maybe even interacted with it.

This part is not yet finished, but was also something I mentioned I wanted to do: a full-page view for any photo. For now, it is handled with just CSS and some in-page anchor links, but there are a few things I’d want to enhance.

Next Time

I want to enhance it with some Popover API:
- Right now it is using position: fixed, but it would be better to put it into the top layer.
- It will also provide esc for closing it from the box.
I would like to add buttons for going to the next/prev photos on the page.
- This is complicated, as if I’d want to do it without client-side JS, I’ll need to gather all the photos on the page in Astro, and then use this when rendering the images.
I did try, but did not finish making a list with thumbnails.
- For it, I’d need to conditionally render the image and its figure differently.
- However, in Astro, there is no such thing as context. So I’ll need to do something differently. Likely, reuse what I’ll do for prev/next buttons, and will try to detect the images’ context when parsing their markdown.
The visuals for the full-page view are not final. Well, nothing is, but it’s even more.
- I’ll need to add more metadata, handle responsiveness better, work on margins, etc.
I wonder if I could add view transitions, for browsers that support them?

Again, there are also tons of other things that I’d want to do, but I think I am close to a state where I could actually start using this!

End of November

This is the last post of November. I guess, I managed to do all 30 posts this month. Some — good, some — meh.

Whiel I did not manage to plan all of them in advance, I tried to play with different ways of setting up the next ones by having these process posts.

Posting what I did and, especially, what I plan to, really helps to continue the work. It makes it easier to get into the context of what I did, and then provides a few starting points. I’ll try to continue doing updates like these in the future.

Let me know what you think about this on Mastodon!

Splash Colour Mixin

Thu, 26 Dec 2024 00:00:00 GMT

Current music:: Nuito — NeKoMaJiN Vs
Current drink:: Jasmine Green Tea

The Context

Two days ago, I published a new article: “Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins”. It is long, but might be a necessary context for today’s post. If you did not yet check it out: please, do!

Anyway. In that article, I presented a way to prototype native CSS mixins with what we have in CSS today: custom cascade layers, and a new technique based on how cyclic dependencies work for custom properties.

Unlike my previous steps toward this — “Layered Toggles: Optional CSS Mixins” — the new technique allows us to call a mixin with at least one parameter!

The increase in usefullness is infinite: 0 → 1. An ability to assign just one custom property — and provide the value at the same time — makes me want to do everything in this way now.

So, in the last two days following the publication of this article, I am already testing it for various things, and written at least two relatively complicated mixins based on it.

In this post, I will write about one of them.

The Splash

Three days ago, Lu Wilson published an experimental colour format: Splash. It is a simple idea: to express RGB in just three decimal digits, with an explicitly loose definition over how it should be converted into the actual color, with an invitation to adjust and play with it.

Coincidentally, after publishing my article about mixins, and talking a bit with Lea Verou, she nerd-sniped me into playing with colors for a bit.

So later, when I read about Splash, I immediately saw what I’d want to do with it. Because in my color experiments, I was looking into how we could map and convert colors when we have only their components. And a format being just a three-digit number makes it straightforward to work with. If it had any letters in it, it would be much harder to work with in CSS!

The Mixin

The original experimental mixin is available on CodePen, but I’ll present it here as well, and will try to explain it a bit further.

I think it is a good demonstration of what might be possible with native mixins.

Component is not available in RSS, visit the the site to access it.

<p style="position: sticky; top: 0;">
	<em style="--splash-bg: 967">pink</em>
	<span style="--splash-bg: 342">dark olive</span>
	<strong style="--splash-bg: 277">turquoise</strong>
	<strong style="--splash-bg: 999">white</strong>
	<strong style="--splash-bg: 000">black</strong>
</p>

@layer splash { * {
	/* Our input, with a list of “dependencies” */
	--splash-bg:
		var(--_splash-bg-value)
		var(--_splash-shadow)
		var(--_splash-color);

	/* Extracting the color components from the input */
	--_splash_r: round(down,
		var(--splash-bg) / 100,
	1);

	--_splash_g: round(down,
		(var(--splash-bg) - var(--_splash_r) * 100) / 10,
	1);

	--_splash_b: calc(
		var(--splash-bg)
		-
		var(--_splash_r) * 100
		-
		var(--_splash_g) * 10
	);

	/* Normalizing the values to regular rgb: any changes and adjustements can go here */
	--_rgb_r: calc(var(--_splash_r) * 255/9);
	--_rgb_g: calc(var(--_splash_g) * 255/9);
	--_rgb_b: calc(var(--_splash_b) * 255/9);

	/* Assigning the actual value for the background color. */
	--_splash-bg-value:
		rgb(var(--_rgb_r), var(--_rgb_g), var(--_rgb_b));
	background: var(--_splash-bg-value, revert-layer);

	/* By default, adding a text-shadow (might be overridden later) */
	--_splash-shadow:
		var(--WHEN, if(style(--_splash-bg-value: var(--_splash-bg-value)):))
		Canvas 1px 1px 0px,
		Canvas -1px -1px 0px,
		Canvas 1px -1px 0px,
		Canvas -1px 1px 0px;
	text-shadow: var(--_splash-shadow, revert-layer);

	/* If the browser supports relative colors, use them to assign a color instead of a shadow */
	@supports (color: oklch(from red l c h)) {
		--_splash-l: clamp(
			0,
			(l / var(--l-threshold, 0.71) - 1) * -infinity,
			1
		);

		--_splash-color:
			var(--WHEN, if(style(--splash-bg: var(--splash-bg)):))
			oklch(
				from var(--_splash-bg-value)
				var(--_splash-l) 0 h
			);

		color: var(--_splash-color, revert-layer);
		text-shadow: revert-layer;
	}
} }

Here is what this mixin does:

On any element, we can add a --splash-bg custom property with a three-digit number.
Doing so will enable the “mixin”: the background and text-shadow or color properties will be applied. Without the --splash-bg, thanks to custom cascade layers and revert-layer, these properties will not have any effect on anything evben though we apply them via *.
In addition, as we know the background color, we can try using relative colors to assign a contrasting text color alongside that background! This is thanks to the “On compliance vs readability: Generating text colors with CSS” article by Lea Verou.

I won’t explain what’s going on there in detail: aside from what is explained in all the linked articles, there is nothing too complex going on.

The remaining most interesting part is splitting the incoming three-digit color into three components. There might be a better way to do it, but I used the very helpful round() CSS function for this, plus some math.

Some Lessons

When I did this experiment, I left some notes to myself.

When we do mixins like that, because we can return any number of properties, it is easy to add something extra — like the contrasting color in addition to the background that we know. This would be not a case with custom functions, or anything that involves only custom properties.
If we were to implement “OKSplash” based on OKLCH — that is, we had three pure components for the perceived Lightness, color’s Chroma, and its Hue — we could skip the relative color part, and calcualte the color directly.
When we’re inside an @layer, using revert-layer for things inside an @supports or other overrides feels very natural and lifts some weight from the mind: we completely revert the declaration, instead of overriding it to some default.
Initially, I saw the intermediate step required for the mixin to work — where we define our value for the property as a separate custom property — as a downside. However, when it is done this way, it is effortless to then reuse this value. In this case, I did not have to change the existing code I wrote for the mixin to use this color to get the contrasting one.
When I use round() for regular numbers, I always forget the 1 in the end. This was a change based an issue by Oriol Brufau, but it is not yet available in all browsers. Testing helps!

That’s It

I really like how we can hide a lot of the complexity behind a simple custom property call. Can we have native mixins already in all browsers, so I won’t have to write these adominations?

Please, sponsor Oddbird so Miriam Suzanne could work more actively on the specs for native mixins!

And — experiment. I am already looking to write another post — or maybe an article on my main site — about another useful way we could use these mixins for. And I am not planning to stop. So I nudge you to try doing this as well. It is fun.

Let me know what you think about this on Mastodon!

CSS Mixins Everywhere

Wed, 29 Jan 2025 00:00:00 GMT

Current music:: kinoue64 — tomorrow, the world will end.
Current drink:: Herbal tea (“Tisane Fruits exotique”)

On Monday, I published a new article: “Pure CSS Mixin for Displaying Values of Custom Properties”. It is a long one, but you don’t have to read it fully to get something out of it, as I also published an npm package that allows you to use the mixin described in the article right away.

The mixin itself is for debugging stuff, and one way I envisioned it being used: have a template on CodePen that would include the mixin. Not super convenient (need to pre-select the template, can’t be used with other pre-existing CodePens, etc.), but works. It is also possible to just drop the

@import
	url("https://unpkg.com/@kizu/mixins@0.2.1/preview.css");

I also included it in this blog, though, importing from node_modules instead of using the CDN. So now it is possible to preview any values here as well:

Component is not available in RSS, visit the the site to access it.

<div style="--preview: pi"></div>

But then… I wondered. What if this mixin was available everywhere in my browser?

I am a fan of CSS overrides in general, and I am using the Stylus extension for this (for Firefox, for Chrome).

What if I would just… add a global override that would be available on every page, and will include the mixin? Now I can just open devtools on any page, add --preview to any element, and “inspect” any values! Or, when doing stuff in a CodePen, I can just use --preview as if it were available natively for me.

Of course, this will be something visible only to me, so if I would want to share such a CodePen with the previews visible, I would need to remember to include the mixin itself as well. But — for the most part, this mixin is purely for debugging. So why not have it available always?

This is the power of CSS mixins: if they do not do anything until you call them, we can always add them and use them when we see fit. A mixin like --preview becomes like a custom browser extension, made with just CSS!

And imagine when we will have native CSS mixins! We could do the same with them: include them always via overrides, and use them for debugging on any page.

Finally, this can be a great way for me to test how robust the mixin’s code is: does it introduce any performance overhead? Will it break in some cases? How annoying is it to have its styles always there in an inspector? Do I want to scope it in some way for this kind of usage, so I would have to add a custom class around something I want to debug?

I am excited to try this out, and adjust the mixin with what I will find. And if you will try this method as well — you’re welcome to, but be warned that it is highly experimental. But then — please, let me know if you have any feedback about it!

Let me know what you think about this on Mastodon!

Photo Walk in December

Wed, 15 Jan 2025 00:00:00 GMT

Current music:: Mammal Hands — Late Bloomer
Current drink:: Pepperming Tea

I have a big backlog of photos, and now that I have an ability to embed them in my blog, I will occasionally do so!

I am initially posting them on Pixelfed, and this post was originally published there. Pixelfed is cool, maybe you should join it, and post photos there, and not somewhere else. If you’re publishing them on your site — reposting them on Pixelfed could also be a good idea.

Anyways.

On December 25 of last year, on the next day after publishing my latest article — “Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins” — I went for a walk in a nearby park.

It is usually hard for me to go outside, but I got this habit recently: after I finish an article, I just try to go for a walk. Either on the same day, or the next one. This led to my Pixelfed account having a bit more photos than usual in the last few months!

This time, there was another reason to go and take some photos — I bought myself a new lens. I am using an Olympus OM-D E-M5 Camera — the Micro Four Thirds one from 2012.

Usually, I use the Olympus M.Zuiko Digital 45mm f/1.8 lens, but this was my first time trying their 25mm version. It was nice, although I got too used to the 45mm one.

It was a nice walk, during twilight, after the sunset. I think, the park was closing soon, but hey, the gates were open, and there were people still inside, so I did sneak in for a bit.

The park is near Château de Saint-Germain-en-Laye and has a long terrace that overlooks the towns below that stretch up to Paris on the horizon.

There were either low clouds, or fog, or smog on the horizon — usually it is possible to see the Eiffel Tower there, on the right from La Défense. This time you couldn’t see them.

But at this time you could see the city with the night lights starting to appear here and there, with cars driving on the bridge over the Seine somewhere below. It was a pleasant evening.

Let me know what you think about this on Mastodon!

Intent to Experiment for Longer

Tue, 25 Feb 2025 00:00:00 GMT

Current music:: Ann Annie — By Morning
Current drink:: Peppermint Tea

Today, Chrome published two “intents to ship”: for the new CSS if() function, and for custom CSS functions.

I informally object to this.

Intent to prototype the if() function was less than a month ago. Its TAG review has no resolution.

Intent to prototype custom functions was a year ago, and while there was some prototyping at the time, the new version of what is currently in Canary was started only in the last month. Its TAG review has no resolution as well.

Given how foundational and crucial these features are — I would strongly recommend Google to re-think how they’re planning to ship these features.

Just last year we had a situation where anchor positioning was shipped prematurely, with very substantial changes to its syntax later based on the later feedback. And this was after the feature was in a prototype stage for much longer than both if() and custom functions.

The absense of open issues in CSSWG for these features cannot be taken as a signal that they are ready to ship: authors just started to play with them, and I am not sure engineers and CSSWG members from other browsers had a chance to take an in-depth look into the specs and play with the prototypes just yet.

I am very biased: I want these features more than many others. My first article about “Conditions for CSS Variables” was in 2016.

In 2023 and 2024 I published four articles about various ways we could write conditional CSS, prototyping conditions, functions and mixins:

For a few years, from around 2013 to 2016, I was also a maintainer of the Stylus CSS preprocessor. I wanted conditions, functions, and mixins for a long, long time.

And yet, I don’t want them to ship in Chrome — not right now.

I want these features to be in their perfect form when they ship. Maybe not complete — but one where we’re all certain that what we have will not change, and will be future-proof.

Just a month since the prototype to shipping the features is many months too soon. I just had a bit of time to play with them. The feedback that I have is already brewing in me, but I’ll need more time to express it properly. Other authors, I am pretty sure, will need this time too.

If Chrome is to ship these features in their stable browser versions — at the very least — do so under a feature flag that is disabled by default. Let authors play with the features, let other browsers to look into them and consider various use cases, let the Web Platform take a few breaths — and then think about shipping the features for real.

Please. Let us experiment with these features for longer.

Let me know what you think about this on Mastodon!

Future-Proofing Indirect Cyclic Conditions

Sat, 31 May 2025 00:00:00 GMT

Current music:: Rökkurró — Innra
Current drink:: Yunnan Tea

When working on another blog post, I noticed that my blog’s styles were broken in Chrome Canary.

What happened? A change in how “short-circuiting” of custom property fallbacks works.

The Context

For a bit of context, see “Short-circuit if() evaluation” issue by Anders Hartvoll Ruud in which CSSWG resolved in February to specify a new parsing behavior for all substitution functions. Including custom properties.

Before that change (and what is currently happening in all browsers), the algorithm for the dependency graph between custom properties in the specs included the mention of the fallbacks:

For each element, create a directed dependency graph, containing nodes for each custom property. If the value of a custom property prop contains a var() function referring to the property var (including in the fallback argument of var()), add an edge between prop and the var.

If there is a cycle in the dependency graph, all the custom properties in the cycle are invalid at computed-value time.

The most recent Editor’s Draft for CSS Values and Units Module Level 5 does not mention this and contains a rewritted set of custom property substitution rules.

The corresponding change followed the spec and landed in Chrome Canary in a commit from May 15 . It was known that this will break backwards compat for anything that used this for reasons. However, the only reason we could think of at the time was my hacky technique: “Indirect Cyclic Conditions”, so we decided to try this, adding a use counter to track the usage of these fallbacks.

Anders did a thorough compat investigation of pages that this use counter found.

Of course, my technique was spotted by this use counter, and was mentioned in the investigation:

Roman invented a terrible (but great) mixin technique which relies on short-circuiting not happening […] This change would definitely break that approach, but Roman was part of the CSSWG decision to make this change, and has accepted the breakage.

But other than this, the findings do now show any highly problematic use cases, and, if anything, this change could fix some of them.

Well, my blog and some articles on the main site broke, but — I knew about it — and it’s time to find a workaround!

The Workaround

One of the reasons I was ok with this change — the only use case for this past behavior that I found was for doing conditionals. With if() function being accepted — and even already shipped in Chrome 137 — we will eventually have a proper way of doing conditions, in a much more simple and non-hacky way.

But — the changes required to make if() performant lead to the past behavior — one my technique relied upon — to break. Can we somehow make it continue to work, while still using my technique for browsers that do not yet understand native conditions?

The first idea I had was to just use @supports and override the definition of the custom property that uses the --WHEN in code to use an if() instead. Note that we cannot use a regular override like

--color: pink var(--WHEN, var(--condition));
--color: if(style(--condition): pink);

as for non-registered custom properties (which we have), they accept anything, and even if the browser does not know about if(), it will only ever use the second declaration here. So, we need an @supports.

Let’s look at a minimal example that uses my technique:

Component is not available in RSS, visit the the site to access it.

.example1 { --WHEN: }
.example1 .minimal {
	--input: var(--bg-value);
	--bg-value: var(--GREEN) var(--WHEN, var(--input));
	background: var(--bg-value, var(--PINK));
}

<div class="minimal">Pink</div>
<div class="minimal" style="--input: 1">Green</div>

If you look at this example today in Chrome Canary with the Experimental Web Platform Features flag on, you’ll see that it does not work: the first element there should be pink, as the always defined --WHEN means it will not go to the fallback, and will make the --bg-value valid for all cases.

Simple Fallback

Just adding a fallback with @supports works:

Component is not available in RSS, visit the the site to access it.

.example2 { --WHEN: }
.example2 .minimal {
	--input: var(--bg-value);
	--bg-value: var(--GREEN) var(--WHEN, var(--input));

	@supports (top: if(():)) {
		--bg-value: if(style(--input): var(--GREEN));
	}

	background: var(--bg-value, var(--PINK));
}

<div class="minimal">Pink</div>
<div class="minimal" style="--input: 1">Green</div>

However, it is a bit verbose — we have to repeat the declaration, and repeat everything inside as well, just in a different form.

Can we somehow keep just one declaration?

Complex Fallback

We can, but we need to do two things:

Define --WHEN conditionally.
Adjust how we use it.

Component is not available in RSS, visit the the site to access it.

.example3 {
	--WHEN: ;
	@supports (top: if(():)) {
		--WHEN: initial;
	}
}

.example3 .minimal {
	--input: var(--bg-value);
	--bg-value:
		var(--GREEN)
		var(--WHEN, if(style(--input: var(--input)):));

	background: var(--bg-value, var(--PINK));
}

<div class="minimal">Pink</div>
<div class="minimal" style="--input: 1">Green</div>

Here, our definition of --WHEN with @supports will need to be added just once, and then, whenever we want to add this condition, we could do it by wrapping the value inside --WHEN’s fallback in a special if().

Why this will work:

When if() is supported, the --WHEN will be initial, so we will skip to the fallback. Then, we will check for the --input — and this check might create our short circuit if the --bg-value will reference it as expected, or, with almost any other valid value, will result in a “space” value as any value will be equal to itself.
When if() is not supported, the browser will still accept all the tokens, but will try to substitute all the custom properties, and will see the var(--input) inside the --WHEN’s fallback, which might create the short circuit.

This requires us to repeat the --input’s name, but otherwise it’s coincise enough.

An Unrelated `tan(atan2())` Breakage

Curiously, literally while I was working on this article, Oddbjørn Øvernes reported an issue with “Pure CSS Mixin for Displaying Values of Custom Properties” that uses this technique in Chrome. However, it was in stable Chrome, and unrelated to short-circuiting. After some debugging, I found out that it was an issue with how it handles tan(atan2()). I already published a 0.2.1 version of this mixin that has both issues fixed in it, and reported the bug to Chromium.

Final Words

Who could’ve guessed that hacky code could have issues? Well, in this case we knew about it, and now accounted for it (although, I will still need to update the “Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins” article with the corresponding changes).

And, now we now have a way to continue using this hacky — but mostly cross-browser — technique for a subset of inline conditions that check for an existance of some value.

I still hope you won’t use it in production!

Let me know what you think about this on Mastodon!

Functional Capturing

Tue, 03 Jun 2025 00:00:00 GMT

Current music:: mudy on the sakuban — Newtype Theory
Current drink:: Jasmine Green Tea

The Context

Chrome currently has an experimental implementation of custom CSS functions in its Canary version and also recently shipped if() conditions in stable Chrome 137.

In February, I wrote a quick post about them: “Intent to Experiment for Longer” — more specificlaly, about how it is better to wait before shipping the features without sufficient developer feedback.

One thing I forgot to mention in that post: the features, as far as I tested them, worked pretty well, and I generally liked their design. My main blocker that was there for functions — a necessity to explicitly define dependencies for functions — was resolved to be removed (official resolution: “Kill using with fire”), and, with it, I did not yet find any other personal blockers, for now.

That said: even when the design and implementation are sound, with the Web Platform it is always better to be on a more cautious side, especially with foundational features. And while I did not yet find any other blocking issues, this does not mean they do not exist. I would be happy if there are none! But if you’re a web developer: please, play with these new features, and give your feedback.

In a small series of blog posts, I’ll write about a few things I found interesting in the current prototype implementations of functions and conditions.

This post is about one feature of custom functions that I will likely use all the time, but which might not be obvious at the first glance.

Basic Capturing

Before continuing, I recommend reading my “Captured Custom Properties” post, in which I talk a bit about the registered custom properties, some use cases for them, and a pattern I currently use with them.

With custom functions, some of those use cases could be solved much more elegantly!

Let’s look at one example from my “Captured Custom Properties” post.

Registered Custom Property Example

In this example, we can use a custom property to “evaluate” its value on the element, so it will store the value of 1.5em in pixels, so it could be used on its children through inheritance.

Component is not available in RSS, visit the the site to access it.

@property --registered-font-size {
	syntax: "<length>";
	initial-value: 0px;
	inherits: true;
}

.example-reg {
	font-size: 0.666em;
	--registered-font-size: 1.5em;

	& span {
		font-size: var(--registered-font-size);
	}
	& .inner {
		font-size: 2em;
	}
}

<div class="example-reg">
	<em>Outer:</em> <span>Foo</span>
	<div class="inner">
		<em>Inner:</em> <span>Bar</span>
	</div>
</div>

This is great, and while my pattern of having a dedicated suit of registered custom properties works well, we have to register new custom properties whenever we want to use multiple of them on the same element.

Even though you cannot register a custom property from inside a custom function, one of their features works similarly, and we can use it to simplify things a lot.

Custom Function Example

Component is not available in RSS, visit the the site to access it.

@function --capture-length(--value <length>) {
	result: var(--value);
}

.example-fun {
	font-size: 0.666em;
	--captured-font-size: --capture-length(1.5em);

	& span {
		font-size: var(--captured-font-size);
	}
	& .inner {
		font-size: 2em;
	}
}

<div class="example-fun">
	<em>Outer:</em> <span>Foo</span>
	<div class="inner">
		<em>Inner:</em> <span>Bar</span>
	</div>
</div>

This works the same! But now we have a reusable --capture-length() function, and with its parameter being typed, this parameter behaves like a registered custom property — capturing its value, and passing the evaluated value, and not the tokens in abstract.

The spec text for the custom function evaluation explicitly describes how exactly those parameters are registered:

For each function parameter of custom function, create a custom property registration with the parameter’s name, a syntax of the parameter type, an inherit flag of “true”, and no initial value. Add the registration to registrations.

Interestingly, if we define a return type for a function, it will also be “captured”, so those two are identical:

@function --capture-length(--value <length>) {
	result: var(--value);
}

@function --capture-length(--value) returns <length> {
	result: var(--value);
}

But using the type for a parameter is just so slightly more compact.

Use Cases for Capturing Length

I won’t repeat everything I wrote in my original article about it, but to sum up some common use cases:

Universal Capturing

The function above only captured a single type — <length>. But we can make it capture multiple different types at the same time!

@function --capture(
	--value type(<length>|<number>|<color>)
) {
	result: var(--value);
}

This will work just as well!

More Use Cases

However, the use cases for things outside <length> are rare.

One example for <color> I also gave in my previous post on topic: “Unlocking Style Queries”.

Until now, if we wanted to check the value of some color, like inside a style query, we had to “normalize” it and use a registered custom property for this.

We can do this with our --capture function as well — and! — with conditions in CSS, we could implement a --light-dark() custom function similar to what I described in my “Querying the Color Scheme” post, but one that will work without the downside of style queries!

Here is a heavily modified example from the “Single Source of Truth” section of that post, but now using the custom functions and if():

Component is not available in RSS, visit the the site to access it.

@function --capture(
	--value,
	--_value type(<length>|<number>|<color>):
		var(--value)
) {
	result: var(--_value);
}

@function --light-dark(--a, --b) {
	--captured-color:
		--capture(light-dark(white, black));

	result: if(
		style(--captured-color: --capture(#FFF)):
			var(--a);
		else:
			var(--b);
	);
}

.example--light {
	color-scheme: light;
}

.example--dark {
	color-scheme: dark;
}

.example {
	padding: 1em;
	background: Canvas;
	color: CanvasText;
	border:
		2px
		--light-dark(solid, dashed)
		--light-dark(hotpink, pink);

	@layer {
		.dark-only {
			display: --light-dark(none, revert-layer);
		}

		.light-only {
			display: --light-dark(revert-layer, none);
		}
	}
}

<p class="example example--light">I should be always light. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>
<p class="example example--dark">I should be always dark. Current scheme: <em class="light-only">light</em><em class="dark-only">dark</em>.</p>

We can see that our --light-dark() function works for any values — not just colors — and works perfectly on the same element on which we define the color-scheme!

There are a few interesting things going on that demand additional explanations.

Capturing `light-dark()`

You could notice that the CSS of the --capture function here is different from what I proposed initially: it has two arguments, with the second one having its value assigned from the first one by default.

What is this, and why? The reason: light-dark() works only for color contexts. It might be Chrome’s implementation bug, but just passing light-dark (…) to a custom function, even if the argument is typed, will not capture it.

But by doing this gambit, where we reassign that argument to another typed argument, we can work around this!

`revert-layer`, for now

I’m using a revert-layer and a custom cascade layer around the if()s that touch display property, but in the future we could use revert-rule for this.

If you don’t know what revert-rule is — in January CSSWG resolved to add it to CSS, following “New !revertable flag to mark a declaration as ‘can be reverted when IACVT’” by Lea Verou, and an older proposal “Proposal: additional CSS-Wide Keyword, ‘ignore’ (primarily for css variable fallbacks)” by Jane Ori.

This CSS-wide keyword will be invaluable for any conditional styles!

`if()` evaluation

While the if() did ship in stable Chrome 137, it is not yet in its final form. Currently, you have to jump through a few hoops when you want to compare a return value of some function: assign it to another custom property, and also make sure the types match inside style() — style(--captured-color: --capture(#FFF)) — here we have to explicitly call our --capture() around the #FFF to make sure it will be properly compared with the --captured-color.

This is a known “gotcha”: for example, Temani Afif wrote a “How to correctly use if() in CSS” post about this, in which he points that we can use registered custom properties to fix this. Our --capture() function might be an even better solution to this!

And, in the future, the way style() is evaluated might change, so there is a chance we could simplify this place later.

Color Capturing Limitations

When exploring capturing the <color> type for another article, I discovered that it does not work for any colors that include currentColor.

I won’t repeat myself, but I welcome you to check the “Problem of the Current Color” section of my “Passing Data into SVG: Linked Parameters Workaround” article (which I also recommend reading in full — it contains many fun bits!)

I imagine there might be other similar cases, where we couldn’t capture something that evaluates at used time, and not computed which both registered custom properties and typed function arguments care about.

Fun Future

I can’t wait for what else we could do with custom functions, if(), revert-rule, and many other incoming features which will make the foundation of future CSS.

At the first glance, functions might seem to be just a syntax sugar over something you could otherwise achieve with preprocessors. But, their type capabilities, and the way they interact with everything else in CSS, allows us to abstract things in much more dynamic ways than previously possible in static CSS.

If you want to play with that future: I recommend trying Chrome Canary with its Experimental Web Platform Features flag, and give your feedback to CSS Working Group and Chromium. And me — I would love to look at your experiments as well!

Let me know what you think about this on Mastodon!

Fit-to-Width Status Update: Prototype and Issues

Thu, 02 Oct 2025 00:00:00 GMT

Current music:: S — Falling
Current drink:: Camomile Tea

Since my last post about fitting some text into a box, Chrome’s team posted their feedback based on the work they did while prototyping.

I agreed with some of what they wrote, but I also strongly disagreed with a bunch of it.

To move things forward, I created four issues, one of them is about a technical issue about which spec this feature should belong to, but the other three are something I’d invite you to read and consider:

“Text Fitting: Default scaling limit” — about my proposed solution of adding a default 200% limit to the feature.

Chrome team’s does not think it will work, but did not yet elaborate on why. Since posting about my proposed solution, I’ve received zero feedback about it anywhere: neither positive nor negative.

If you care about accessibility and want to help — I’ll be happy if you will consider the problem and the proposed solution. Is it enough? Is there an alternative? What do you think?
“Text Fitting: Shrinking and Growing” — about having one or two ways to approach the fitting thing.

My initial thought was that we should have just one text-grow property, and in my previous post I described why.

Chrome team’s insists that authors want to have text-shrink too. I can see that there are use cases where approaching fitting from the text-grow will be awkward (although possible), and in this issue propose an alternative approach: to use a single text-fit property with two possible values of the used method — text-fit: grow and text-fit: shrink. This allows using only one of them, eliminating a bunch of possible issues (like the conflict with the 200% limit).

If you were to want to use this feature — how would you want to use it? Would you ever want to use both methods at the same time? Is the potential accessibility problems (not being able to rely on the 200% limit) worth doing so when having a single method will allow doing everything anyways?
“Text Fitting: Scaling of things based on font-size” — about the core of how the new feature should work.

My hacky technique works in a finite number of steps, and allows scaling the text in a “true” manner, where any elements or properties that have values based on our element’s font-size would follow the scaling change, including applying the optical sizing axis of variable fonts properly (although, with an acceptable approximation).

Chrome’s team argues that this won’t be possible to implement in a performant manner. I am not a browser engineer, and can’t argue about this, but I doubt it is impossible to implement a solution that won’t be faster than my hacky way of doing it via containers and copies of the content. Chrome’s team proposes to make this implementation-dependent, which I strongly opposed, as this undermines the predictibility and power this feature can give authors in controlling typography.

I don’t know what non-browser engineers can contribute to this discussion. Maybe provide their use cases for things scaling that Chrome team things are ok to omit? And if you’re a browser engineer, please, look at my technique, and tell me you want to see it used everywhere in place of the native subpar solution. Because this is what will happen if the native feature will not cover the common use cases that people have.

Initially, it was resolved that I will become a co-editor for this spec. I wanted to start a draft of things how I see them, but with the Chrome team’s prototype, I don’t really have anything to draft, as their vision is very far from mine. First, we need to find a common ground and only then I could try writing something. After all, I never edited a spec before, and starting from something in this state might not be a good idea.

If you care about typography and accessibility, please, provide any feedback, privately or publicly. It’s difficult to move in the darkness, without almost any feedback from authors. I am grateful for the critique of the accessibility issues that folowed the resolution to add the feature to CSS, but since then, it was silent so far, with proposed solutions not getting evaluated.

It would be great to have a constructive discussion, and work on making this feature a reality without compromising on anything.

Let me know what you think about this on Mastodon!

November, Again

Sat, 01 Nov 2025 00:00:00 GMT

Current music:: The Album Leaf — Seal Beach
Current drink:: Ceylon tea

For the third time, I am attempting to write a blog post for every day of November. I managed to do it for 2023 and 2024. I won’t promise I’ll manage to post every day this time, but I’ll try.

Apple Annie

I was not sure if I will do this attempt, but when thinking about the coming November, I couldn’t stop thinking about Anne Sturdivant who passed at the beginning of this year (post by Adam Newbold — thanks for letting us know), and who was the constant presence for this challenge for the last years.

Annie was an inspiration, and I loved how many different topics she covered in her blogs. I mentioned her posts and experiments five times in my blog, and I am endlessly sad that no new posts of her will be mentioned here.

But I will try to at least continue doing this challenge: even though it was always very tough, it was always productive. For me, that challenge will now always be associated with Annie.

Burnout

I did not write about CSS a lot this year, right? Neither on my main site, nor in this blog. And I did not do many new experiments.

I am a perfectionist, and often it feels like, sometimes, I care too much about what I do. And then, when I expect the same care from others, and find that it is just not there, it can hurt.

My debt of spoons is big, and it is hard to find strength for doing anything.

So many drafts, so many of them are not finished, not published, covered by digital dust, crumbled in a corner between dropped anime series and unfinished video games.

My hope is that having to post each day of this month will at least produce something.

The Plan

I have a big backlog of stuff I want to write about, but I also created a list of what I could write about this month specifically. I won’t post it here, but here is what I will try to do:

Every weekend I will post something non-CSS related: more personal notes, thoughts, maybe game reviews? We’ll see.
Weekdays will be for more front-end related stuff. CSS. Maybe something else. Maybe will do some more work on this blog and post some dev logs?

Other than that, I don’t think I will follow any specific structure. I hope that on the weekends I could manage start writing drafts for some of the future November posts, just so I will be not as pressed to do so on the actual days.

I want to say and write even more now that I started — as it often happens with me. The hardest thing is to begin, then words start flowing.

Thank You

If you read this post — thank you. Sometimes it feels that the internet of old is gone. But anyone who has it in them to read random musings of people on the web contributes to the idea of independent network.

And if you’ll want to write a few more posts than usual this November — send them my way, regardless of the topic — I’ll be happy to read them.

Let me know what you think about this on Mastodon!

Photo Walk in March

Sun, 02 Nov 2025 00:00:00 GMT

Current music:: Haisuinonasa — Dynamics of subway
Current drink:: Ceylon tea

Well… It is November, but I am sharing photos from my walk from this March. I already published them on my Pixelfed account almost right after taking them, but I really want to continue posting them here as well.

“A nice spring day” (image is not available in RSS, visit the the site to access it.)

This was my first walk with both a new camera, and a new lens:

Camera is OM System OM-3.
Lens is OM System M.Zuiko Digital 17mm f/1.8 II.

If you don’t know — “OM System” is the brand name for the company that bought Olympus camera division, so they basically continuing doing the same: releasing new cameras and lenses for micro four thirds system.

My last camera — Olympus OM-D E-M5 — was released in 2012, and I bought it for myself in 2013. I don’t often upgrade my gear!

This lens is now the widest lens I have, although in full frame equivalent it is not as wide — it would be 34mm there.

But, for me, it is wide: my favorite lens before that was 45mm in micro four thirds, so a 90mm equivalent.

I am not that used to this wide of an aperture, but I was glad that I went into the forest — unlike my past lens that allowed me to focus on details, this lens made it possible to get more of the surroundings into the frame.

“Narrow footpath” (image is not available in RSS, visit the the site to access it.)

Winter was over, and while the trees did not yet get their leaves, the grass was already started to get greener, and, occasionally, small flowers started to show up among fallen leaves from the last year.

“Tiny flower” (image is not available in RSS, visit the the site to access it.)

It would’ve been harder to depict how tall are the trees in the forest without a wide lens: when you meet someone on the path, they can look very small in comparison.

“Leafless trees” (image is not available in RSS, visit the the site to access it.)

I really liked the texture of the sprawling oak branches against the sky. I hope the conditions in your code don’t look like this:

While most of the trees were leafless, some smaller trees had leaves sprouting on them, and flowers starting to bloom.

“Blooming flowers” (image is not available in RSS, visit the the site to access it.)

That day the weather was nice, and there were several people in the forest, either walking by themselves, or with their dogs.

To the east of the forest there is a long terrace that is overlooking Paris. It is a part of the park, and has a few entrances in the wall that surrounds its park area.

“Entrance to the terrace” (image is not available in RSS, visit the the site to access it.)

It is always a great view from the terrace.

After walking through the terrace and the park, I entered the city again, and went back home through its narrow streets.

“Well, that’s not a street, of course.” (image is not available in RSS, visit the the site to access it.)

I like to use different paths when getting back from my walks: it if nice to notice new things and places that you did not see before.

“Very cozy corner” (image is not available in RSS, visit the the site to access it.)

Courtyards are often closed off, but sometimes you can peek there, and they can be pretty interesting too.

It is nice to revisit some of the older photos and older memories. I still have many photos posted on Pixelfed that I will share here in the future, and even more that I did not publish anywhere yet.

I need to get a habit to post more, and go out with a camera more.

Let me know what you think about this on Mastodon!

Inline Custom Identifiers

Mon, 03 Nov 2025 00:00:00 GMT

Current music:: Daughter — Doing the Right Thing
Current drink:: Green tea with bergamot, kiwi, yellow peach, orange blossom and violet flower

The Context

This is a quick post about a pattern that I use more and more: a way to connect elements that require named custom or dashed identifiers for various CSS features.

I constantly use this pattern, but never explicitly wrote about it, even though I used it in many of my experiments.

The reason I finally do it now is because of a question by Eric Meyer in Mastodon about how to connect two elements for anchor positioning in absence of the anchor attribute (which is in limbo of standardization: it is uncertain if we will ever have it).

The Pattern

The pattern is pretty simple: we use inline styles to add custom properties with the same custom identifier, and then use these custom properties in CSS.

Component is not available in RSS, visit the the site to access it.

<p>
	<strong style="--is: --hello">
		Hello
	</strong>
	<em style="--for: --hello" class="anchored">
		World
	</em>
</p>

[style*='--is:'] {
	anchor-name: var(--is);
}
.anchored {
	position: absolute;
	position-anchor: var(--for);
	top: anchor(outside);
	left: anchor(outside);
}

The names I like to use: --is for naming something, and --for (similar to <label>’s for attribute) for referencing.

Inline Styles?

I often see people either neglect inline styles, or putting too much stuff into them. In my opinion, the proper way to use inline styles is for putting custom properties into them.

Regular properties will be too high in the cascade when put inline, which is why we should never use them there.

Custom properties, on the other hand, are much safer: we can use them as an API and abstract certain features through them. Of course, it is possible to have cascade conflicts with them as well, but it is up to use to design that API in a way the conflicts could be avoided.

That’s why I recommend this pattern, and recommend using inline styles for assigning unique custom properties per element.

Attribute Selector

This is another pattern that I never wrote about, and an article about which is long overdue, although I gave a lightning talk about it at dotCSS 2019 conference (video, slides). Many things changed since then, and if I were to write about this approach properly, I’ll need to revisit many of my past assumptions.

But, in short, the idea is that we can use attribute selectors to match any elements with inline custom property definitions, like [style*='--is:'] in the above example. The *= means that the part afterwards can be present at any place in the attribute, and if we match on the name of the custom property alongside the :, then unless we use very funky whitespace, or have variable names that include our name partially, like --foo--is for the above example, we can be pretty certain that we will only select elements that define such properties.

After matching, we know that we have this custom property, and can use it right away.

Other Examples

I used this pattern at least in the following articles on my main site:

I am pretty sure I used this pattern somewhere else, but I can’t remember where.

Try it Out!

That’s it for today! We are getting more and more features in CSS that rely on connecting things through dashed idents, and, in the absence of something better, inline styles are a great way to do so.

If you evern find yourself needing these types of references — try this pattern, and let me know if it was helpful!

Let me know what you think about this on Mastodon!

Renaming Outer Variables in CSS Functions

Tue, 04 Nov 2025 00:00:00 GMT

Current music:: österreich — I’ll Take You Everywhere
Current drink:: Thyme, rosemary & lemon infusion

In one of the first drafts of the custom CSS functions by Tab Atkins-Bittner, if you wanted to use variables from the outer scope, you had to explicitly list them when defining the function like this:

@function --foo(--arg1, --arg2) using (--var1, --var2) {…}

There was some pushback from many people about this, including from me, and, eventually, this restriction was removed, with all custom properties from the outer scope now being available inside the custom functions without listing them. Great!

At the time, I wondered if we could reintroduce the using keyword or something similar as something that could allow us to rename the variables in the outer scope, allowing us to use them in the function’s scope with different names.

@function --foo() {
	@return var(--bar);
}

@function --baz() using (--bar as --outer-bar) {
	--bar: something;
	/* will be `--a: something` */
	--a: --foo();
	/* We can still access outer `--bar` */
	--b: var(--outer-bar);
}

Later, while playing with the currently specified custom functions in Chrome Canary, I found out that we already can kinda do the same with the optional arguments and defaults. The above example could be written as:

@function --foo() {
	@return var(--bar);
}

@function --baz(--outer-bar: var(--bar)) {
	--bar: something;
	/* will be `--a: something` */
	--a: --foo();
	/* We can still access outer `--bar` */
	--b: var(--outer-bar);
}

And here is a live, although not very practical, example:

Component is not available in RSS, visit the the site to access it.

@function --double() {
	result: calc(2 * var(--x));
}
@function --plus-one-and-double(--outer-x: var(--x)) {
	--x: calc(var(--outer-x) + 1);
	result: --double();
}

<div style="
	--x: 2;
	--preview: --double();
">2 * x = </div>
<div style="
	--x: 2;
	--preview: --plus-one-and-double();
">2 * (x + 1) = </div>

The problem we are solving: if we have some function like --double(), which does not use arguments, and is just accessing the variables from its outer scope, can we use it inside another function with a different --x without overriding it in that outer scope?

The solution: use an argument, and assign its default value using that variable. This way, the function will get that variable’s value and assign it to a different variable:

@function --plus-one-and-double(--outer-x: var(--x)) {…}

Now, inside that function’s body, we’re free to redefine that variable, with the original value staying accessible with the old value in our argument!

This allows us to redefine this variable, call our function in question, all without touching and modifying the outermost scope.

Neat. I don’t know if this will ever be useful, but hey!

This is the second post from the series that I started with “Functional Capturing” about some of my initial experiments with custom functions. It was in my drafts for a long time, but because the feature is relatively useless, I did not end up finishing it.

Until now — all because with the ongoing work on inherit(), there was an issue opened by Anders Hartvoll Ruud, in which I managed to use this feature in an argument. Fun!

Let me know what you think about this on Mastodon!

Zombie Styles

Wed, 05 Nov 2025 00:00:00 GMT

Current music:: Daughter — Burn It Down
Current drink:: Ceylon tea

This is a short post about one thing I encounter a lot, but never saw explicitly defined for easy reference. This is my attempt:

Zombie Styles (noun): Dormant styles that break the UI after a configuration change.

What do Zombie Styles mean?

Zombie Styles refer to CSS styles that exist in the document’s stylesheet, but are dead, usually due to being overridden by other declarations. In their dormant form, they do not impact anything in the UI, and do not activate under normal circumstances.

However, some confuguration change can bring them to life unintentionally, and now that they’re applying, they affect the UI and wreak havoc.

Examples of Zombie Styles

Forgotten Styles

The most common case of this happens when the same styles exist in multiple files, or in the same file but separated by other rules or declarations.

.Foo {
	background: pink;
	/* 100 very useful design-tokens */
	background: lightgreen;
}

.Foo {
	background: pink;
}

/* Many rules after, or maybe even in another file */

.Foo {
	background: lightgreen;
}

When you look at a long stylesheet and only see a portion of styles, you might think “Maybe, I want the background of this Foo component to be transparent” and you then remove the background: lightgreen declaration. But somewhere there was a declaration hidden: it never applied before, but now it jumps and makes you spend another few minutes debugging your code.

The first case is easy to catch if you use Stylelint via a declaration-block-no-duplicate-properties rule, but more complex cases can be harder to spot.

Generally, it is a good idea to never repeat selectors, separating styles that are applied together in the code.

Import Order Change

In SPAs (Shitty-Produced Applications) that load chunks of CSS based on the Let’s say we have this HTML:

<section class="ComponentA">
	<p class="ComponentB">I am alive</p>
</section>

And these two that components have the following styles:

.ComponentA > * {
	background: pink;
}

.ComponentB {
	background: lightgreen;
}

Both of these styles have the same specificity, and a page can be built with the expectation that the ComponentA will always be imported before the ComponentB. The background: pink never applies.

Then, suddenly, somewhere in the app, ComponentB is included before the ComponentA, and now the styles’ order changes.

The declaration that was previously “dormant” activates. Oops. It might be the time to rethink your whole CSS architecture.

Were You Also Bitten?

Confess. Do you have bite marks from zombie styles? It is safe to confide in this: unlike normal zombies, zombie styles, usually, don’t convert you into CSS declarations.

Usually.

Please let me know which examples of zombie styles you have encountered. How did you fight them? Or did you just run away?

Let me know what you think about this on Mastodon!

Fixing Baselines

Fri, 07 Nov 2025 00:00:00 GMT

Current music:: 夢中夢 — Unforgiven
Current drink:: Lapsang Souchong tea

Do you know how to center things in CSS? In year 2025? Easy! You just… align… or justify…, ok, maybe just place? your content… or items? …Forget it, this post is not about alignment. Or is it?

This post is about another common alignment concept that might seem simple: baseline alignment. In it, I share a technique I have already used for twelve years.

The Definition

To quote from the specs,

A baseline is a line along the inline axis of a line box along which individual glyphs of text are aligned.

Figure from the spec: Alphabetic text in two font sizes with the baseline and em-boxes

The specs go into many details, and if you will start reading them (or if you have enough practice), you’ll get that it is not ⭐️simple.

The Problems & Solutions

If you pay a close attention to the previous sentence, you might get the idea.

Overflowing Inline Elements

This is the simplest problem, which, today, has a simple solution. The problem: if you have an element with inline-block, giving it overflow: hidden (or auto, scroll, etc.) will break the baseline:

Component is not available in RSS, visit the the site to access it.

<p>Hello, <span class="block-world">world</span>!</p>

.block-world {
	display: inline-block;
	outline: 1px solid;
	overflow: hidden;
}

The solution: use inline-flex or inline-grid instead. They will retain the baseline!

Component is not available in RSS, visit the the site to access it.

<p>Hello, <span class="flex-world">world</span>!</p>

.flex-world {
	display: inline-flex;
	outline: 1px solid;
	overflow: hidden;
}

More than eleven years ago — almost twelve — I wrote a dedicated article about this topic: “Battle for Baseline”. If you want to read about all the crossbrowser issues I had to dig through to make this work at that time, I invite you to read it.

But today, now that inline-flex and inline-grid are baseline (sorry), we no longer have the same bugs and issues. Hooray.

Icons Before Text

The second problem can be much more pronounced today, and does not have a solution built into the specs (or — I don’t know about it).

It is what happens when you have some inline element, for example, a button, and then inside of it, but before its text, you add some icon. And then, you want to center everything vertically inside, but, at the same time, align this button’s content with the baseline of the nearby text. It doesn’t work:

Component is not available in RSS, visit the the site to access it.

<p>
	Hello,
	<button type="button" class="button-world">
		<span class="icon">🌐</span>
		world
	</button>!
</p>

.button-world {
	display: inline-flex;
	padding: 0 0.5em;
	gap: 0.5em;
	place-items: center;
	border: 1px solid;
	border-radius: 9em;
	overflow: hidden;
	font: inherit;
}

.icon {
	font-size: 2em;
}

If the font-size of the icon that contains an emoji was the same as of the text, it would look ok. But if we modify this element’s font-size, or use an empty element or a replaced element instead, then this element will be used for determining the baseline of our button.

This is because, by default, the button uses the first “baseline set” for aligning that inline-flex element, and that first baseline will come from our icon!

`baseline-source`

If we dig a bit into the specs, we could find a partial solution for our problem: the very obscure baseline-source property.

Why is it obscure?

First, it is not baseline (I am so sorry again), and is only supported in Firefox and Chrome, with support missing from Safari. It is not even present on MDN.

Then, if we were to use it in browsers that do support it to address our problem, it will help for a simple case:

Component is not available in RSS, visit the the site to access it.

<p>
	Hello,
	<button type="button" class="button-world with-baseline-source">
		<span class="icon">🌐</span>
		world
	</button>!
</p>

.with-baseline-source {
	baseline-source: last;
}

But — the only value other than auto and first is last. And, guess what will happen if we would also add an icon to the end of our button:

Component is not available in RSS, visit the the site to access it.

<p>
	Hello,
	<button type="button" class="button-world with-baseline-source">
		<span class="icon">🌐</span>
		world
		<span class="icon">🙀</span>
	</button>!
</p>

And, the second problem will happen if we were to have a multiline button — and would want, for some reason, to still use the default behavior of aligning it via its first line:

Component is not available in RSS, visit the the site to access it.

<p>
	Hello,
	<button type="button" class="button-world with-baseline-source">
		<span class="icon">🌐</span>
		wrapped<br/>world
	</button>!
</p>

It is not just the last element that defines the baseline now — it is the last line box of the last element. Oops.

An Extra Element Solution

So, how can we solve this problem today, and more reliably?

The solution that I used for years, but I don’t think I ever shared (or saw mentioned elsewhere — if someone did write about it, please let me know!) — to just use an extra element before the element that otherwise breaks our baseline. That extra element should have the same font metrics as the real content, and we need to make this element to not contribute any space, but otherwise this works pretty well:

Component is not available in RSS, visit the the site to access it.

<p>
	Hello,
	<button type="button" class="button-world with-extra-element">
		<span class="icon">🌐</span>
		world
	</button>!
</p>

.with-extra-element {
	--gap: 0.5em;
	gap: var(--gap);
}
.with-extra-element::before {
	content: '\a0'; /* &nbsp; */
	width: 0;
	display: inline-block;
	visibility: hidden;
	margin-left: calc(-1 * var(--gap, 0));
}

A few things to note:

Because our element uses a gap, we have to remove the extra gap that will appear when we insert the pseudo-element.
I am using a '\a0' — a no-break space. I found it to work the best. Extra tip: whenever you use escaped characters in your CSS, add comments that communicate what they are.
For it to not impact anything other than the baseline, we give it width: 0 and hide it via visibility.
Of course, if you don’t have a gap, you can skip the margin stuff.

And that’s it!

Prior Art

While I am using this technique for almost twelve years already, I used Marginalia search to look up if anyone else mentioned it elsewhere.

I might’ve missed something, but the closest thing I found is “SVG icon sizing and alignment” article by Dimiter Petrov.

Could There Be a Better Way?

Currently, we can only control which baseline set is used for our element on the wrapper element.

But what if we could have something like baseline-presence: exclude that could be used on our inner elements, so we could add it to our icons, and then they won’t participate in the definition of our baseline?

Right after published this post, I opened an issue about this in CSSWG, as I did not find any others that would cover this. I work on design systems for a very long time, and this problem appears over and over in all of them.

And — if you know of a different solution — please let me know, or — even better — write your own post about it and share it!

Let me know what you think about this on Mastodon!

Photo Walk, End of March

Sun, 09 Nov 2025 00:00:00 GMT

Current music:: Tom Figgins — Clouds Do Part
Current drink:: Thyme, rosemary & lemon infusion

I am a bit out of it — did not sleep for quite a while, but not managing to fall asleep properly now. Staying in Europe and not going to this year’s TPAC, I am trying to shift my waking hours to match Japan. Not very successfully so far.

Well, time to repost some older photos from Pixelfed!

“Magnolia, blooming.” (image is not available in RSS, visit the the site to access it.)

This was at the end of this March, when trees started to get their leaves, and blooming with flowers.

“The opposite of trees losing the leaves.” (image is not available in RSS, visit the the site to access it.)

Weather was pretty nice that day: sunny, with some clouds. There were a bunch of people in the parks.

“People walking in the parks.” (image is not available in RSS, visit the the site to access it.)

I went a long way, intending to get a tram back. Passed between the viaduct with the tram line on top, and noticed some houses nested under it.

Went pretty randomly, through some parks I never visited before.

“A lot of activity in the park.” (image is not available in RSS, visit the the site to access it.)

Ended up going onto some hill with a dead end, but managed to find a private (but open) path between properties.

“A hidden path between private properties.” (image is not available in RSS, visit the the site to access it.)

I did not manage to make many good photos: I was still getting used to the wider lens, and unlike when I was in the forest, it was a bit harder to get good shots.

“Someone’s yard.” (image is not available in RSS, visit the the site to access it.)

Funnily enough, the tram did not work that day, and some of the closest bus stops were closed because of some construction. Well.

“A tunnel.” (image is not available in RSS, visit the the site to access it.)

In the end, I just walked all the back home, and tested a nice hill climb with a staircase.

That’s it. I’ll now go drink some tea, eat some food, and try to go sleep for a while.

Let me know what you think about this on Mastodon!

Embedding Bandcamp Tracks

Sat, 08 Nov 2025 00:00:00 GMT

Current music:: The Album Leaf — An Interview
Current drink:: Ceylon tea

A long time ago, back in LiveJournal, sometimes people embedded various music players in their posts. It was fun! You could read the posts of your online friends, and sometimes listen to random music they shared with everyone.

What I Did

I already had a “Current music” field added to most of my posts, replicating one small bit from the LiveJournal experience, but now I also added a way to enrich this field by adding an optional Bandcamp track reference, and spent my evening updating existing posts in the blog to have it.

Bandcamp embeds are just a <iframe>s, so by placing one inside an HTML <details> tag and adding the loading="lazy" to the <iframe> we can make it so the <iframe>’s code won’t be loaded before the details are open.

I didn’t use any APIs to retrieve the ID to embed, so I had to add the necessary metadata to this and other posts manually.

In total, unless I miscounted, I added Bandcamp links to a bit less than 70% of my ~78 posts with the “Current Music” field. Which is fun! Nice to see that many artists I listen to on Bandcamp. It went almost to the point where I could start thinking about the automation, but it did not hurt, and whenever I added a track to another post, I always tested it out and nodded at my past choices.

Example

You can go to the top of this post, click on the track name that is prefixed by the disclosure triangle, and see what happens. Maybe even listen to that track that is there!

Or — here is another example, from another post:

Haru Nemuri — [Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/embedding-bandcamp-tracks/)

Example of a minimal embed inside the details tag.

And, while I am not using this anywhere yet, I made it so it is possible to configure the same embed inside to expand in the bigger version that Bandcamp provides, this is yet from another post:

This is The Kit — [Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/embedding-bandcamp-tracks/)

Example of an embed with an album cover inside.

I remember in LiveJournal I sometimes posted custom embeds like that but the photos that I took instead of the album cover, trying to match the mood. Maybe I’ll implement something like that one day here as well.

Implementation?

I kinda promised not to talk a lot about frontend or CSS on weekends, even though I found there might be a lot to share while writing this post and implementing the embedded Bandcamp player. However, I’ll try to stick to my plan, and stop before going into more details.

I noted down a few things I’d want to share regardless, so, maybe, one day!

Potential Issues

Possible Future Bias

What I have now presents a slight problem: if some artist or a specific track is not present on the Bandcamp, I cannot currently link to it in any way. Having a “richer” experience for Bandcamp might make me choose artists who are present there more when adding them to my posts.

Some artists might be present on platforms I don’t want to link that much, like YouTube, but maybe it’s ok? Some of them might not be present anywhere outside the streaming platforms, which might make things even worse.

I need to contemplate what to do: should I add alternative types of metadata and presentation for other services? Just link to artists’ pages when possible? Hm hm.

Future Link/Embed Rot

Another thing that could happen because I am not self-hosting the Current Music (duh) — if the tracks will disappear from Bandcamp, the embeds will stop working. Which is not the end of the world, but I currently don’t have any tools to detect that.

That’s It, For Now

Yep. What I like about having my own website — I can do whatever I want with it. Even the more independent and federated networks became very limited in what they allow. While I was not on it, I looked with interest at Cohost with all the CSS Crimes you could do there (post by Blackle Mori — author of many such contraptions).

The older, asocial, pseudonymous networks were much more relaxed in what you could post and do with your personal spaces. Custom themes, embeds, quizes, custom avatars per post, inline CSS.

I understand how in modern web there are now many concerns over privacy and security which close some of the past doors, but I hope that with newer CSS features like @scope we could maybe unlock some of them, and allow the chaotic creativity to invade our niche spaces.

Let me know what you think about this on Mastodon!

Uneven Inline Paddings

Mon, 10 Nov 2025 00:00:00 GMT

Current music:: COVET — Ares
Current drink:: Green tea with bergamot, kiwi, yellow peach, orange blossom and violet flower

Today, I want to share one tiny design tweak you can do to your content styles. I have used it in my blog’s design for a while, and recently decided to improve it a bit, and will take this as an opportunity to share it.

The Ragged Edge

No, this is not about Babylon 5’s 100^th episode that had “The Ragged Edge” as its title, in which Garibaldi’s relapse into alcoholism jeopardises a covert mission to the Drazi homeworld (quoting Wikipedia’s episode summary that I found when doing some research; good show, BTW).

I will be talking about the left-aligned text, also known as “flush left” or “ragged right”. Actually, this could also work for right-aligned text — the main idea is that we need to have the rag, and not have the text justified.

The problem with the ragged edge — if the padding on both sides of your column of content is even, it will get perceived as uneven.

Component is not available in RSS, visit the the site to access it.

.container {
	padding: 32px;
}

<div class="container">
	<p><span>This is a paragraph of text that will wrap, and will create a ragged edge because it is not justified, which can result in the perceived uneveness of the paddings on both sides of it. If this doesn’t happen, then maybe the width of its lines matches very precisely the width of the container.</span></p>
	<p><span>If you can resize your window or this example, you might have a better chance to be able to spot the difference.</span></p>
</div>
<fieldset class="controls">
	<legend>Tweak this example</legend>
	<label class="with-background"><input type="checkbox" checked /> <u>with green background</u></label>
	<label class="with-edge"><input type="checkbox" /> <u>highlight the padding edge</u></label>
</fieldset>

Very rarely any of the words in the text will get flush with its right edge: usually, they will wrap before reaching it, and thus will always leave some extra space.

In the above example, by default, all the padding around the paragraph is shown with a green background, excluding the background under the actual text content. This makes it easy to spot the unevenness: removing the background “hides” this, but only to an extent.

The Solution

The solution for this is to apply a smaller padding to the ragged edge:

Component is not available in RSS, visit the the site to access it.

.uneven-padding {
	padding-inline-end: 16px;
}

<div class="container uneven-padding">
	<p><span>This is a paragraph of text that will wrap, and will create a ragged edge because it is not justified, which can result in the perceived uneveness of the paddings on both sides of it. If this doesn’t happen, then maybe the width of its lines matches very precisely the width of the container.</span></p>
	<p><span>If you can resize your window or this example, you might have a better chance to be able to spot the difference.</span></p>
</div>
<fieldset class="controls">
	<legend>Tweak this example</legend>
	<label class="with-background"><input type="checkbox" checked /> <u>with green background</u></label>
	<label class="with-edge"><input type="checkbox" /> <u>highlight previous padding edge</u></label>
	<label class="with-fix"><input type="checkbox" checked /> <u>with uneven padding fix</u></label>
</fieldset>

This might not look that impactful on a minimal example, but the more text you have, the bigger the change. This can be even more important for narrow contexts: on my blog I initially only applied this in the desktop version, but on smaller screens the padding ended up being equal.

Downsides

Should you go and change all your paddings? Probably not. Especially, given there might be potential issues with this solution:

You could think that the bigger the padding, the bigger chunk of it we could remove. To an extent, this is true, but it can be very easy to shift the unevenness in the other direction. This is something that should be done “by an eye”, although as a rule of thumb a good starting point could be to apply a half of the original padding.
Often, people include things other than the text in their content. Images, code blocks, etc. If those have backgrounds or borders on their own, an uneven padding around those elements will look uneven. This is where you’d want to either add an extra margin to those elements to compensate, or invert things and keep the original even padding intact and only add a negative margin on the children that might need it like paragraphs, list items, and so on.
After addressing the problem with the full-width elements above, and if the padding is pretty large, then cutting it in half can lead to the unevenness being pretty obvious. These pronounced blocky elements will visually reinforce the “expected” edge, making the “hanging” text in the rag stick out.
If your text has text-wrap: balance or pretty, the effect of the fix will often be smaller because then all the lines will wrap sooner, so the chances of the text not going until the edge will be higher, and a small padding tweak won’t help. And if the width of the container will be equal to the longest wrapping lines, it is likely things could feel unbalanced, similar to if we had text-align: justify.

Closing Thoughts

I hope you found this short post interesting. I consider myself bad at design, but many people tell me that they like how my main website and this blog look. Blame all the years that I iterated on them!

Over these years, gradually, I implemented more and more ideas, small and big, regarding their design and typography. Did you spot some already? Or are they subtle enough that you’re now wondering what exactly do I mean? ~~Let me know in the comments down below.~~

Let me know what you think about this on Mastodon!

Named Container Presence Check

Tue, 11 Nov 2025 00:00:00 GMT

Current music:: Haisuinonasa — Shower
Current drink:: Cappuccino

The Task

I was doing some styling recently, and I wanted to know if my element was inside a certain container.

If you're new to _containers_, you can familiarize yourself with them via one of these resources:

	- [“An Interactive Guide to CSS Container Queries”](https://ishadeed.com/article/css-container-query-guide/) by [Ahmad Shadeed](https://ishadeed.com/).

	- [“Container Queries Unleashed”](https://www.joshwcomeau.com/css/container-queries-unleashed/) by [Josh W. Comeau](https://www.joshwcomeau.com/).

	- [“CSS Containers, What Do They Know?”](https://www.youtube.com/watch?v=-Fw8GSksUIo) — a talk by [Miriam Suzanne](https://www.miriamsuzanne.com/).
</aside>

.my-container {
	container-type: inline-size;
}

<div class="my-container">
	<div class="some-element">
		Where am I?
	</div>
</div>

<div class="some-element">
	And me, what about me?
</div>

While I could reuse the same selector that I used to apply the container with, this did not feel right: what if I were to apply the same container via a different selector? Or have a version of that element where the container is removed via some modifier?

Given I already had container-type: inline-size, and I literally wanted to know if this exact containment from this exact element was applied, as a way to differentiate between it and the viewport, using a named container to check this was pretty obvious.

Checking Named Containers

Generally, named containers — ones with the container-name property — are used for differentiating between them. What if you have multiple containers around an element, and you need to check the dimensions on a specific container? Is this a query for a card, or for content?

Usually, you’d use these containers to query either elements’ dimensions, or, with style container queries, values of custom properties on them.

For my purpose, I don’t care about any specific values: I only need to know about the presence of some named container. For different types of them, we can do this differently.

Querying a Size Container

For size containers things are pretty simple: if we have an established size container, we can add a container-name to it (or join the name with its type into a container shorthand), and then query it in an always-positive way alongside its name:

Component is not available in RSS, visit the the site to access it.

.my-container {
	container: --my-container / inline-size;
}

@container --my-container (min-width: 0) {
	.some-element {
		outline: 3px solid var(--GREEN);
	}
}

<div class="my-container">
	<div class="some-element">
		Where am I?
	</div>
</div>

<div class="some-element">
	And me, what about me?
</div>

Some notes:

I am setting the name for our container using the shorthand. I am also using a dashed ident for it, even though containers allow any custom idents. I wrote a post about why I am doing this two years ago: “Dashed Idents for Everything”.
A container cannot have a negative width, so a min-width: 0 check will always match, but only if there is a --my-container somewhere in the tree around our some-element.
This will work only if we apply any container-type on our container: both size and inline-size will work for min-width, and if we’d want to check if our container is specifically size container, we’d need to check min-height: 0.

Style Querying any Container

Container style queries are almost here: Firefox should get them pretty soon. For querying styles of custom properties, we don’t need to have any containment, thus with container style queries we will be able to just name any element, and then query if we have this specific container somewhere in our element’s ancestors.

Component is not available in RSS, visit the the site to access it.

.my-styletainer {
	container-name: --my-styletainer;
}

@container --my-styletainer not (
	style(--a:a) and style(--a:b)
) {
	.my-element {
		outline: 3px solid var(--BLUE);
	}
}

<div class="my-styletainer">
	<div class="my-element">
		Where am I?
	</div>
</div>

<div class="my-element">
	And me, what about me?
</div>

In order to match a style container regardless of what its styles are, we can use a not (style(--a:a) and style(--a:b)) condition: it will be always truthy, as it is not possible to have some custom property that has two different values at the same time.

Why Not Regular Style Queries?

One could ask a question: couldn’t we just use style queries and then check some custom property like --container-name: --my-styletainer instead?

If we wanted to check if that container is the closest to our element — sure, that would be the way. However, what we want is to check if the container is present at all, without checking for its proximity.

Aren’t Those Hacky?

While the size containment check is pretty simple, we still have to establish the size containment. As for style queries, the check is very verbose. We could try to simplify it as not style(--\-) — use a name that will unlikely be present in our document, but it won’t be guaranteed.

Currently, @container --my-container {} won’t ever do anything: the follow-up condition is required. But what if we could use this simple notation to check for the named container’s presence? It will be pretty straighforward and simple.

I opened a CSSWG issue about this. If you have any use cases for this, write about them in this issue, otherwise, if you think it is a good idea — please, upvote it!

And — that’s it for today’s post! As it often goes: I thought it will be a simple one, but then ended up filling a Firefox bug and a CSSWG issue. Even more: this post was actually a side effect from starting to write another post, in which I used this “technique”, so I wanted to first briefly explain it in a separate post.

Update from 2025-11-12

After I published this post, Miriam noted that CSSWG already resolved on this 2 years ago, and Rune Lillesveen contributed WPT tests a year ago, which, as also tested by me, are still not passing.

I closed the issue I created as a duplicate. Now, I guess, the onus is on browsers: this feels like a very low-hanging fruit, as all necessary for verifying the presence of a container should be already done, this new feature is only excluding some of the checks browsers do when there is a query present.

Update from 2025-12-13

And now there will be a first implementation of the name-only container queries, thanks to Anthony Frehner who submitted a patch to WebKit that is now merged! Looking at the code there — it really seems like a pretty simple thing, so, I hope, this will be in other browsers too sooner rather than later.

Let me know what you think about this on Mastodon!

Responsive tab-size

Wed, 12 Nov 2025 00:00:00 GMT

Current music:: This is The Kit — Birchwood Beaker
Current drink:: Thyme, rosemary & lemon infusion

The `tab-size`

There exists a not well-known CSS property: tab-size. It sets the width, in spaces, of the tab indentation, usually found in code blocks of authors who use tabs instead of spaces (good job, authors).

One of the benefits of using tabs for indentation: it is possible to control how big the indentation will be. CSS is not exception, and that’s why tab-size property is very useful. Especially, given its default value is the enormous 8 spaces. It is very likely you’d want to override it for your code blocks:

Component is not available in RSS, visit the the site to access it.

<pre>
	One default tab here!
</pre>
<pre style="tab-size: 4">
	One overridden tab here!
</pre>

.example {
}
.example[class] pre:not(:has(> code)) {
	border: 2px solid var(--PINK);
	margin: 0;
	border-radius: 0;

	& + &,
	&:is(div + div > *) {
		margin-top: 1rem;
	}
}
.example2 .container {
	overflow: hidden;
	resize: horizontal;
	max-width: 100cqi;
}

Responsiveness

However, who says that this value should be static?

Component is not available in RSS, visit the the site to access it.

<div class="container">
	<pre class="dynamic-tab">	One tab here!</pre>
</div>
<div class="container" style="width: 66%">
	<pre class="dynamic-tab">	One tab here!</pre>
</div>
<div class="container" style="width: 33%">
	<pre class="dynamic-tab">	One tab here!</pre>
</div>

.container {
	container-type: inline-size;
}
.dynamic-tab {
	--available-width: 100cqi;
	--step-size: 10ch;
	@supports not (z-index: calc(1px/1px)) {
		--captured-length: var(--available-width);
		--captured-length2: var(--step-size);
		--ratio: tan(atan2(
			var(--captured-length),
			var(--captured-length2)
		));
		tab-size: round(up, var(--ratio), 2);
	}
	@supports (z-index: calc(1px/1px)) {
		tab-size: round(
			up,
			var(--available-width) / var(--step-size),
			2
		);
	}
}

Ok, that CSS looks scary! If all browsers supported typed arithmetic — an ability to divide two values of the same type to get the unitless ratio between them — we could simplify it to just this:

.dynamic-tab {
	tab-size: round(up, 100cqi / 10ch, 2);
}

Now, that’s much more readable, right? We divide the available space by some length to get the number of times it fits in it, and then round it up to be even.

This makes the tab-size start from being two spaces wide, and increase with the available space. If needed, a min() could be added if we’d wanted to limit how high it could grow.

But — typed arithmetic is not currently available in all browsers. That said, we can work around this.

I am using the tan(atan2()) hack by Jane Ori alongside “Captured Custom Properties” to capture some values that compute to px and then get the ratio between them via tan(atan2()).

I am also using @supports for the browsers to see only what they need to based on the typed arithmetic support. If we were not abstracting the values into custom properties, we could rely on fallbacks, but when custom properties are present we can’t use them.

That’s It

I first experimented with this almost exactly 2 years ago, and earlier this year shared an updated version of this technique on Mastodon.

This time, I finally wrote a proper blog post about it, and at the same time slightly updated it to use the typed arithmetic alongside the @supports rule.

I also updated my blog’s CSS to use this, although here it only switches between values of 2 and 4 spaces, and maybe a bit overcomplicated due to some of my blog’s implementation details — I even used the “Named Container Presence Check” that I described in the previous post.

It is fun finding places where the typed arithmetic could help with responsiveness: any place you see an integer or a unitless number could be an opportunity to try it. How can we connect our container’s size with it? Maybe use for color components? z-index? Number of repeats in grid’s repeat()? Something else?

Go on, and experiment. We need more experiments!

Let me know what you think about this on Mastodon!

Styles For Secondary Interactive Elements

Thu, 13 Nov 2025 00:00:00 GMT

Current music:: Raised By Swans — how do these hearts unfold
Current drink:: Lapsang Souchong tea

This is a post about another design tweak that I adopted while iterating on my site’s and blog’s designs over the years. I use it a lot, and really like how it feels and works — and I invite you to consider trying it as well.

What are “Secondary Interactive Elements”?

I don’t know if there is a better term — this is just something I came up when trying to describe them. By “them” I mean interactive elements that are not buttons or links.

These — I know how to style: hover states, focus states, underlines for links, cursor: pointer for both. I know, I know, that last part is pretty contentious, but I stand by it for a long time, and wrote a “Correct Cursor on Active Elements” article more than 12 years ago about this. Fun fact: my first CSSWG issue was about this!

Regular text inputs could also be considered “primary”, and have established conventions over how to style them.

But what about <label>, <summary>? They’re also interactive! I will refer to them as “secondary”. And will try to convince you that they deserve some extra styling. Aside from the cursor: pointer, of course.

Dotted Underlines

Yes, dotted underlines. I don’t remember where exactly this came from, but in my early days of browsing cyrillic webs, dashed or dotted underlines were a thing, often for ligher JS-based interactive elements that are not exactly buttons and are not links.

I think, this type of styling fits the <label> and <summary> elements the best:

Component is not available in RSS, visit the the site to access it.

<label for="test-checkbox">
	<input id="test-checkbox" type="checkbox" />
	<span class="u">Example of a label</span>
</label>
<details>
	<summary>
		<span class="u">Example of a summary</span>
	</summary>
	<p>Demo details’ content. Hello.</p>
</details>

Adding such underlines helps to communicate that these elements are, in fact, interactive. Especially for inputs because authors often forget to add proper labels, users might not know that they don’t have to be very precise and end up clicking only on the checkbox or radio buttons. We can help by adding extra affordance here.

Extra Inner Element

One thing you could notice: I have an extra .u span inside the label and summary, wrapping the actual text content, and applying the underline only to it:

.u {
	text-decoration: underline;
	text-decoration-style: dotted;
}

The reason for this: this is the least hacky way for styling only the text. Here is what would happen if we were to apply the underlines to the <label> and <summary> on their own:

Component is not available in RSS, visit the the site to access it.

<label for="test-checkbox2" class="u">
	<input id="test-checkbox2" type="checkbox" />
	Example of a label
</label>
<details>
	<summary class="u">
		Example of a summary
	</summary>
	<p>Demo details’ content. Hello.</p>
</details>

label.u,
summary.u {
	text-decoration-style: dotted;
}

In all browsers, the checkbox is treated as an inline element, and Firefox also treats the summary’s marker as such, and thus the text-decoration might go over them.

I found that adding an extra element around the content and delegating the underline to it is the most reliable way to handle this.

Why Not Dashed?

While this could seem like a personal preference, I consider dashed style to not work very well for thickier underlines. I also see more cross-browser difference for dashed underlines compared to the dotted ones.

Dotted underlines still look vastly different in all browsers, but because my main browser is Firefox — and it renders them the best — I ended up using them.

If I were to pursuit cross-browser styles, I would go for background images and used SVG with stroke-dasharray instead, alongside applying “Box Decoration Break”.

Other Underline Styles

My blog’s design has more going on with the underlines: the color, the thickness, the hover, — but it is not limited only with dotted ones, but extends to regular links as well. That might be a topic on its own; I’ll blog about it on some other day.

But for today, that’s enough. Do you have styles that you apply to <details> and <summary>, or do you rely on browser defaults? I would be happy to hear from others!

Let me know what you think about this on Mastodon!

It is OK to Say “CSS Variables” Instead of (or Alongside) “Custom Properties”

Fri, 14 Nov 2025 00:00:00 GMT

Current music:: Rökkurró — Sjónarspil
Current drink:: Ceylon Tea

TPAC 2025 just ended, and I am positively tired. Attending it remotely, my sleep schedule is chaotic right now. I have many ideas for CSS-related posts in my list of ideas for November, but almost all of them require at least some amount of research and crafting demos.

Well! I found one note that I wanted to expand on, and which sounds tiny enough to be able to finish it in my altered state.

Let me repeat the title of this post: it is OK to say “CSS Variables” instead of (or Alongside) “Custom Properties”.

I won’t say that this is something contentious, but it was always mostly a thing where I always stumbled a bit before continuing using the terminology.

The official name of the corresponding CSS module is “CSS Custom Properties for Cascading Variables”. It’s URL’s slug is css-variables.

They are variables. More specifically: cascading variables. They change with the cascade: when different rules match, values can be overridden and change.

We can have animations that involve custom properties, or custom properties with values based on the viewport, containers, or something else — dynamic, responsive values that can vary for multitudes of reasons.

They are also custom properties, and even the more property-like when using @property. They can also be explicitly typed, while the rest of CSS is often typed implicitly. But — typed, unlike some other “programming languages”.

Ah, yes, CSS (and HTML) are programming languages, and anyone thinking otherwise is wrong. The best programming languages, according to me, by the way.

Oh, I am tired. But also right after finishing this last ~~day~~ night of CSSWG F2F, I successfully experimented a bit with one ongoing idea of mine, and now planning to write a proper nice article, for my main site, like I sometimes do. Stay in touch.

Let me know what you think about this on Mastodon!

My Most-Used Obsidian Plugins

Sat, 15 Nov 2025 00:00:00 GMT

Current music:: Helios — Dragonfly Across An Ancient Sky
Current drink:: Decaffeinated Earl Grey tea

I’ve used Obsidian for quite a while. While my vault’s contents are a chaotic mess, it really helps me to be the place where I can put my notes and then find them when the need arises.

I use a bunch of community plugins to improve a few workflows. And some of them I use more than others! That is a post about them!

The plugins will be in the alphabetical order. In the future, if I encounter another plugin that I will start using all the time, I’ll try to remember to update this list.

Advanced URI

A nice plugin, which I do not use by itself, but use it with my daily notes workflow — see the Calendar and QuickAdd plugins.

Maybe I need to find some other uses for this plugin, as it can unlock some other useful actions as well.

Calendar

I use the core “Daily Notes” plugin, well, almost daily. Whenever I have some idea, I quickly add it to my daily notes, where it goes with the exact time stamp of the idea in an unordered list. Then, I can go there and add any extra content or brainstorm a bit.

This plugin is very helpful both for accessing these daily notes, and for just having a calendar at hand. Usually, I can remember the approximate month/week when I wrote something down, and with this calendar, I can go and quickly look for it.

Hide Sidebars on Window Resize

This is a very tiny plugin that does just one thing. What thing? The one in its name. I use the Rectangle app by Ryan Hanson to quickly resize windows or move them to a different screen. With the wider windows, I have both sidebars open at the same time. But when it becomes narrower, it is very convenient to remove those sidebars automatically.

One thing it doesn’t do and that could be improved: it does not consider vertically split tabs. It would’ve been great if it did consider not just the window’s width, but the number of vertically split tabs, and adjusted when to hide sidebars based on this, hiding them earlier.

Other than that, once installed, this plugin is mostly “invisible” and just works.

Paste URL into selection

Another very simple plugin which also just does the thing in its title pretty well. You select some text, you have a link in your clipboard, you press paste — here you go. Nice.

QuickAdd

Another useful addition to my daily notes workflow: allows adding new paragraphs to the today’s note.

I use it in combination with the Advanced URI plugin and Alfred App, which allows me to open it, write q + enter, and start writing.

Recent Files for Obsidian

This is another very useful plugin that helps with my daily notes workflow. More specifically, it allows maintaining a list of recently open files that excludes the daily notes, as I already have quick access to them via Calendar plugin.

“Recent Files” allows me to have fewer open tabs and fewer pinned tabs, as opened files kinda “pin” themselves into this plugin’s list, and it becomes very simple to find something you return to a lot.

That’s it! Do you use Obsidian? What plugins do you use all the time? Please let me know! While my practice is usually “look for a plugin once I want to automate something”, sometimes you might not know that you need something.

Maybe even you found something in the above list that you were “oh, I did not know I need this!”

Let me know what you think about this on Mastodon!

Preparing Images For Pixelfed

Sun, 16 Nov 2025 00:00:00 GMT

Current music:: mewithoutYou — January, 1979
Current drink:: Thyme, rosemary & lemon infusion

I wanted to post another batch of already published photos from my Pixelfed, but something in its API does not allow me to fetch the photos as it previously allowed me to do, and I won’t have time to fix that part of my workflow for publishing them here.

However, I wanted to share for quite some time how I prepare photos before uploading them to Pixelfed, and now is a good opportunity to do so. There were a few things I noticed that made a difference in how pictures are displayed there.

I don’t know the details of how different Pixelfed instances can affect things, so what I will be talking about was tested on Pixey.org.

Problems

In order, from the most impactful, to less.

Color Profiles

Pixelfed strips ICC color profiles from the photos, which can lead to them being less saturated and not looking how you would expect them to. There is an open issue about this on Pixelfed’s GitHub.

This might be obvious, but it is pretty easy to forget about that.

**Solution: ** Export in sRGB, or, ideally, run the image through Squoosh.

Image’s Dimensions

Pixelfed instances have limits on the image dimensions, resizing the images when uploading, and doing it not with the best algorithm, resulting in images not being as sharp as you could want.

The limits for vertical and horizontal images (or — for the images’ width and height) can be different! On my instance, it is 1440px for width, and 1350px for height.

**Solution: ** Resizing images on your own before uploading, matching the limits. Then, Pixelfed will only recompress the image, but won’t resize it.

Image Compression

Pixelfed will re-compress your images, regardless of how much you managed to optimize them before uploading.

This is the common issue I have with almost any services: it doesn’t matter how much you care and how much you optimize an image before uploading it. Services almost never look at the resulting size of the image you upload, and always run their optimization, replacing your image with it. Even if the new image will weight more, and result in a worse result visually!

Solution: Export images in 100% quality. As Pixelfed will recompress the image anyways, this way you won’t lose on quality twice.

Squoosh App

I am using Squoosh to solve all these problems:

It will save the image as sRGB by default, applying the color profile if it is present.
I
I use the “Resize” option and make sure width&height are not bigger than the limit.

This results in an image that, in my opinion, looks the best once uploaded to Pixelfed. This is a web app, it is free, it runs all the processing on your own device and doesn’t upload the image anywhere.

I hope this helps someone! And maybe I am missing something that could make the images look even better? Do you have your own workflow that you use for this? Share it with me if so!

Let me know what you think about this on Mastodon!

Whitespace in Code

Mon, 17 Nov 2025 00:00:00 GMT

Current music:: Balmorhea — In the Rowans
Current drink:: Ginger & apple tea

I am working on a new article for my main site, for a new technique I invented, so this will be a shorter and lower-effort post (as, probably, those for the rest of the week).

I always liked to pay a lot of attention to how I format my CSS, with the roots of it coming from the conventions that Vadim Makeev shared when we worked together in ~2007–2008.

Some other conventions that I used at the time were enforced via the CSScomb formatter, to which I even contributed a bit at the time. It is sad that this project is no longer maintained, and that Prettier does such a poor job of formatting CSS.

I also already wrote one post in this blog about formatting CSS: “Calculation Indentation”.

Use More Whitespace

Currently, I don’t have spoons for formatting my CSS, but I try to polish my CSS examples that I put them in my articles, and, sometimes, for the components I am working on.

If I were to give one advice for formatting CSS, it would be “use more whitespace”.

Put extra lines between rules:

.button {
	…
}

.card {
	…
}

Put extra lines before comments, but no additional lines after:

/* My beautiful button. */
.button {
	…
}

/* A responsive card component. */
.card {
	/* We shrink the card to fit its contents. */
	width: max-content;

	/* Without `width: auto`, we need to limit the max. */
	max-width: 100%;
}

Group common groups of properties together:

.tooltip {
	/* It is year 42025, we support anchor positioning. */
	position: absolute;
	position-anchor: --anchor;
	position-area: bottom;

	/* TODO: use design tokens, maybe. */
	background: pink;
	box-shadow: 0 0.2em 0.4em -0.2em deepPink;
}

The reason to do all of these instead of lumping everything together is that having extra whitespace allows you to group related things together.

It is easier to tell two rules apart if they’re separated by extra lines, and especially if there are comments alongside: a comment will look more like a header when it has a bigger space before it and less after — and a common design principle is to “glue” headers to the content after.

Grouping common properties together makes it easier to tell what is going on, and makes it easier to put new declarations in the rule. That’s where CSScomb was very useful!

Do you have your own rules for formatting your CSS? It is often a very subjective matter, but it would be great to hear if there is anything you do differently.

Let me know what you think about this on Mastodon!

Minimal Reproductions

Tue, 18 Nov 2025 00:00:00 GMT

Current music:: GoGo Penguin — Murmuration
Current drink:: Thyme, rosemary & lemon infusion

I am continuing working on my new article, and while making examples for it, I stumbled upon a crash in Safari — both in its stable version and in Technology Preview. I managed to reduce it to a minimal reproduction and reported it — and in this post I want to encourage you to create minimal reproductions of any bugs you encounter too — for more than one reason.

Here is the bug that I reported: “Tab crashes when an element containing a scoped scroll-driven animation from an inner pseudo-element repeatedly changes display while depending on cqw”.

That’s a long title! But the conditions are also pretty specific — as it often goes with my experiments.

That said — the code I reported is as minimal of a reproduction as I could manage to reduce the original CSS to. From around 150 lines to around 30. There was a lot more going on before I stripped everything that did not impact the crash!

The first reason the minimal reproduction is helpful: you will understand what is going on much easier, and will be able to confirm to yourself if that’s really a bug, or some interaction in the specs you’re missing. Of course, for a crash this is not as important, but then by understanding what’s going on you will be able to report it better — with proper title and description. Not just “something is wrong”.

The second reason: it will be much easier to understand where the issue is for the engineers that will be working on fixing the bug. You’re likely already in the context of your code, you know what is likely to be not related, and it will be much faster for you to reduce it. You also know exactly about what the issue is, and could verify that it still happens with ease. And if the engineers working on the bug are more efficient with their time, and if the bug does not look intimidating to take from the backlog — the chances are it will be fixed much, much faster than otherwise.

The final reason: after creating a minimal reproduction, you will be left with a limited number of puzzle pieces that explode together. In CSS, it is always possible to do the same thing in multiple ways. Sometimes this is a hindrance which leads to the choice paralyzis, but in case of bugs, this is an advantage: for any code path that leads to the bug you can look for another road to your desired result. And anothe method might not cause the bug!

That’s what happened in my case: it wouldn’t be very nice if examples in my new article — and the technique at large — would cause random browser crashes. But by reducing things, I was able to identify a simple solution: while most conditions in the bug I reported related to the scroll-driven animations and setup around them, the simplest outlier was the presence of pseudo-element: simple tests shown that replacing a pseudo-element with a real element eliminated the crash. Oh well, the code will be not as efficient and with a more verbose HTML, but still working.

So — please, whenever you encounter bugs, try to find the minimal reproduction, understand what’s going on, and then report it. This will make the fix to become available faster for everyone, but, specifically for you, a possible workaround will be closer as well.

Let me know what you think about this on Mastodon!

Anchoring to a Containing Block

Wed, 19 Nov 2025 00:00:00 GMT

Current music:: Haru Nemuri — Lost Planet
Current drink:: Fruity infusion (pear, kiwi, mango, etc.)

I am still working on my new article! And today I stumbled upon an issue that I and some others had in the past: an inability to use an anchored element’s containing block with anchor positioning.

At least — to do so easily. This post is about how we can actually do so with just a few small changes to your usual anchor positioning setup.

I did not end up using this in my article, so decided to share today regardless.

The Problem

Look at this example:

Component is not available in RSS, visit the the site to access it.

fieldset {
	position: relative;
	anchor-name: --fieldset;
	margin-top: 1.5lh;
}

legend {
	position: absolute;
	position-anchor: --fieldset;
	left: anchor(inside);
	bottom: calc(anchor(outside) - 1px);

	padding-inline: inherit;
	border: inherit;
	border-bottom: 0;
	background: var(--CONTENT-BG);
}

<fieldset>
	<legend>Some legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

Here, we could expect the <legend> to be positioned correctly… but it doesn’t. It does not see the mentioned anchor, and thus the values for the corresponding inset properties become initial. This behavior is per spec:

possible anchor and positioned el have the same original containing block and either

Basically, if our anchor is our positioned element’s original containing block, this condition won’t match.

Last year, I opened an issue about this, and I saw other people also stumble upon this issue, for example, James Stuckey Weber also opened another issue about this.

Eventually, it was resolved to not change anything, but consider a way to adjust the containing block in the future.

But what can we do today?

The Solutions

Not Using Anchor Positiong

Ok, in this exact case we don’t even have to use anchor positioning, and could do just this:

Component is not available in RSS, visit the the site to access it.

fieldset {
	position: relative;
	margin-top: 1.5lh;
}

legend {
	position: absolute;
	left: -1px;
	bottom: 100%;

	padding-inline: inherit;
	border: inherit;
	border-bottom: 0;
	background: var(--CONTENT-BG);
}

<fieldset>
	<legend>Some legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

If you compare the two examples, you’ll notice one difference: where the “magical” 1px goes. In the non-working example it was in the bottom property, but in the working example it moves to left.

This is because anchor positioning takes borders into account, while regular absolute positioning uses a padding box for positioning.

In my today’s experiments, I actually wanted to measure the width of the border, so I needed to anchor to the outside of the containing block.

Basically, whenever we need to take the border into account, anchor positioning could help — but not easily if our anchor is our containing block.

Using `position: fixed`

The proper solution: to use position: fixed, as then we won’t be bound by the same containing block.

Without Scoping

However, we can’t just replace absolute with it: if we’d have several elements, then their containing block will become the viewport, and both anchored elements will use the same last visible anchor for the positioning:

Component is not available in RSS, visit the the site to access it.

fieldset {
	position: relative;
	anchor-name: --fieldset;
	margin-top: 1.5lh;
}

legend {
	position: fixed; /* The only change */
	position-anchor: --fieldset;
	left: anchor(inside);
	bottom: calc(anchor(outside) - 1px);

	padding-inline: inherit;
	border: inherit;
	border-bottom: 0;
	background: var(--CONTENT-BG);
}

<fieldset>
	<legend>First fieldset’s legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

<fieldset>
	<legend>Second legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

We don’t want that!

Adding Scoping

Thankfully, we have an anchor-scope property, and if we add it to our anchor with the same name, this element will be the last elements any children will see when looking for the corresponding anchor name, and use it:

Component is not available in RSS, visit the the site to access it.

fieldset {
	position: relative;
	anchor-name: --fieldset;
	anchor-scope: --fieldset; /* Required! */
	margin-top: 1.5lh;
}

legend {
	position: fixed; /* Not `absolute` */
	position-anchor: --fieldset;
	left: anchor(inside);
	bottom: calc(anchor(outside) - 1px);

	padding-inline: inherit;
	border: inherit;
	border-bottom: 0;
	background: var(--CONTENT-BG);
}

<fieldset>
	<legend>First fieldset’s legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

<fieldset>
	<legend>Second legend</legend>
	<div>Some fieldset’s content</div>
</fieldset>

The Only Issue…

If you look at this example in Safari (even in Technology Preview) or Firefox Nightly, then you might notice a few rendering issues with the anchored elements that use position: fixed.

Sometimes it works there, sometimes it doesn’t, with the position not updating correctly from time to time.

I will open bugs about this, but not today (unless someone else will beat me to it, wink wink).

Update from 2025-12-31

Good news: at least in the latest Firefox Nightly, the above example seems to work well! In Safari, it is still glitchy, mostly when there is a smooth scroll going on, but it is tolerable.

Conclusion

While it might seem that anchor positioning is already present in some stable versions of browsers, in reality it is further from being even baseline. If, today, Firefox would release anchor positioning into its stable version, even if Firefox itself will be perfect, there are enough issues, starting from feature’s usability (absent features like being able to change the containing block) to bugs in stable versions of browsers that prevent many use cases from being viable.

The Safari bug above is not the only issue I found when testing anchor positioning: Chrome also has at least one blocker that prevents many use cases. Maybe I will write about it some other day.

Let me know what you think about this on Mastodon!

Scope for Examples

Thu, 20 Nov 2025 00:00:00 GMT

Current music:: Jenn Champion — Going Nowhere
Current drink:: Thyme, rosemary & lemon infusion

With yesterday’s post, — “Anchoring to a Containing Block” — I started to use @scope for my code examples.

This is one of the most exciting use cases I saw for the @scope — an ability to do something like this:

Component is not available in RSS, visit the the site to access it.

p {
	outline: 2px solid var(--PINK);
}

<p>Hello!</p>

See how I render this code inline in my post, and the p selector is not applying to this literal paragraph that I am writing right now?

And, actually, let me show you how this looks like in my markdown:

<LiveExample isScoped require="at-scope">
```css
p {
	outline: 2px solid var(--PINK);
}
```
```html
<p>Hello!</p>
```

This is how I write all the examples in my blog: I have my custom Astro [Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/scope-for-examples/) component, which takes the Markdown code blocks inside, and both shows the corresponding code, but also outputs these code blocks’ content on the page, so I can just write my examples once, have their code visible, and not have to duplicate the effort when I need to update something.

In the above case you can see the isScoped prop: before I had it, all examples did output their code literally, so whenever I had to have similar examples, I had always to come up with some prefix or unique class names for them.

With isScoped, I wrap the content of the inner CSS block with just @scope {}, so that code will be equivalent to

@scope {
	p {
		outline: 2px solid var(--PINK);
	}
}

Which can be called “local scoping”, see the “Identifying Scoping Roots and Limits” section of the Cascading and Inheritance Module 6.

How it works is: if we add an HTML <style> tag in our HTML, and inside this tag there will be an @scope without the scope start selector, it will be scoped to that <style>’s parent element:

If no <scope-start> is specified, the scoping root is the parent element of the owner node of the stylesheet where the @scope rule is defined.

And that is very useful for any blog posts with code examples — this makes every example to work independently of others.

There are a few things I will need to improve with how I use these types of examples:

Sometimes, there is a need to share some styles across different examples. Possible solution: use named scopes, and overload the prop to allow also doing isScoped="foo", where I could mention some ident, and then both the example will get this ident automatically added as a class name to the example’s wrapper, and it will go into the @scope like @scope (.scope-foo) or something.
It can still be useful for understanding of the examples to have their full code, so maybe there could also be something done on the LiveExample’s side to add some automatic diffing of consequtive examples, where we could highlight the changed lines in some way? In yesterday’s post, that would’ve been pretty handy.

But… `@scope` is not Baseline?

Yeah, but I also write about non-baseline things. When writing about CSS features like anchor positioning or scroll-driven animations, or anything newer, there is no reason not to use @scope.

If you have a blog, write about modern CSS, and create inline demos there (not by embedding CodePens or anything else as <iframe>s), I highly recommend you to try @scope. It is cool.

Let me know what you think about this on Mastodon!

I Want to Rewrite Everything

Fri, 21 Nov 2025 00:00:00 GMT

Current music:: COVET — falkor
Current drink:: Fruity infusion (pear, kiwi, mango, etc.)

This whole week, I am switching between writing posts in this blog and working on my next article for my main site.

My blog has a much more modern setup for writing posts: it is based on Astro, and I enjoy tweaking the components that I use with it, like with my yesterday’s “Scope for Examples” post.

Writing posts with this setup is a joy, where it is effortless to add new interactive examples, and adjust things.

The old setup? It is an abomination of some old gulp custom config, with a bunch of custom JS and Hugo on top of it. The templating system that it has? One of the worst I used. Honestly, screw React, but JSX and the idea of components are a much better fit for what I usually want for building complex HTML pages. And with Astro not outputting any actual JS and pre-building everything in HTML is just great.

So, all of this might be one of the reasons why I am not writing longer and more polished articles on my site as often. I really would like to rewrite everything that I have there to use the same architecture I am using for my blog.

There are still many features that my old setup has that I did not yet implement here: sidenotes are much better there, examples with screenshots/video alternatives, some other aspects. But, eventually, I would really like to have just one system I maintain and use in both places. Ideally, in the same repo: currently, the sources for both are separate, and this makes it harder to maintain things or deploy things simultaneously.

If only I had more time! My current paid time off is running out, but I am already planning to return to this idea of rewriting everything at the end of December.

I need to still find a way to somehow keep the old setup alongside the new one, as it is likey impossible to (quickly) migrate everything from the old system to the new one. So what I am planning is to try and make it possible to merge both, and keep the old posts rendered with the old system, while allow writing new posts with Astro. We’ll see if it will work out!

I guess, this was a much less useful post for anyone reading, but I really want to just document — even if for myself — the process of me working on my website.

Let me know what you think about this on Mastodon!

On Perfectionism and Chaotic Messes

Sat, 22 Nov 2025 00:00:00 GMT

Current music:: Keaton Henson — You
Current drink:: Ginger & apple tea

I don’t have a topic for today, so I decided to ramble a bit on a random topic: wondering how the two things in the title of today’s post can live at the same time in me. I have a tendency for perfectionism. At the same time, I often surround myself with various degrees of chaotic mess.

I think the answer is in the availability of spoons.

Would I want this chaotic mess that is my room, or my file system, or obsidian vault, or everything else, to be less messy, organized, structured, and perfect? Oh, I would.

Do I know what to do and how to approach achieving this? Yep.

Would I do it? I can’t: I don’t have enough spoons for everything. I think I might’ve lost all of them in CSS (Cascading Spoons Supply).

In my notes for the November ideas, almost everything is about CSS. I am on “vacation”, and that means that I can, finally, spend as much as I want on CSS. Although, it appears that I can’t do it too many days in a row — need some rest time, after all. But oh how I wish I could do all of this every work day, just work on CSS.

CSS is in the foundation of my hierarchy of needs, it is physiological at this point.

Any spoons that do not feed the CSS demon are wasted.

The problem: CSS is so large, I don’t even have enough spoons to put them into every declaration. There is just so much to think about, to experiment, to delve into!

Oh, well.

Let me know what you think about this on Mastodon!

Photo Walk, April

Sun, 23 Nov 2025 00:00:00 GMT

Current music:: Flip Grater — Hymns
Current drink:: Thyme, rosemary & lemon infusion

I am back with reposting some of my old photos from my Pixelfed, but now in my blog. I did not fix the API issue that prevented me from doing it the last time, but made a workaround that worked well enough.

Curiously, the first two images from this post can illustrate what I was talking a week ago in my “Preparing Images For Pixelfed” post.

The first image from this series was published before I saw the issue with the color profiles and resizing/recompression:

“A blossoming tree.” (image is not available in RSS, visit the the site to access it.)

It has a bit of a flatter profile than what I inteded to have, and is not as sharp as it could be.

After this image, I changed my workflow, and here is, hopefully, the quality of photos that I’ll try to post from this point on (unless I will report some of the older ones, of course):

If the last two posts that I shared had photos made with the 17mm prime lens, this time I went to the opposite side: I bought a second-hand lens from MPB — Olympus M.Zuiko 75mm f/1.8.

Before that, my favorite lens was the 45mm one, but I think fell in love with this lens after my first walk with it. I really like to hunt for details, and I am fascinated by the out-of-focus rendering this lens produces.

This metal lens is pretty big for Micro Four Thirds, and is quite heavy: a bit more than 300g. Initially, I thought that it would not be as comfortable as other lenses on my OM-3, which doesn’t have the best grip, but at some point I stopped noticing it.

“Over the wall.” (image is not available in RSS, visit the the site to access it.)

This time I went first to the park, then with a goal to go down the hill to the Seine and then back.

I am usually shy, and try to avoid being obvious when shooting people, but this lens really allows being very far away, not feel like you intrude, and catch some nice small scenes.

“In the park.” (image is not available in RSS, visit the the site to access it.)

The next photo, especially with that crop, demonstrates the background compression that 75mm — 150mm equivalent on full frame — can achieve. This is the edge of the terrace, with the La Défense in the background, around ten kilometers afar.

Scyscrapers? They look nice in the distance, but that’s it. I would rather be closer to the tiny buildings like this one:

“I wonder what’s there inside” (image is not available in RSS, visit the the site to access it.)

And closer to these fellows as well:

In this park there are always people, and there is always someone standing there at the edge and marvelling the views.

“People on the terrace.” (image is not available in RSS, visit the the site to access it.)

Though, some are not that interested in them.

“Dog.” (image is not available in RSS, visit the the site to access it.)

Going through the park, I started to go down the hill. One notable thing there is this pavillon visible:

“With not that old buildings behind it.” (image is not available in RSS, visit the the site to access it.)

The telephoto lens makes it possible to catch some nice details, like the statues in this pavillon’s garden with maze hedges.

The views are very nice both on the terrace, and on the way down: bridges, trees, old buildings, a lot of things to look at.

“A Bridge.” (image is not available in RSS, visit the the site to access it.)

Not that many people walk this way, uphill or downhill. I once went there, and the path is generally pleasant.

There are many ways down, and I used the one I chose for the second time, as the last time I saw a bunch of squirrels there. This time I also saw them, but did not manage to make any good photos, oops.

“Another dog!” (image is not available in RSS, visit the the site to access it.)

It is always nice down by the river, although, while 75mm is nice, it is just barely enough to catch some birds there: would need a much more powerful lens for that. But not sure if I want one.

The riverbank is pretty diverse, with boardwaks, pathways, etc. It is rather nice there.

“A boardwalk.” (image is not available in RSS, visit the the site to access it.)

The river is wide, there are islands on it, with trees almost falling into the water.

Some tall trees on the other side, and some tiny trees on this one.

“Green grass.” (image is not available in RSS, visit the the site to access it.)

And some dinosaurs swimming in the river.

Managed to catch this composition in the end, with the lens allowing to get it without too much cropping.

“A rectangle.” (image is not available in RSS, visit the the site to access it.)

That’s it for now! I don’t have other full photo walks I did afterwards, but I have a lot of older photos that I will be slowly publishing, so it is likely the next photo posts will have photos from my older camera and lenses.

Let me know what you think about this on Mastodon!

Play With Inherit Function

Mon, 24 Nov 2025 00:00:00 GMT

Current music:: MASS OF THE FERMENTING DREGS — New Order
Current drink:: Thyme, rosemary & lemon infusion

One of the things that might flight under many people’s radars is the incoming inherit() functional notation. Not the inherit keyword — we had it for quite a while already.

The Context

In 2018, Lea Verou opened an “inherit() function: like var() for parent value, for any property” issue in CSSWG GitHub, in 2021 CSSWG resolved to adopt it, and was stale since then, until, finally, last month, Anders Hartvoll Ruud sent an Intent to Prototype for it, and started implementing it in Chromium. Did this happen because I pestered him at this year’s CSS Day asking how hard it would be to do? Who knows!

But now it is available in Chrome Canary with the “experimental web platform features” flag, so, if you want, you can go play with it! It only works for custom properties for now, for similar reasons of why we don’t have style queries for regular properties, but maybe one day this will change, although I won’t wait for this.

So, yeah, experiment!

Like, for example, Stuart Robson already did with his “Making Context-Aware Components: How CSS inherit() Could Simplify Design Systems” article.

Or — how I did last year with my “Self-Modifying Variables: the inherit() Workaround”, although there I wrote about a workaround that we can use instead today. This workaround relies on container style queries though, so not really production-ready, but still better than nothing!

Some Examples

The following examples will not work anywhere where the inherit() is not supported — so, you can open Chrome Canary if you want to look at them!

I will just adapt some of the examples I had in my article about its workaround, so nothing too new. But, hey, that article was not super popular, so maybe you missed it.

I won’t provide any screenshots here — if you want to check how things should look like, go to the above article — it has both live examples and screenshots for them.

Element Depth

I slightly adjusted my original example: we can have a --depth custom property, and bump its value for every component of the same type that is nested inside itself:

Component is not available in RSS, visit the the site to access it.

.test {
	--depth: calc(inherit(--depth, 0) + 1);

	--padding: 1em;
	padding: var(--padding);
	background:
		oklch(
			from var(--BG-FROM)
			l c
			calc(var(--depth) * 127)
		)
	;
	border-radius: calc(
		4.5 * var(--padding)
		-
		var(--depth) * var(--padding)
	);
	border-start-start-radius:
		calc(0.5 * var(--padding));

	&::before {
		counter-reset: depth var(--depth);
		content: counter(depth);
	}
}

<div class="test">
	<div class="test">
		<div class="bar">
			<div class="test">
				<div class="test">
					<div class="test"></div>
				</div>
			</div>
		</div>
	</div>
</div>

With the --depth incrementing on every element, we can then use it for anything: adjust colors via their relative syntax, make the border-radius decrease with the depth level, and so on.

I love my second example from this article: this is the use case that I very often stumble in my practice — the need to have a nested list, where the indentation of elements grows, but each line should be interactive from start to end. Without inherit() or its workaround, we generally had to express the depth in HTML in some way, but now this just works:

Component is not available in RSS, visit the the site to access it.

ul {
	--depth: calc(inherit(--depth, 0) + 1);

	display: block;
	width: fit-content;
	padding: 0 !important;
	margin: 0 auto;
}

li {
	padding: 0;
	margin: 0 !important;
	list-style-type: none;
}
li::before {
	content: "";
}
li > a {
	display: block;
	padding: 1em;
	padding-block: 0.25em;
	padding-inline-start:
		calc(var(--depth) * 2em - 1em);
	background:
		oklch(
			from var(--BG-FROM)
			l c
			calc(var(--depth) * 127)
		)
	;
	border-radius: 1em;
	border: 2px solid transparent;
	background-clip: padding-box;
	text-decoration: none;
	color: var(--color);

	&:is(:hover, :focus-visible) {
		border-color:
			oklch(30% 1 calc(var(--depth) * 75));
	}
}

<ul>
	<li>
		<a href="#">Menu item</a>
	</li>
	<li>
		<a href="#">Menu item</a>
		<ul>
			<li>
				<a href="#">Menu item</a>
				<ul>
					<li>
						<a href="#">Menu item</a>
					</li>
					<li>
						<a href="#">Menu item</a>
						<ul>
							<li>
								<a href="#">Menu item</a>
								<ul>
									<li>
										<a href="#">Menu item</a>
									</li>
									<li>
										<a href="#">Menu item</a>
									</li>
								</ul>
							</li>
							<li>
								<a href="#">Menu item</a>
							</li>
						</ul>
					</li>
				</ul>
			</li>
		</ul>
	</li>
</ul>

Again, the only thing we need to do here is this:

--depth: calc(inherit(--depth, 0) + 1);

And then we’re free to use that custom property in any way we want.

Swapping Values

The last example is a fun one: an ability to swap variables around:

Component is not available in RSS, visit the the site to access it.

:scope {
	--a: var(--GREEN);
	--b: var(--PINK);
}

.swapped {
	--a: inherit(--b);
	--b: inherit(--a);
}

.a { background: var(--a); }

.b { background: var(--b); }

p > span {
  margin: 0.5em;
  padding: 0.25em 0.5em;
}

<p>
	Regular:
	<span class="a">A: green</span>
	<span class="b">B: pink</span>
</p>

<p class="swapped">
	Swapped:
	<span class="a">A: pink</span>
	<span class="b">B: green</span>
</p>

Again, without inherit() or my workaround this is not possible.

Go On!

This is a really great feature: I hope that other browsers will also look into experimenting and implementing it. It might be simple, but it unlocks many nifty use cases.

And even if you can’t think of one now — when you will be writing CSS, try to remember that we will get this in the future.

Let me know what you think about this on Mastodon!

Responsive Cyclic Margins

Tue, 25 Nov 2025 00:00:00 GMT

Current music:: Mitski — Pearl Diver
Current drink:: Infusion of hibiscus, apples, rosehip, and orange peels, with cherry flavor.

The title of this post might not seem like a big deal, but the problem I will talk about was pretty fun to work out: how do you make a margin between elements responsive based on the available space in their parent, and such that it does not collapse in a min-content context?

The Problem

That might seem to be pretty specific, but let’s say we have an element with two parts like a button, with the text disappearing when there is not enough space:

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon">🌐</span>
	</button>
</p>

:scope {
	--border: 1px;
	--padding: 8px;
	--icon-size: 1em;
	--min-width: calc(
		var(--icon-size)
		+
		2 * var(--border)
		+
		2 * var(--padding)
	);
}

p {
	overflow: hidden;
	resize: horizontal;
	outline: 1px solid var(--PINK);
	padding: 1em;
	width: min-content;
}

button {
	display: inline-flex;
	max-width: 100%;
	min-width: var(--min-width);
	padding: 0 var(--padding);
	border: var(--border) solid var(--GREEN);
	background: var(--CONTENT-BG);
	border-radius: 1lh;
	font: inherit;
	cursor: pointer;
}

.ellipsis {
	overflow: hidden;
	white-space: nowrap;
	text-overflow: ellipsis;
}
.icon {
	display: inline-block;
	width: var(--icon-size);
	text-align: center;
	flex-shrink: 0;
}

What we want is to add a margin between the text and icon here, but make it disappear when the button collapses.

Any static margin added to either span there will be still there when we collapse the button to be narrower than the available space:

Component is not available in RSS, visit the the site to access it.

<p style="width: var(--min-width);">
	<button type="button">
		<span class="ellipsis with-margin">Hello, world!</span>
		<span class="icon">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon with-margin">🌐</span>
	</button>
</p>

.ellipsis.with-margin {
	margin-right: 0.5em;
}
.icon.with-margin {
	margin-left: 0.5em;
}

And, because our buttons has to shrink to fit its contents, we can’t use inline-size containment and size the margin via container query length units. So, what to do?

An Attempt

You could think: hey, we can use % in CSS, which will be evaluated based on the width of the parent element… Could we use it in some way, like with a calculation?

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon with-naive-percentage">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon with-naive-percentage">🌐</span>
	</button>
</p>

.icon.with-naive-percentage {
	margin-left: clamp(
		0px,
		100% - var(--min-width),
		0.5em
	);
}

It seems to wor— oh wait, why is there an ellipsis? And even when we expand our resizable paragraph, it stays this way?

What we attempted to do is to make it so we will have a margin that depends on the parent’s width, and goes from 0.5em to 0px. By subtracting the --min-width variable we can make it go to zero when approaching that min-width.

And it kinda works: when it is narrow, there is no margin, when it is wider — margin appears, but something breaks.

Percentage Evaluation

The answer to what is happening — why we have the text truncated even though it seems like we should have space available, lies in the “Intrinsic Contributions of Percentage-Sized Boxes” section of the “CSS Box Sizing Module Level 3” spec, specifically the paragraph “d.”:

[…] for margins and paddings (and gutters), a cyclic percentage is resolved against zero for determining intrinsic size contributions.

Because the button shrunks to its max-content width when it is inline-…, this width is calculated by adding up all the childrens’s contibutions, and for our margin we substitute any % inside with 0. So, for calculating this width, the following:

margin-left: clamp(
	0px,
	100% - var(--min-width),
	0.5em
);

Can be treated as

margin-left: clamp(
	0px,
	0px - var(--min-width),
	0.5em
);

And so it will become just 0px, so the total width of the whole button will consist of its borders, paddings, text content, and the icon. Plus zero for our margin.

Then, knowing this width, we start to layout everything inside, and according to our formula the margin becomes 0.5em as the width is quite large… but that reduces the space available for our text, so it becomes truncated!

The Solution?

To solve this, we can introduce even more percentages but in reverse!

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon with-percentage">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon with-percentage">🌐</span>
	</button>
</p>

.icon.with-percentage {
	--margin: 0.5em;
	margin-left: clamp(
		max(0px, var(--margin) - 100%)
		,
		100% - var(--min-width)
		,
		var(--margin)
	);
}

Now it works! When wide — without collapsing — the margin is 0.5em, when narrow — it is zero.

What we did is replaced the lower boundary of our clamp() with a max() that, when considered in a cyclic percentage context results in 0.5em, and otherwise results in 0px. Whoa!

…Except for the Safari Bug

Ooops. That’s what happens when you test out an obscure place in CSS, and check how it behaves in different browsers. Instead of only evaluating the % as zero, Safari just throws the whole calculation away and replaces the whole margin with zero T_T

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button">
		<span>button</span>
	</button>
</p>

button > span {
	margin: calc(0% + 50px);
}

Safari renders this example not as you would expect… Of course, I opened a bug about this.

The Working Solution

Right after I published this post, I suddenly decided to test what will happen if, instead of a margin, we would use a gap? **It works! **

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button" class="with-gap">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button" class="with-gap">
		<span class="ellipsis">Hello, world!</span>
		<span class="icon">🌐</span>
	</button>
</p>

.with-gap {
	--gap: 0.5em;
	gap: clamp(
		max(0px, var(--gap) - 100%)
		,
		100% - var(--min-width)
		,
		var(--gap)
	);
}

So, this is the solution I will recommend: instead of a margin, use a gap, with the rest of our calculations remaining in place: without the negative cyclic percentage condition the button would still collapse, but now the gap works the same in all browsers — likely because it was implemented later than margin. Ooof.

An Alternative Flex Solution

While I like the solution with the gap, and when Safari will fix the bug with margins/paddings, this technique could be potentially used in non-flex contexts (what about floats?), the next morning after publishing this article, I decided to think of possible alternative solutions.

Thinking about gap and flexbox, I found a solution that was likely one people use to achieve this effect right now: having a shrinking spacer element.

Component is not available in RSS, visit the the site to access it.

<p>
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="spacer"></span>
		<span class="icon">🌐</span>
	</button>
</p>
<p style="width: var(--min-width)">
	<button type="button">
		<span class="ellipsis">Hello, world!</span>
		<span class="spacer"></span>
		<span class="icon">🌐</span>
	</button>
</p>

.spacer {
	width: 0.5em;
}

Well, that’s pretty simple! The main con of this solution is that it requires one additional element per gap that you want to make responsive, but there are a few pros as well:

Unlike gap and similar to margin, it is possible to style each gap separately.
In previous solution, we had to know the min-width to describe the gap, here we rely on the default flex-shrink behavior.
The shrinking itself is much smoother, and we can control the ratio of how the gap shrinks compared to the other elements by using different values of flex-shrink.

Conclusion

Not always you stumble over a cyclic percentage issues, and not always you can overcome them by exploiting the same substitution to zero with conditional calculations.

I feel this is just a glimpse of what these kinds of calculations could achieve, and I invite you to also try and hack any similar places in the same way. Maybe you’ll stumble over something fun too!

As usual, it is also fun how we can find different solutions for the same problem in CSS, each with its own pros and cons. Similar to what I wrote in “Minimal Reproductions”, knowing what exactly does not work allows you to pursue alternative solutions and find one that works.

Let me know what you think about this on Mastodon!

Conditional JSX in Astro

Thu, 27 Nov 2025 00:00:00 GMT

Current music:: Will Driving West — Walls
Current drink:: Lemongrass, Ginger & Black Pepper tea

This is me documenting the way I am handling some of the more complex conditional rendering in Astro’s JSX. Well, not strictly JSX — but its “Component Template” part of .astro components and assigning them to variables.

The Problem

In React/Preact, inside a .jsx/.tsx it is possible to save snippets of JSX code to variables and then use them conditionally, like this:

const MyComponent ({ linkText, isDiv = false }) => {
	const someContent = (
		<a href="#hello">{linkText}</a>
	);
	return (
		<div class="wrapper">
			{isDiv ? (
				<div class="inner">
					{someContent}
				</div>
			) : (
				<span class="inner">
					{someContent}
				</span>
			)}
		</div>
	);
}

This example is nonsensical, but you should get an idea: we’re able to define some JSX code in the function body, and then reuse it inside various conditionals in the component’s return.

This is very useful when you have some complex content, but then in different setups it could be rendered in different contexts, or in a different order.

In .astro components, if you’re coming from React or Preact, it is easy to misunderstand the component’s Script part as being the function’s body, and the Template as the return.

But the problem: it is not possible to save snippets of HTML in the Script part! So it can be pretty awkward to work with more complex HTML structures.

If you were to try writing something like this:

---
const { linkText, isDiv = false } = Astro.props;
const someContent = (
	<a href="#hello">{linkText}</a>
);
---
<div class="wrapper">
	{isDiv ? (
		<div class="inner">
			{someContent}
		</div>
	) : (
		<span class="inner">
			{someContent}
		</span>
	)}
</div>

You would get an error:

[ERROR] Unexpected ";"

The Solution

The solution for this that I found: good old IIFE, or “Immediately Invoked Function Expressions”.

Astro allows JavaScript Expressions inside the Temlpate part. Those are usually there for conditions, maps, and so on. And — they support HTML inside, so you could do things like {list.map (item => <li>{item}</li>)} that you could be used to.

But that means that nothing stops us from doing this:

---
const { linkText, isDiv = false } = Astro.props;
---
{(() => {
	const someContent = (
		<a href="#hello">{linkText}</a>
	);
	return (
		<div class="wrapper">
			{isDiv ? (
				<div class="inner">
					{someContent}
				</div>
			) : (
				<span class="inner">
					{someContent}
				</span>
			)}
		</div>
	);
})()}

This works! The HTML is correctly parsed and assigned to the someContent variable, which then can be reused as you wish.

A good way to think about it if you’re approaching to this from React/Preact mindset:

Treat the Script part as the outside of your component’s function body. All the imports, helper functions, and static calculations could go there.
The function body of IIFE is now the place where you could define any reusable snippets of JSX. Nice.
Its return is what will be rendered. That means that you could also benefit from early returns, and simplify your conditions!
You could even put the Astro.props as the argument of that IIFE, and then destructure props as if you were authoring a React component… But why?

Offtopic: Upgrading Astro

I love that Astro is prebuilt statically by default, so all this logic will exist only before build, and the final HTML will be clean and nice.

Before writing this post, I upgraded Astro from 4.14.4 to 5.16.2 and did not encounter almost any problems… Or so I wrote initially, only to find out I couldn’t publish my blog, even though npm run dev worked perfectly.

There were a few issues:

Random LightningCSS Warnings

I noticed that when running npm run dev I got the following warnings from LightningCSS:

[WARN] [vite] [vite:css][lightningcss] …

Solution: I suppressed them by passing logLevel: 'error' to vite inside astro.config.mjs.

Node.js Version Requirement

I use Netlify, and apparently it runs an older version of Node.js by default, and Astro 5 stopped supporting it.

Solution: add a supported node version via .nvmrc.

`highlighter.codeToHtml is not a function`

Ooof, this one was a hard one! I found one post that mentioned this issue: “Astro Code Toggle Component” by Daniel Corin, but there the author did not debug what exactly is going on, stopping at noticing that the issue was in the Astro’s Code component, and reimplementing the highlighter on their own.

Debugging it myself, and logging what’s going on, I noticed that the highlighter in question had a different method available, which worked. The types did complain — and this seemed like an issue of something in dependencies.

Looking at my package-lock.json I found that the library that should provide that highlighter was @astrojs/markdown-remark, and it was not on the latest version. Trying to force the latest version in my package.json shown the reason why it wasn’t the latest: another package — @astropub/md by Jonathan Neal had an earlier @astrojs/markdown-remark version as its peer dependency!

The solution: override the dependency specifically for @astropub/md in my package.json while adding a newer version by default:

{
	"dependencies": {
		"@astrojs/markdown-remark": "^6.3.9",
	},
	"overrides": {
		"@astropub/md": {
			"@astrojs/markdown-remark": "5.3.0"
		}
	}
}

Oof, this worked! Ideally, I guess, it might be time to remove the @astropub/md — I only use it to render markdown for RSS, and I think there is now a better way to do it through Astro, so maybe one day (when my solution stops working?) I’ll return to this.

Ah, and I had to add --legacy-peer-deps to the NPM_FLAGS environmental variable in Netlify to make it run npm install --legacy-peer-deps as otherwise it was erroring out.

That’s It

I also looked at my other dependencies, noticed that there was Preact, which I experimented for a while years ago, and decided to remove it and its Astro integration as well — after all, I did not end up using it for anything.

I hope that this post will help you if you’re working with Astro, and, like me, is unfortunate to come to it with React preconceptions. Although, even if not, I think this IIFE pattern inside Astro templates is still fun!

And — debugging the build issues took much longer than I wanted, and three times as long as it took writing the rest of this post. Oh hey, it is modern front-end for you.

Let me know what you think about this on Mastodon!

Bolder Links

Fri, 28 Nov 2025 00:00:00 GMT

Current music:: Steve Pardo — Wave Dancer
Current drink:: Thyme, rosemary & lemon infusion

This is another post about a small design tweak that I made around two years ago to both my blog and main website. I never shared it, because, well, it feels very small. But I liked it a lot, and I don’t think I could ever come back, so why not write about it?

The tweak is, you’ve guessed — make the font-weight of most links on my website bolder. That’s it, that is the crux of the change.

Component is not available in RSS, visit the the site to access it.

<ul style="margin:0">
<li><a href="./#test2" style="font-weight: unset">This is a regular normal link</a>, alongside some text.</li>
<li><a href="./#test" style="font-weight: 600">This is a nice, slightly bolder link</a>, alongside some text.</li>
<li><a href="./#test2" style="font-weight: bold">Regular bold link</a>, alongside some text.</li>
<li><a href="./#test2" style="font-weight: 900">This one maybe too bold</a>, alongside some text.</li>
</ul>

I chose the 600 weight for my blog — slightly less than the default 700 for the bold keyword. And, for sure, not the boldest 900.

The small bump in weight gives links a tiny buff in contrast, while not making them stand out too much. One of the reasons I wanted to give them that bump in contrast is because I carefully chose the text color for both regular and visited links.

I wanted to keep a more vivid hue while not making it too dull, at the same time keeping enough contrast with both the page background, and the surrounding text. Even though I have underlines on my links, I dim them slightly, and having an extra affordance feels good in addition.

As I already mentioned, I kept this style for at least two years now, and I don’t think I would go back. I got used to it, and I like having this small barely noticeable tweak present in my blog and site’s designs.

I wonder if you ever, while visiting my websites, noticed this tiny aspect of it?

Let me know what you think about this on Mastodon!

Build Bridges

Sat, 29 Nov 2025 00:00:00 GMT

Current music:: 36 — Inside (2:56AM Mix)
Current drink:: Lemongrass, Ginger & Black Pepper tea

This is a very quick shout-out to the Bridgy Fed project by Ryan Barrett.

Its goal is to connect people across otherwise unrelated federated network: Fediverse, Bluesky, and even IndieWeb sites.

After the exodus from more corporate and capitalist networks, people ended up in different parts of the web. Each segment could be well-connected inside, but if you want to participate everywhere where people are now, you often need to create and maintain multiple accounts.

I often see people reposting the same thing in multiple places — which is fine, but not everyone has the spoons to do so. Not everyone is also ready to create an account in a network they do not understand or do not like.

That’s where Bridgy can really help: it is the easiest and most straightforward way to connect your account to other networks.

If you’re on Mastodon or elsewhere in the Fediverse and want to make it possible for people from Bluesky to follow you, you can either log in with your account here or just follow the @[email protected] account from your client (you can use search to find it there via its handle).
If you’re on Bluesky, and want to make it possible for people on Mastodon and the Fediverse at large to follow you, you can either log in with your account here, or just follow @ap.brid.gy from Bluesky.

That’s it. Bridgy works as opt-in — nothing is bridged without your consent, and by default it will only bridge your public posts.

Here is, for example, my bridged account on Bluesky, where the posts from my Mastodon profile go automatically.

And here is my bridged Pixey (Pixelfed instance) account where the photos from my Pixey gallery go.

Bridgy even handles replies, DMs, and more. It is zero maintenance, and there is zero reason not to use it.

If you know people who are only present on one of the networks and are not bridging their accounts — nudge them to do so!

The more interconnected our web is, the more powerful it is. I find it awesome that vastly different networks can talk to each other thanks to projects like that.

Let me know what you think about this on Mastodon!

Third Complete November

Sun, 30 Nov 2025 00:00:00 GMT

Current music:: Balún — Camila
Current drink:: White tea with peppermint

For the third time, third year in a row, I managed to write a post for every day of November.

I was tired at the end, and postponed writing many posts until the end of the day, but it felt easier than the last two previous years.

The hardest part was: I decided not to post about CSS or frontend on weekends, and I ended up with more notes for what to write about CSS, and couldn’t find many topics for non-CSS posts.

However, I still did write some CSS on weekends.

Anyways, I don’t think the quality of the posts was that good, but it is better than nothing, right? The necessity to write posts was nice as a way to push myself to actually publish stuff.

I won’t go through all the posts that I wrote about CSS, but will recommend you check out these three if you missed them:

“Fixing Baselines” — a small technique that I used for a very long time, and finally found an opportunity to write about.
“Inline Custom Identifiers” — a post about an approach to naming things and connecting them to other elements that require unique identifiers in CSS via inline custom properties.
“Anchoring to a Containing Block” — the way to fix a very common anchor positioning issue that I stumble over and over again.

I also wrote a few posts about some of the design tweaks I ended up using for my blog and website through the iteration over the years:

“Uneven Inline Paddings” — usually a not noticeable thing to visually balance the left-ragged text.
“Styles For Secondary Interactive Elements” — a more noticeable thing, which I don’t see people using often.
“Bolder Links” — a more subtle thing I do for around two years.

There are more posts that I could write about, but I think I’ll stop. Usually, in these last few years, I do a roundup of things I did for the whole year, and I will likely write about some of them there.

The best part: I have more notes about CSS than I could write about. Many of those topics were a tiny bit too big for a quick daily post, so I hope I will manage to start writing and publishing them over time.

And there is also one big article that I started writing, but did not manage to finish, partially because some of my time was dedicated to those daily posts. But — I for sure want to finish and publish this article in December. It should be a pretty good one, I think.

See you next month.

Let me know what you think about this on Mastodon!

My 2025 in CSS

Wed, 31 Dec 2025 00:00:00 GMT

Current music:: Every Gentle Air — Under Water, Under Ice
Current drink:: Yunnan tea

Intro

For me, 2025 was a much less productive year than 2024 and 2023. A mix of industry and world frustrations, personal issues, and just certain people being mean — all of that made me live on borrowed spoons for most of the year.

Oh well! I am not sure if I will recover fully in 2026, but I’ll try to do what I can. And it is not like 2025 was without its bright sides.

This post is a roundup of everything I wrote about CSS, so if you missed something — it is a good way to catch up!

My Articles and Techniques

Compared to the six articles I published in 2024, I managed to get out only two new ones — both at the beginning of the year. That said, I really like how both of them ended up, and if you missed them — I recommend finding time and reading them. You will likely need a lot of time — my articles do not become shorter — but, I promise, even beyond their premise, they contain many curiosities that I did not see anyone talk about.

“Pure CSS Mixin for Displaying Values of Custom Properties”

January 27. This was one of the most complex things I did. Even though it is not strictly practical, I still find myself using it while working on my experiments. It works! While it is based on my 2024’s “Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins” technique, there are many other small things to learn from the way I wrote this mixin.
“Passing Data into SVG: Linked Parameters Workaround”

March 24. In some way, this article was twelve years in the making. This is a topic that is still not solved in the Web Platform, and while there is a spec for it, no browser implemented it yet. There are many moving parts and approaches that I describe in this article. While the overall experimental technique is far from being practical, some of those details can be applied wider.

Some of My Blog Posts

I was unable to return to posting bookmarks, so I wrote fewer posts than in 2024. I still managed to do the whole November challenge, where I wrote one post every day for the whole month, making it the third year I completed it. I find this challenge pretty useful, as it allows getting out some of the things I could not find an opportunity to write about otherwise — especially this time, I managed to share many small but impactful things.

Here are some of these posts that I recommend you to read:

“Future-Proofing Indirect Cyclic Conditions”

May 31. This is a follow-up to my “Indirect Cyclic Conditions” article that I already mentioned, in which I had to find a way to fix it to work with the changes in the spec and implementation that broke my technique.
“Functional Capturing”

June 3. This is also a follow-up, now to my “Captured Custom Properties” post, but now looking at how we could use custom functions in CSS to achieve a similar capturing behavior.
“Inline Custom Identifiers”

November 3. A post in which I name and share a pattern I used for a few years. I continue using it, and highly recommend look at it if you’re planning to work with scroll-driven animations, anchor positioning, and other newer CSS features that require unique identifiers.
“Renaming Outer Variables in CSS Functions”

November 4. A post about hidden mini-feature of custom functions. It might not be something very useful in practice, but as we start to experiment with custom functions and mixins more, I believe this will find its use.
“Zombie Styles”

November 5. A post that names a problem that happens occasionally with CSS, especially when complex build steps are involved.
“Box-Decoration-Break”

November 6. A post reminding about a not very common CSS property which is yet to become baseline in theory, but which can be already used for many use cases alongside its -webkit- prefixed version.
“Fixing Baselines”

November 7. This one could’ve been an article on my main site, potentially. While the technique itself is not novel, I did not see many people write about it, and I find it returning to it year over year.
“Uneven Inline Paddings”

November 10. While I can’t say I am good at design, over the years I gathered a few barely noticeable design tweaks that, I thought, are worthy to be shared. This is one of them.
“Named Container Presence Check”

November 11. A post about how we can check for the presence of some named containers today, while the corresponding native CSS feature for this is not yet available in all browsers.
“Responsive tab-size”

November 12. A fun way to use typed arithmetic for making the tab-size property be responsive to some container’s width.
“Styles For Secondary Interactive Elements”

November 13. Another design tweak, one that I also use for a while, and recommend you to try as well.
“Whitespace in Code”

November 17. A very short post about a small tip for improving the formatting of your code.
“Anchoring to a Containing Block”

November 19. A post about one anchor positioning gotcha, where it is not possible to anchor an element to its containing block with absolute positioning, and a workaround that involves fixed positioning and anchor-scope.
“Scope for Examples”

November 20. A short post about an @scope use case that I expect will be very popular, especially in blogs of those who write about CSS, as it simplifies creating examples for articles a lot!
“Play With Inherit Function”

November 24. A post about how inherit() function is now available for testing in Chrome Canary. I expect this function to be tremendously useful once it is in all browsers, as it unlocks some of the API designs and ways to write code that were not possible without complex hacks before.
“Responsive Cyclic Margins”

November 25. A post about a few ways of making some margins or gaps collapsible to zero without compromising the max-content dimension of the element they’re used in.
“Border: 2px double”

November 26. A tiny “fun fact” about how 2px double borders are rendered. No interop in sight.
“Bolder Links”

November 28. Last design tweak I shared this year for increasing the contrast of links compared to the body text style.

CSS Working Group

A big part of my involvement with CSSWG this year was thinking about potential standardisation of the “fit to width” technique.

After my 2024’s article “Fit-to-Width Text: A New Technique”, in April of this year it was resolved to start working on a native CSS feature for it.

There was a lot of valuable feedback from the community, as well as a Google Chrome team’s explainer and experimental implementation, which were followed by more discussions and issues, some of which are still ongoing.

I wrote two blog posts about some of that:

“Fit-to-Width Discussions & Feedback”

May 1. A post with my critique of Google’s explainer and a proposal for fixing one of the accessibility issues.
“Fit-to-Width Status Update: Prototype and Issues”

October 2. A post with the status update and a list of new CSSWG issues I opened that are related to “fit to width”.

Aside from the above work, I opened a few new CSSWG issues about an array of topics.

“[css-values-5] typeof() or something similar to be used inside if() conditionals to check types of custom properties”

February 19. In some way, a follow-up to my “Pure CSS Mixin for Displaying Values of Custom Properties” article, in which I did many hacks for trying to understand the type of some custom property.
“[css-scoping] Scoping of functions, other name-defining at-rules and custom idents”

February 27. I consider global scoping of idents in CSS to be one of the last issues that require external tooling. While this issue started from an attempt to use @scope for this, a more likely direction would be to use a dedicated lexical scoping at-rule, maybe even reuse the @namespace.
“[css-contain-3] Container Variables”

August 13. We have an ability to name containers with the container-name property. We have an ability to query custom properties from such named containers. But what if we had an ability to use the values of such custom properties directly with something like container-var()?
“[css-mixins-1] Expose environmental variables inside apply’s contents block”

August 20. There is currently a lot of work dedicated to native CSS mixins. This issue is about one of their aspects for usage, with passing rules inside mixins when calling them.
“[css-inline-3] A property to exclude an element from the baseline calculation”

November 7. There are currently only indirect ways of adjusting the baseline participation of some element. As a part of writing my “Fixing Baselines” post, I opened this issue with a proposal to add a built-in way of handling this.

Aside from these, I participated in some other issues and discussions, and some of my older issues were resolved in CSSWG meetings.

My Browser Bug Reports

With this year not being as productive, there were not as many opportunities to stumble upon bugs. And, in the same way I had fewer spoons for actual experiments, I was unable to find them to report the issues I encountered.

That said, a fun fact: with fifteen bugs reported, they were distributed equally among all browser engines.

[email protected]%20created:2025-01-01..2025-12-31">5 Chrome bugs ([email protected]%20created:2024-01-01..2024-12-31">13 in 2024)
5 Firefox bugs (8 in 2024)
5 Safari bugs (6 in 2024)

Plans for 2026

Since November, I am actively working on a new proper article for my website. It takes a while, mostly due to the necessity to come up with good examples, but I hope the result will be worth it.

I also have material for another big article, though it will likely need a bit more research.

It becomes harder and harder to find “unsolvable” problems and hack the solutions to them, but hey, you never know what you will stumble upon.

Let me know what you think about this on Mastodon!

Fixing Obsidian’s Markdown Display with CSS

Sun, 16 Jul 2023 00:00:00 GMT

Current music:: The Album Leaf — Pinky’s Storage
Current drink:: Sencha tea

Introduction

In my previous blog post — “Apps with Presence on Mastodon” — I did write about what ended up being the decisive feature leading to me starting to use Obsidian:

I knew that it was possible to create plugins for Obsidian, but only now has it clicked for me that it is based on the web platform: plugins can be written with JS and everything can be styled with CSS, with CSS snippets being a thing that people actively share.

In this post, I will describe how I managed to already start using this to fix the first problem I encountered.

The Problem

The default Obsidian’s display mode is implemented in a way that hides the Markdown syntax unless you’re editing the corresponding lines.

Component is not available in RSS, visit the the site to access it.

In the video above, we can see how when we move the caret in this mode, things jump, like em becoming _em_ when we focus on it. And the source code for the images or other embeds makes things jump vertically.

Personally, I find this to be a poor experience, with this jumping getting in my way. Additionally, it can be very hard to edit the links, as the only clickable part of them is the actual link. If I used the “Source Mode” this won’t be a problem, but I like the expanded embeds, so I went to see if I could make things better.

The Solution

I did not find any community plugins or pre-made CSS snippets that would fix this (let me know if there is something like this already!), so I decided to throw some CSS at the problem.

Obsidian’s ability to add CSS overrides is the feature that sold me on it, so it is time for me to start using it. With Obsidian being an electron app, it is very easy to develop for it: I just pressed CMD+Shift+I and got to the Chromium DevTools. Then, in the options, at the bottom of the “Appearance” tab, there is a “CSS Snippets” field, which allows us to add any CSS overrides there.

Here is how it looks with my CSS snippet being applied:

Component is not available in RSS, visit the the site to access it.

I did end up leaving the full URL of a link hidden, resulting in a jump, but at least now, only the later part of it is changing, with the start part of the link code always being there.

There are other benefits that I found due to this change:

I can now easily edit the links by clicking on their code part; a click on it goes into editing them instead of going through the link. Very handy!
It is now easier to distinguish between external and internal links; internal ones would get wrapped with [[]], and there could be other cases where the more explicit, visible Markdown code would help.

Here is the code that I ended up writing (for now):

:root {
  --_fmd-opacity: 0.2;
}

.cm-link,
.cm-hmd-internal-link,
.cm-em,
.cm-strong,
.cm-inline-code,
.cm-header {
  &:not(.cm-formatting, &.cm-formatting + &) {
    &::before {
      content:
        var(--_fmd-before, var(--_fmd-pseudo));
      opacity: var(--_fmd-opacity);
    }
    &::after {
      content: var(--_fmd-after, var(--_fmd-pseudo));
      opacity: var(--_fmd-opacity);
    }
  }
}

.cm-header-1    { --_fmd-before: "# "      }
.cm-header-2    { --_fmd-before: "## "     }
.cm-header-3    { --_fmd-before: "### "    }
.cm-header-4    { --_fmd-before: "#### "   }
.cm-header-5    { --_fmd-before: "##### "  }
.cm-header-6    { --_fmd-before: "###### " }
.cm-em          { --_fmd-pseudo: "_"       }
.cm-strong      { --_fmd-pseudo: "**"      }
.cm-inline-code { --_fmd-pseudo: "`"       }

.cm-link {
  --_fmd-before: "[";
  --_fmd-after: "](…)";
}

.cm-hmd-internal-link {
  &:not(
    .cm-hmd-embed,
    .cm-link-alias-pipe,
    .cm-link-alias-pipe + &,
    .cm-formatting-link + &
  ) {
    --_fmd-before: "[[";
    --_fmd-after: "]]";
  }
}

.internal-embed {
  &:not(
    .cm-line:has(.cm-hmd-internal-link) + &,
    .cm-formatting-link-end + * + &
  )::before {
    content: "![[" attr(src) "]]";
    opacity: var(--_fmd-opacity);

  }
  .cm-line + &::before {
    display: block;
  }
}

I probably have not covered all the cases yet. I’ll try to update this when I encounter other places that would require fixing, but I’m pretty happy with how it works.

How It Works

A few notes on that CSS I did write:

Because Obsidian is using Chromium v112 at the moment, it comes with support for native CSS nesting, allowing me to just go and use it.

As I’m writing this CSS only for Obsidian, I don’t need to care about cross-browser compatibility: Obsidian can use anything present from Chrome v112 at the moment.
As I’m writing this CSS only for Obsidian, I don’t need to care about cross-browser compatibility. In one place, I used :has(), which is not yet available in Firefox.

I expect Obsidian to be a very nice practical playground for some of my wild CSS experiments (though I’ll need to wait until the newer features like scroll-driven animations and anchor positioning first land in Chrome, and then that version will land in Obsidian).
I’m using CSS custom properties to make the code leaner: defining them for all elements I would style at once and then assigning the variables I need for the specific elements. This allows me to not duplicate the complicated selector for each of the elements.

Important note: this relies on the way Obsidian renders Markdown, and the actual selector after expanding the nesting is not ideal in a lot of senses — I would not use it in a production site, but it works perfectly fine. For now.
Some features require a bit more complicated code, like the embeds, but otherwise, most of the things are handled similarly: we just “restore” the Markdown syntax by placing the ::before and ::after pseudo-elements in the correct places at the right conditions.

Limitations

Sadly, with the way Markdown is rendered in Obsidian, some cases are not covered by my CSS snippet. Simple example:

**_em inside bold_**
_**bold inside em**_

In Obsidian, right now, the above Markdown renders into the same HTML, with the only difference being the text content inside:

<span class="cm-em cm-strong">…</span>

It is not possible to tell how this HTML was written in Markdown. Things are even worse in cases where some parts of a text are only inside the topmost tag and some are not.

For example, the following Markdown:

**strong _em `with code` inside_ strong**

Would display as this:

**strong ****em** `with code` ** inside**** strong**

All of this is because Obsidian unwraps all elements one after another, making it impossible to tell if some inline element is nested into another.

While it is not possible to fix with CSS, I wonder if it is possible to somehow hook up into the way Obsidian renders Markdown from its plugins API with JS, in which case it could be possible to just output the actual symbols right away, maybe even without touching CSS (or, as I did it with my snippet, fade these symbols, making them less noisy).

Conclusion

This CSS snippet, while not ideal, was very quick to write, and I’m much happier now while editing Markdown in Obsidian.

If I find time, I’ll try to investigate its plugin API to see if this problem could be solved from a different angle, but in the meantime, if you also struggle with this default Obsidian behavior, feel free to copy this CSS snippet!

Let me know what you think about this on Mastodon!

Never Use “Scroll” Value for Overflow

Fri, 10 Nov 2023 00:00:00 GMT

Current drink:: Camomile tea

This post is prompted by the website for the new “monaspace” family of fonts (it was fixed since I started to write my article — nice!)

The Problem

The problem there is the scroll value for any of the overflow properties. Don’t use it.

What you want to use instead in 99.9% of cases is the auto value.

Here is a screenshot of the issues from the “monaspace” website:

“A screenshot of the stylistic set lists from the Monaspace website” (image is not available in RSS, visit the the site to access it.)

In the above screenshot, there are only two blocks with actual scrollbars: on the bottom right, but every other similar element that does not have enough content for an overflow to happen still has a rectangle in the scrollbar’s place.

This is because the developers did use the scroll value, and did not test with the “Show scroll bars: Always” preference.

Here it is in the macOS “Appearance” System Settings tab:

“A screenshot of one “Show scroll bars” settings in macOS” (image is not available in RSS, visit the the site to access it.)

The default value for macOS there is “Automatically based on mouse or trackpad”, making most of the scrollbars everywhere to have the “overlay” styles.

Changing this setting to “Always” makes it easy to spot this mistake. Highly recommend.

The Solution

Just use the auto value.

But What If…

Do you need to reserve some space for the scrollbar? Ok, maybe then you’re excempt from this rule! As with anything, if you know absolutely what you’re doing — go for it.

Though, in the future, I would recommend using the scrollbar-gutter property with the stable value instead. Or, if you, for some reason, don’t need Safari support, you can go ahead and use it now.

Prevention

I did add this as a Stylelint rule to our codebase.

The rule I did chose for this is declaration-property-value-disallowed-list:

{
	rules: {
		'declaration-property-value-disallowed-list': [
			{
				'/^overflow(-(x|y|inline|block))?$/i':
					/\bscroll\b/i,
			}
		]
	}
}

That’s it! If you’re using Stylelint — I recommend adding this rule yourself. If you’re not — I’ll strongly recommend starting using it, especially if you’re working in a team.

Let me know what you think about this on Mastodon!

Updated Scroll Markers in the Table of Contents

Sun, 10 Nov 2024 00:00:00 GMT

Current music:: Haru Nemuri — Shunka Ryougen - Audiotree Live Version
Current drink:: Peppermint Tea

Quick Update

I’ve spent most of the day inside the delayed and cancelled trains (thanks, Deutsche Bahn). I did not have an opportunity to come up with a good post for today, but both yesterday (and a bit today) I hacked on this blog, as a part of the IndieWebCamp.

I did the thing I wanted to do during this weekend: update my blog’s Table of Contents to be similar to what I have on my main site. Actually, it was already working like that, but only in Chrome.

What I Had

What I am talking about: the small finger marker that appears in the Table of Contents, pointing to the current section:

Component is not available in RSS, visit the the site to access it.

Before this update, it worked only in Chrome: I was using a heavily modified variation of my scroll-driven animations experiment for scroll markers.

The Update

Now — it is all the same, but also works in Firefox and Safari!

All thanks to some JS, delivered via a custom element. This is something I briefly mentioned in my CSS Day talk: instead of trying to cover the whole technology, like scroll-driven animations, with a polyfill, we can only ponyfill a single technique with a custom element and implement only the missing parts.

This is what I did: the technique requires scroll-driven animations, particularly, timeline-scope, which Firefox Nightly does not yet support in its outdated experimental implementation of them.

I used an intersection observer and a window resize event to implement what is missing, while keeping most of the styles intact.

I won’t go into the details of the implementation today. Maybe the code behind it could be polished and published as a package? Maybe, one day. Maybe, not. Let me know.

If you’re interested at peeking at the source code of this (far from polished, but at least with some comments), here it is:

The Specs

Interestingly, Robert Flack opened a CSSWG issue about scroll-markers as a part of the work they did alongside Miriam Suzanne and Nicole Sullivan on the “carousels” — “CSS Overflow - Broad Research”.

With it, things like that will become trivial, and I cannot wait for it to be specified and in the browsers.

Let me know what you think about this on Mastodon!

My 2024 in CSS

Tue, 31 Dec 2024 00:00:00 GMT

Current music:: MASS OF THE FERMENTING DREGS — Aoi, Koi, Daidaiiro No Hi
Current drink:: Sencha tea

Intro

This was another productive year for me. After 2023, when I explored anchor positioning, scroll-driven animations, and came up with “Cyclic Dependency Space Toggles”, I was afraid that I couldn’t get anywhere close. After all, innovation is hard, and you never know if you will stumble over something exciting.

Looking back at 2024, I can safely say that I managed to continue doing what I was doing. And, as it will be obvious from the next sections, there were things that would be difficult to top.

Joining the CSS Working Group

For someone who built their entire career by focusing on CSS, getting an email titled “Would you like to be a CSS WG Invited Expert?” at the beginning of February was surreal, and equally gratifying.

Obviously, I accepted. A bit later, in June, the company I am working in — Datadog — joined W3C, so now I’m a regular member of CSS Working Group.

I try to participate in every meeting I can, although I am not sure if I manage to contribute much. Being among people who write CSS specs and implement them in browsers is a good opportunity to keep the impostor syndrome that I had my whole life going strong.

“A photo showing a group of people walking from left to right on a hill overlooking a city on a peninsula, with blue water, rolling green hills and slightly cloudy sky.” (image is not available in RSS, visit the the site to access it.)

In June, I traveled to A Coruña for a few days of face-to-face meetings and met many people I previously only talked to or followed virtually. I still need to publish the photos that I took there, oops.

Speaking at CSS Day 2024

Another thing that happened at the beginning of 2024 was getting an invitation to speak at CSS Day conference, and then speaking at it in June.

I’ve yet to watch my talk, but I am planning to eventually do it, as I want to do a text version of it. I have no idea how it went other than that I almost fell from the stage, haha.

All other talks from this conference, were, as usual, great — I can highly recommend you to watch them!

My Articles and Techniques

While 2023 was for me mostly a year of playing with experimental features, I spent most of 2024 thinking about custom properties, ways we can do APIs with them, and many related topics like conditional CSS and mixins. Most of it stemmed from my “Cyclic Dependency Space Toggles” from 2023: both the first and the last articles I published are a continuation of them.

“Layered Toggles: Optional CSS Mixins”

April 9. Probably the weakest article from this year, but about an important topic — I published it as soon as I discovered the technique. While the usage of revert-layer for optional styles was not new, using it in combination with space and cyclic toggles is a much more powerful concept, which I will depend on in the future.
“Alternating Style Queries”

April 16. An article about a simple but powerful trick with style container queries. Once they become available in all browsers (Firefox, I’m looking at you), I expect this technique to be very common. Initially, it was meant to be a part of the next article I published, but I saw how it is more important to separate it from the more gimmicky and complicated parts.
“Self-Modifying Variables: the inherit() Workaround”

April 18. The article that flew under the radar the most, even though the effect it talks about is very useful and powerful and is not possible to achieve in any other way. Looking at how we can work around the things that will eventually be in CSS was a theme for me this year, and the inherit () function is something I wish browsers started to prototype. The workaround based on alternating style queries from the previous article is tricky, but once we have style container queries, I expect it to be an important and invaluable tool.
“Fit-to-Width Text: A New Technique”

July 19. The most popular article from any that I ever published. The solution for fit-to-width text was something of a holy grail in CSS, and I still can’t believe I found a key to it — and that it is fully cross-browser. It is imperfect as it requires duplication of content, but I don’t think we will come anywhere closer with pure CSS. Let’s hope this will one day be possible with native CSS!
“Possible Future CSS: Tree-Counting Functions and Random Values”

October 22. The article that took the longest to finish. But it also has the best interactive examples! It does not really introduce new techniques, but it combines many concepts that I did not see used together before. I can’t wait for the native CSS in question to be available, but, for now, I am planning to use the workarounds described in this article in my other experiments.
“Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins”

December 24. The article is about a technique that is a culmination of many different things. In some way, it was another holy grail that I pursued for a long time, and I’m thrilled that I managed to get to the solution. Yes, we will eventually have native conditions, functions, and mixins, but what I unveiled in this article will allow us to close the gap and experiment with these concepts today. And, hopefully, it could also push browsers to start prototyping sooner rather than later.

Some of My Blog Posts

While I did manage to write a blog post every day for the whole of November again, I did not manage to do it consistently in other months. At some point, I got overwhelmed with the bookmarks backlog and will need to work on some kind of solution (I still want to share them more often — and first read them, as I never share things that I did not read).

I did also post a few noteworthy CSS-related posts here. Some of them were almost good enough to be articles on the main site, but I explicitly wanted them to be a bit less polished. I wanted to work on my blog’s engine (mostly Astro), so I needed to have some posts with live code examples.

Here are the posts that, if you missed, I recommend to check out:

“Cap-Height Vertical Align”

January 3. That was a nice post to start the year from. A rather simple technique, but also something that I wanted to write for a while.
“Querying the Color Scheme”

August 29. A fun, but not very practical trick. Requires style container queries — another sign we need them as soon as possible.
“Captured Custom Properties”

September 2. A post about a pattern that I use more often for my registered custom properties.
“Observation: Forced Wrapping”

November 5. A short post about one rare use case for flex-basis. I want to publish posts like these more: there are many neat interactions that can happen with various CSS properties.
“A good way to hide non-defined custom elements”

November 14. While I do not yet use custom elements a lot, this was one of the first things I tried when seeing the issues of other similar implementations.
“Observation: Sticky Anchor Navigation”

November 25. A few test cases and a workaround for one weird issue with anchored navigation. This is a topic that I hope to delve more into, as there are numerous interoperability issues related to it.
“Observation: CSS Math Eval” and “CSS Math Eval, now Better and Weirder”

November 28 and November 29. Posts looking at how we can use the powers of CSS calculations to safely evaluate user input with everything that is available inside calc().
“Splash Colour Mixin”

December 26. One of the first native mixin prototypes I did after publishing “Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins”. More to come!

My Browser Bug Reports

Almost every time I work on an article or post, I encounter some bugs. I am not always diligent in reporting them, but I try to do it when I have the spoons for this. This year, I matched the number of bugs I reported in 2023: a total of 27 across all browsers then and now.

[email protected]%20created:2024-01-01..2024-12-31">13 Chrome bugs ([email protected]%20created:2023-01-01..2023-12-31">16 in 2023)
8 Firefox bugs (6 in 2023)
6 Safari bugs (5 in 2023)

I think I have a few unreported bugs here and there in my notes and drafts; I’ll try to be even more diligent in 2025.

Plans for 2025

Speaking of notes and drafts. While I don’t have any specific plans for the next year, what I have is a pile of drafts and experiments on various stages.

While there is nothing groundbreaking among them, there are some things that I find curious enough to be content with what I could publish in 2025. I do not intend — and can’t imagine — topping this past year. After all, you can’t force discoveries — only work towards them.

Let me know what you think about this on Mastodon!

I Added Lightning CSS to This Blog

Fri, 15 Nov 2024 00:00:00 GMT

Current music:: Daughter — Still
Current drink:: Camomile & Lavender tea

The Problem

After I published my “My Mastodon Starter Pack” post, it got boosted a bunch in Mastodon. This led to more people trying to read it, and some — not successfully.

All because in this not very polished blog I used a lot of a bit too-modern CSS, for example, native CSS nesting. And — this resulted in the layout breaking quite substantially:

“An “above the fold” screenshot of the “My Mastodon Starter Pack” article, showing the broken and mostly unreadable layout. The elements in the screenshot go into incorrect places in the grid.” (image is not available in RSS, visit the the site to access it.)

Yeah. This is what happens when non-frontend people arrive at your experimental site!

Well, I guess it is time to fix it!

Lightning CSS

First thing I did is I added Lightning CSS to my blog (following these instructions in Astro docs), so now its styles go through it. With the default settings, it does some transpilation, including unwrapping native CSS nesting, the absence of which led to most of the problems.

After first adding it, I noticed that I don’t want to have all the transpilation that it gives me: I’d better be a control freak in this case, and only add transpilation of native nesting, without, for example, transpiling :is() to :-webkit-any() and :-moz-any(). Here is the full part related to Lightning CSS in my astro.config.mjx:

import { Features } from 'lightningcss';
// …
export default defineConfig({
	// …
	vite: {
		css: {
			transformer: "lightningcss",
			lightningcss: {
				targets: {},
				include: Features.Nesting,
			},
		},
	},
});

I already manually add fallbacks for non-oklch colors, and the rest seem to degrade much more gracefully, so, at least for now, this minimal config is all I need.

Fixing Calculated Responsiveness

After testing how things look in Firefox 115, I still found that I need to adjust my responsive side notes and table of contents.

I’m using a bit too complex math for them, which involves many moving parts like round() and @property (for “Captured Custom Properties”).

I added one @supports (targeting round() support) that sets some binary flags that I’m using for calculations to put these elements always inside the content area:

```css
@supports not (width: round(1px, 1px)) {
	--has-no-aside: 1;
	--has-aside: 0;
	--has-no-toc: 1;
	--has-toc: 0;
}
```

That’s it. There are probably still places that could be improved, with better fallbacks, but this should be good enough for now.

Appreciating Feedback

I noticed that people are often reporting typos in my posts, and other issues — like this one.

Multiple people did let me know about it:

Thank you!

I always appreciate any feedback and bug reports, so, please, continue sending them my way. Some things could take a bit longer to fix, but, as you can see, repeated reports make it easier to prioritize more important fixes!

Do not be afraid to report something that you think is obvious or could’ve been reported before. Even if it was — you’ll give an additional signal that other people care, and that more people are affected. And if not, you could be the one reporting an awkward bug or typo that I missed.

Let me know what you think about this on Mastodon!

Box-Decoration-Break

Thu, 06 Nov 2025 00:00:00 GMT

Current music:: 2:54 — Dawn
Current drink:: Green tea with bergamot, kiwi, yellow peach, orange blossom and violet flower

In the last few days, coincidentally, I saw two cases where the obscure box-decoration-break property CSS could help.

This might be a good sign that it is worth it to remind everyone about its existence!

One reason why, I think, this property is not yet well-known is that it is not “baseline”. Its standard version is implemented in Firefox and Chrome, but Safari is still using the older prefixed -webkit-box-decoration-break version.

There is a pull request to WebKit from Karl Dubost about unprefixing it, although it is a bit stale: the last time it was updated was a year ago. Hopefully, one day it will be finished!

I won’t go into details about what box-decoration-break does, as I will link to many different articles and resources about it.

Quick Resources

If you are keen to learn about the property itself before continuing, read one of these:

“CSS box-decoration-break” — an introductory article by Kilian Valkhof from last year’s “12 Days of Web” curated by Stephanie Eckles.
An MDN reference for box-decoration-break.
The current draft of CSSWG specification about it.

But let’s look at what were the questions that brought me to this topic.

Multi-line Padded Text

First case was a question from Jonathan Schofield about a certain cross-browser issue with some text effect. While it could be interesting to investigate the actual interop issue, I noticed that the author was likely pursuing a very specific decorative style, which would be achieved much easier with box-decoration-break.

I took the name for this section from an eleven-years-old “Multi-Line Padded Text” article by Chris Coyier. Alongside this property that was “new” at the time, Chris presented a few workarounds that worked then. Can’t wait until this property will become “newly available”.

A newer article that involved box-decoration-break for a similar, although much more elaborated effect, was “A Deep Dive into the Inline Background Overlap Problem” by Ana Tudor from this March. Which, of course, involves some SVG filters magic. Just know that the further you’ll go into the article, the more you’ll start to see the matrix, and the slower your browser will render the page. Sadly, browsers neglected SVG for a long time, including working on its performance.

Pseudo-Random SVG Underlines

Second example is something that I forgot to use when I was working on my last long-form article “Passing Data into SVG: Linked Parameters Workaround” (if you did not read it fully — I highly recommend, it contains many fun details).

That article was, in part, thanks to Ivan Reese, and after some research I proposed to use the method that I later explained in my article instead of the work-in-progress solution that he was working on.

The solution was for a tiny decorative detail of the Ink & Switch’s website — pseudo-randomized underlines for links.

Recenly, I saw one of their projects — Automerge — mentioned on Mastodon by https://piccalil.li/, which reminded if Ivan ended up using my weird SVG solution for the underlines’ implementation on Ink & Switch’s website.

It was, with a proper credit inside the SVG file used for the undelines!

It is fun to see your highly experimental technique used in practice.

When looking at the links on the page, especially on the bottom of its page, I noticed something: while in general links looked nice, when they were wrapping, they had a “hard cut” on the edges:

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/box-decoration-break/)

Links wrap not nicely.

When I saw this, I remembered that we have box-decoration-break: clone, and immediately tried it in the dev tools:

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/box-decoration-break/)

Links wrap nicely.

It works! Browsers create separate fragments for each part of the wrapped links, and apply the SVG for each of them.

One other difference that we can notice: the wrapping of the last part changed — and this happened only in Firefox. Probably something to report!

Conclusion

I hope box-decoration-break will become standard sooner rather than later. There are some very fun use cases for it that I did omit in this post: maybe one day I’ll write about them as well.

This property was proposed to be included in the last year’s Interop initiative by Jason Kuhn, but not included there.

Please — play with it, see if you could use it to enhance your designs, and let browsers know that you want it to be baseline.

Let me know what you think about this on Mastodon!

Fit-to-Width Discussions & Feedback

Thu, 01 May 2025 00:00:00 GMT

Current music:: Tom Figgins — A Leaf in the Breeze
Current drink:: Peppermint Tea

The Context

A bit less than a year ago, I published my “Fit-to-Width Text: A New Technique” article, where I presented a CSS-only way to achieve a responsive fit-to-width text. You might’ve noticed: this article’s header uses it, for example.

Since then, I thought a lot about that technique, refined it, and bumped a few times the corresponding CSSWG issue by Tobi Reif, which is now seven years old.

On April 1st, I presented this issue and my thoughts about it during a CSS Working Group’s face-to-face meeting, where we resolved to start working on it as a part of CSS Fonts Module Level 5.

Following that, two things happened: a discussion in the issue regarding potential accessibility problems of this feature, started by Patrick H. Lauke, and an Intent to Prototype for it alongside an Explainer by Kent Tamura.

I have some thoughts, feedback, and ideas about both of these, so here is a post!

Accessibility

The Problem: Dependency on Viewport

Long story short, a common problem of fit-to-width (and other responsive typography) approaches is that they can fail Success Criterion 1.4.4 Resize Text of WCAG 2.1:

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

How could this technique fail this success criterion? Let’s say we have a viewport, in which we have a fit-to-width block that stretches from one side to another:

Component is not available in RSS, visit the the site to access it.

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)Hello There!

Now, a user wants to zoom in to increase the text’s size up to 500%:

Component is not available in RSS, visit the the site to access it. Component is not available in RSS, visit the the site to access it.Hello There!

Do you see any change in the text’s size? No? The example above has width: 20%; scale: 5; added to it, essentially, replicating the effect that would be there if we were to zoom into a web page without changing the dimensions of its window.

When I measure the computed font-size of both examples, the first example has 125.45px, and the second — 25.1108px. 500% is the maximum full-page zoom I can achieve in my Firefox, and it did not change the font-size of our text at all.

Possible Arguments

While it could be argued that in some cases users could have access to an alternative way to zoom in like a pinch-to-zoom, not all users will have it, so if we were to consider only those methods available in the browsers, neither changing the default page’s font-size, nor full-page zoom allows us to bump the size of our text by 200%.

And so, it fails the success criterion. At least, literally: in some cases, like in an example above, it could be argued that the text is “big enough”. And, here is a relevant comment by Mitchell Evan from a different (but related) WCAG issue by Šime Vidas “Can large headings be exempt from Success Criterion 1.4.4 Resize text?”:

[…] I’ll add that today 150% sized heading text could meet the functional performance criteria of US Section 508 as an instance of equivalent facilitation, if it provides “substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance”. It’s a similar concept to functional needs in WCAG 3.0.

I am not a lawyer, and I don’t know if fit-to-width cases could be considered an “equivalent facilitation”. And if WCAG is referenced by legislation in other countries where they don’t have such excemption, from the potential letter of law this could still be a problem.

It is also necessary to say that the “equivalent facilitation” will only take place in certain conditions, where the text that fits the width would need to have some minimum font-size that is larger than the body copy, not overflow when zoomed, and so on.

In practice, when authors implement fit-to-width texts and other responsive typography techniques, it is possible to easily make the experience worse in certain cases.

For example, forgetting to set a minimum font-size, and then trying to fit a very long line of text in just one line could lead to the font-size being too small:

Component is not available in RSS, visit the the site to access it. Component is not available in RSS, visit the the site to access it.This a very long line of text that fits the width, but does not wrap, rendering in a tiny font-size as it does not have a lower limit.

Ah, and this is also an example that uses width: 20%; scale: 5, emulating a user trying to use full-page zoom in an attempt to make the text larger. The computed font-size here is 2.48483px on a wide screen, and 1.10771px on a screen of an iPhone mini.

My other personal pet peve is what happens when you’re not just zooming in, but zooming out — sometimes a text can be too large, and you want to shrink it to read easier… but cannot, as it continues to take all the available space regardless of the full-page zoom level.

Component is not available in RSS, visit the the site to access it. Component is not available in RSS, visit the the site to access it.CSS

This example is “zoomed out” by 50% via width: 200%; scale: 0.5, but the text continues to be very big (computed size is 779.034px for me).

Fixed Exceptions

Before talking about solutions, I want to note that this problem won’t appear always. If the fit-to-width does not have a dependency on the viewport’s width, it will follow the full-page zoom perfectly.

Component is not available in RSS, visit the the site to access it.

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)42

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)2025

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)3.1415926

Above is an example with three elements, each of which has a fixed width of 200px. If we were to zoom in, the text’s size will increase as well, as it won’t adapt to the change of the viewport.

However, this is only a subset of all possible cases which authors could have, and sometimes you could think that the element’s width is fixed, apply the technique, only to add max-width: 100% later and find the “stretched” text to be too small on a mobile viewport, where it becomes the limiting factor.

Possible Solutions

It is impossible to eliminate all the potential traps an author can fall when using new features, but we can make it harder to break things unintentionally, and build the defaults more cautiously.

If we were to implement the feature with very severe limitations, there is always a chance authors would either use something else (which could be even worse), or work around the limitations by removing them completely with various hacks. We need to find a balance where we could allow authors to express themselves, but in a way they couldn’t unknowlingly make their sites inaccessible.

I will welcome any constructive feedback: please let me know if you think the proposed solutions are enough, and if not — which limitations would you like to see instead? Is there anything I missed? Don’t hesitate to reply either on Mastodon, in the parent CSSWG issue, write a post on your platform of choice, or email me at [email protected]">[email protected].

Limiting the Size Range

My first (and main) idea for a potential solution came from reading the “Understanding Resize Text Success Criterion” document, specifically, the second note there:

[…] For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page’s text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. […]

This note describes a case where an author adjusts the font-size based on the available space, but in a way where even though they reduce it from 20px to 10px, an increase in 400% from that point will lead to the text being 200% larger than originally, thus passing the Success Criterion 1.4.4.

What if we were to limit the range in which our fit-to-width can operate?

In my initial proposal, I wanted to use the original font-size as the minimal size in which the text will be rendered during the first pass, and which then would be increased to fit the available space up to an optional maximum font-size. I contemplated having a default value there, and wondered if something like 100vb would be enough.

But what if we had the default value to be just 200%? With all modern browsers having at least 500% full-page zoom available, a range of any font from 1em to 2em should pass the Success Criterion 1.4.4 in the same way as described in the above note.

Here is an example from before, but with this limit: first without the “fit-to-width” applied, then with it, and finally, zoomed-in:

Component is not available in RSS, visit the the site to access it.

Limited

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)Limited

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)Limited

Of course, you can see that the text in the second line does not fit the full width, as it grows only to be up to 200% larger than originally, but that is what allows it to grow when we “zoom in”.

In practice, this limitation just means you need to care more about the original font-size, and make it not too small if you want your headers to be able to grow. This post’s header is using this limit, and it still looks good:

Component is not available in RSS, visit the the site to access it.

Component is not available in RSS, visit the the site to access it.Fit-to-Width Component is not available in RSS, visit the the site to access it.Discussions & Feedback

Although, I had to slightly bump the original font-size of the “Fit-to-Width” to grow further, but it was simple to do, and still allows the header to feel responsive when you resize the content area.

Relaxed or Strict

There are two versions of this proposed solution: relaxed and strict.

Relaxed: use 200% as the default “max-font-size” value for the fit-to-width feature. Omitting a value will lead to a guaranteed “passing” criterion. But it will be possible for an author to override it to a different value: smaller or larger.
Strict: have 200% as the limit of what you could have for the feature. You could set it to be lower, but not higher.

I lean towards the relaxed solution: the strict limit won’t make sense for any case where the problem is non-existent, and as I described at the beginning of the “Possible Solutions” section, in CSS it is possible to find hacky way to work around this anyways.

Having a stricter default could be a good start, additional guidance about the potential accessibility implications in the specs and on MDN could go a long way, and user agents’ developer tools could go even further and detect places where the fit-to-width value (or — any responsive typography calculations) can result in a more than 200% range and is dependent on the viewport dimensions.

There might be some in-between version of this solution as well, where we could introduce some friction for removing the 200% limit. An author that knows what they’re doing will be able to do the required simple step to remove it, but the path of the least resistance will be safer.

Finally, there might be other ways to achieve “fitting to width”, like with letter-spacing and other methods. If we will be able to define them well, a strict solution could use these methods to get the “last mile” after stopping at 200% for the font-size. But that is something that requires experimentation and prototyping, and I still tend to think that a more relaxed solution will work well enough.

Collapsing the Container

Another idea I had, but did not manage to go far with it: what if we could somehow detect that the element is in the context where it can’t adapt to the viewport — or its container’s — width? If the problematic cases only happen due to the zoom & viewport interaction, and we can’t detect the zoom level (there is an “Browser zoom unit for accessibility” issue by Scott Kellum, but I am not sure if it will be ever resolved), then can we require setting that fixed width for an element that should grow?

I tried thinking how we could approach it — using containers, maybe anonymous boxes around our text, or something else — but couldn’t find a way that wouldn’t introduce too much friction, or won’t be easy to work around by using registered custom properties, viewport units, or something similar.

However, I wanted to mention this as an idea, or a direction in which we could think. Could we have a strict max font-size by default, but somehow make it relaxed when we detect that the container has a fixed width?

Please let me know if you think this direction is worth exploring it further. Or if you have other ideas over how we can alleviate the zooming issue when we’re bounded by the viewport.

Built-in vs. Custom Solutions

I find this case to be similar to many other cases, where there is a tension between the web platform trying to improve certain use cases, when the design behind them is questionable in the first place. Exclusive accordions, carousels, screen-reader-only styles come to mind.

Today, authors implement these in hacky ways, often with heavy JS usage. Disabled scripts, a tiny mistake, or just an author oversight can render the solutions inaccessible or broken. But new sites continue to be created using these patterns regardless.

Should the Web Platform make it easier to implement such designs? Opponents note that this will make those cases even more prevalent. Proponents say that if we approach it thoughtfully, we can build these solutions accessible (as much as they can be) from the box, eliminating the common mistakes, and reducing the room for an author error.

I don’t have a definitive answer to this, but I believe that together we can strive to make things better and improve the Web.

Explainer

Now, to the second part of this post: my feedback for Google’s “CSS fit-width text Explainer”.

In general, it is great that Google wants to prototype fit-to-width feature! Having it available in Canary could allow us to test our assumptions and explore possible fixes to the accessibility problems the feature could have. Of course, we should keep it as a prototype until we will come to an acceptable solution for those, and I am strongly against shipping anything without doing so.

The explainer proposes to have two ways of defining the “fit-to-width” behavior as two new CSS properties: text-grow and text-shrink.

My opinion: at least initially, we should have only the text-grow behavior, and I am not sure if we need the text-shrink at all. I want to focus my feedback on this part first, and then I’ll provide some of my thoughts regarding other open questions from the explainer.

Problems of `text-shrink`

While it might seem that there is not a big difference in which way we approach “fit to width” — first rendering the text as small, and then growing it to fit, or first rendering the text as large, and then collapsing it to fit — in practice, there are many ways in which the “shrinking” behavior can be more awkward and less accessible.

I argue that we can do everything text-shrink can do with text-grow, and having both can be problematic.

Worse Fallbacks and Responsive Behavior

Today, many workarounds for fit-to-width tend to start from a larger font-size, shrinking it until it fits. If someone tried to reproduce the same behavior with text-shrink by wanting to have a single-line header that fits into the width, they will likely set white-space: nowrap and a large enough font-size, and then add text-shrink.

This will work, but it creates many problems:

In browsers that do not support text-shrink, the text will overflow beyond its container. More often than not, authors will forget to wrap the white-space in an @supports.
Similarly, if we’d like to enable/disable this behavior dynamically, instead of toggling a single property, you’ll need to remember to toggle white-space as well.

With text-grow, we start from the small font-size, and then make it grow as a progressive enhancement. We don’t need white-space: nowrap, as we design for the initial state first.

Harder to Set a Limit

If we decide to go with having a 200% limit of how much our text’s size can change, things become very awkward if we have both text-shrink and text-grow, and allow using them at the same time.

Do we make the limit for either smaller, so we will still have a 200% range from the smallest size to the largest when both are present? Do we add some magic that chooses this limit based on the presence of other property?

I don’t think there is a good way to go about it. We either limit the most common cases, or introduce a hard-to-understand behavior.

Opaque Edge Cases

If we design for the larger font-size to be shrunk, we will likely only test the cases that have a non-modified font-size, but will rarely check what happens when it reaches the available range.

This can lead to a tiny font-size, or — if we use the white-space: nowrap — content overflowing by reaching the minimum font-size, and not being able to shrink further.

If we involve adjusting other properties alongside or instead of font-size like letter-spacing, negative values of it can result in a completely unreadable text:

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/)

Illustration from the [“Combining behaviors” section of the Explainer](https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md#combining-behaviors)

If we implement text-shrinking for something like a pill element, where the count inside fits its width, it is easy to make the font end up being too small to read.

Generally, treating text-grow as a progressive enhancement allows us to design from the extreme case, and allow the browser improve the display of the text.

Other Syntax Feedback

Aside from text-shrink, there are two things that, I feel, need to be talked about.

Limit Value

The explainer proposes to use a <length> for setting the max value of the font, and it mentions values like 30px and 8px. Setting the font-size in pixels is a common mispractice, and maybe this is a place where we could try not to introduce another potential point of failure for authors. I see two ways to handle this:

Allow only <number>|<percentage> values, with a 200% by default. If the limit will be strict, it will allow a range of values either from 1 to 2, or from 100% to 200%.
Allow setting a <length> as well, but convert it into a value based on rem automatically. This can be conroversial, as I don’t think we have a precedent for this in CSS yet, but maybe it is worth introducing a mechanism like this?

And, a final option will be to disallow changing the limit at all. Are there actual cases where you’d want to limit upper value to be less than 200%? If a strict limit will be enough, then why not simplify the property by removing the ability to override it at all.

Syntax of `<fit-method>`

The explainer proposes to have the following values: scale, scale-inline, font-size, and letter-spacing.

I am not certain there is any benefit from having a scale/font-size separation: for most fonts there is no effective difference aside from maybe hinting, and for fonts with an optical variable axis you’d likely never want to use scale.

Having scale-inline is interesting, although at least in western typography non-proportional scaling of glyphs is rarely considered to be good. I can see how it can be sometimes better than changing font-size, but it might also be too easy to shrink the glyph too much.

The letter-spacing seems obvious, but I wonder if we also want to have some kind of limitation to how much it can grow: imagine having a two- or three-letter word that stretches using letter-spacing. We’d need to be able to control how much it will stretch, and have some built-in limit as well.

Finally, I saw many authors mention that they’d want to be able to apply both font-size scaling and letter-spacing, and maybe even some other approaches like changing the font’s width optical axis, or something else. In this case, we’d want to be able to mix these, potentially providing a % of each, or defining a sequence in which they should be used (like first only scaling via font-size, and when the limit is reached use letter-spacing).

Handling multiple methods and mixing them is something I want to experiment with, and maybe we could start with a simplistic syntax, but we need to accomodate its future expansion to be more complicated.

Thoughts on Open Questions

There are a few items and open questions in the “Detailed design discussion” section of the Explainer that I’d like to give my thoughts about.

Scalable or Static Elements

Items contained in a line box are classified as either “scalable” or “static”, and only “scalable” items are affected by this feature.

I am not sure if it is useful to categorize elements inside a line box. Mostly, because later there is a question:

What about padding/border/margin of inline boxes?

And I strongly think that almost anything that depends on the current font-size should scale accordingly (anything with values in em, ch, cap, etc), and anything that does not (px, rem, etc.) should not.

In my proposal, I suggest having an additional render step that allows us to determine the static contribution of any static parts, including paddings, margins, or more complex calculations.

Should we assume text with a fixed font-size as “static”?

Yes, if a nested element has a font-size defined in px or rem, it should not grow proportionally to the parent’s font-size.

Replaced elements such as <img> and <input> are static.

Atomic inlines are static

As I mentioned before, I don’t think we should think about specific elements as being static, but rather determine how much they contribute statically, and how much they contribute when depending on the font-size. An image icon that is sized in em should grow with text, an input could also inherit the parent’s font-size, and thus grow with its font-size as well.

This also answers a later question about <length>:

How does this interact with properties with <length>.

Should the length be scaled or not? Depends on its units (px, em, rem, %, vw, vh, etc.)?

`scale` vs `font-size`

The methods vaues scale and font-size that can be specified for <fit-method> can produce similar visual results. Through prototype implementation and discussion, we aim to decide whether to standardize both or remove one of them.

scale linearly scales up the glyph data obtained at the original font size for rendering. Consequently, the displayed glyph might differ from the ideal glyph intended for that size. However, since the glyph data retrieval process only happens once, it operates significantly faster.

font-size renders the ideal glyph for the displayed size. This process can be considerably slower because it necessitates trying out glyphs of various sizes.

I mentioned this in the “Syntax of <fit-method>” section. In short, I think we don’t need the scale, as it won’t be a correct representation of the change in font-size, and I can see how the above thoughts about separating elements into static and scalable could make sense if we will do the “scale” method, but I consider this method to not be good enough.

Best-fit `font-size` Algorithm

How to find the best-fit font-size? There are cases where the line width becomes smaller even if the font-size is increased.

The algorithm that I am using in my workaround could be a good starting point. For edge cases like calc(20px - 1em), there are two things we could do:

Only use the initial font-size for such calculations, so the 1em there won’t inherit the changed value.
Or, we could check if our new value that attempts to increase the length of a line results in a shorter line, and keep the original value instead.

Such edge cases are rare, and we should strive to solve the most common cases, and have an accessible fallback for those outside of them.

Other Variable Axis

font-weight or font-width for <fit-method>? They work well only with specific fonts, and they don’t offer the flexibility to fit text to any width. So we don’t apply them in the initial proposal.

I agree that we could postpone this part, but we need to design the syntax in a way where it could be easily expanded to support those.

I have some ideas about how we could do it. One is to treat each additional axis as linear by default, taking the dimensions of the min and max versions, and interpolating between them. Of course, a font could have a non-linear interpolation for any of the axises, in which case we could allow defining a custom easing as well, but for most cases, like with the width axis, having a linear interpolation by default should be good enough.

Mentions of Accessibility

Accessibility If an end-user tries to enlarge font size, UAs should not fit enlarged lines to the container width. Is minimum-font setting enough?

The user’s minimum font size preference should be respected.

These are the only mentions of accessibility, and I don’t think it is possible for the UA to “not fit enlarged lines to the container width”, as this means the UA will treat full-page zoom differently than just a narrow layout, which might be problematic.

I do not remember if we have a notion of a global “minimum font-size” in CSS, but if we have, and regardless of this, we for sure need to consider it. However, I imagine that we only would need to consider it when talking about text-shrink, while if we were to only implement text-grow, it won’t apply (as it will be just its interaction with regular font-size).

Otherwise, I would like the explainer to dive into accessibility deeper, and consider my thoughts from the first part of this post.

Handling of last lines

How to handle last lines if text-grow:per-line is specified. Should we widen them even if auto-wrapped?

A good question! Without a limit, a single short word in the end could get too large. However, if we introduce the limit, I don’t think this becomes a big issue?

Floats and Initial Letters

Line’s available width can depend on its block offset. e.g. float and initial-letter.

I think the float case is more simple: we could exclude it from any scaling (so not change the font-size inside of it), and first lay out the float, then determine the line boxes and only then do the scaling.

The initial-letter is more complex, as it behaves interestingly when it stretches multiple lines, as its size starts to depend on the line-height. If the line-height is only dependent on the font-size, then it is simple enough case, as we can treat the initial-letter’s contribution to each line as scaling accordingly, but when it is static or mixed, then the dependence is not linear, and we’ll need to define how things should work then.

Further Recommended Actions

It is great that there is this explainer, as it allows us to start a dialogue and discuss the direction in which we want to go with this feature. If I were to give some advice to Google’s engineers implementing a prototype, here is what I would suggest:

Implement a soft 200% max-font-size limit. Having it in a prototype as a soft limit will allow us to test how things behave without it, and also test what happens if we increase it, and if we ever need to do so. We could always make it strict, or remove an ability to override it altogether later.
Focus only on text-grow for the start, see the reasons why above.
Focus on trying to do the proper font-size scaling while taking the potential optical sizing axis in consideration as I explained in my original proposal. If the regular scaling is simple, it will be better to try and do the hard part first — we should not discard it without trying. But, in my opinion, even if just scaling in simpler, it will not be enough, and for many typographic designs we’ll have to rely on existings workarounds instead of using the new feature. And, because of the ways different algorithms treat static/scaling contributions, I doubt it will be good to allow them both.

Invitation to Participate

That’s it for now!

Fit-to-width is a hard problem, but it is worth solving. I invite all designers, typography enthusiasts, and accessibility practioners to participate in doing so, and finding a way forward that won’t make things worse.

Let me know what you think about this on Mastodon!

Border: 2px double

Wed, 26 Nov 2025 00:00:00 GMT

Current music:: toe — all i understand is that i don’t understand
Current drink:: Lemongrass, Ginger & Black Pepper tea

I wanted to write a different post today, but did not have time to finish it, oops.

So let me tell you one pretty useless but fun CSS fact.

Look at this:

Component is not available in RSS, visit the the site to access it.

<div class="square"></div>

.square {
	width: 1em;
	aspect-ratio: 1;
	border: 2px double;
}

On screens with good old 1x resolution this will render with a solid 2px border.

But on systems with retina screens (or similar), this renders in a fully non-interop way:

[Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/border-2px-double/) [Component is not available in RSS, visit the the site to access it.](https://blog.kizu.dev/border-2px-double/)

Chrome

Firefox

Safari

Interestingly, there is no guidance (as far as I know) about this in the specs. They only say for double:

Two parallel solid lines with some space between them. (The thickness of the lines is not specified, but the sum of the lines and the space must equal border-width.)

And browsers are free to interpret this as they wish.

Curiously, both Firefox and Chrome also do 1.5px double correctly, in which case it will be two 0.5px-wide borders with 0.5px space between, while 2px results in whole 1px-wide space between those two 0.5px borders.

If only Safari did follow suit… But hey, I mentioned that this is mostly useless fact. But I hope it was at least a bit fun!

Let me know what you think about this on Mastodon!

Roma’s Unpolished Posts

Apps with Presence on Mastodon

Table of Contents

Introduction

Things I Did Choose This Way

Things I Used Before

Scroll-Driven Animations in Stable Chrome

Not an Ideal Start

Table of Contents

Introduction

The Stack

Everything Else — From Scratch

Bumps on the Road

CSS Snapshot

Astro MDX Components

Table of Contents

Introduction

Providing MDX Components by Default

Accessing the Slots Content

That’s It

Weekly Bookmarks 2

Table of Contents

CSS Techniques and News

Non-CSS Web Platform Stuff

Not Exactly New, but Noteworthy

My Bug Reports

Upcoming Events

IndieWebCamp Updates

Table of Contents

Introduction

Microformats

Syndicating My Blog to My site

Planned for the future

Final Thoughts

Calculated Fractions (Report the Bugs!)

Open the Bugs!

Weekly Bookmarks 1

Table of Contents

Introduction

CSS Techniques and News

Not Exactly New, but Noteworthy

My Bug Reports

Calculation Indentation

Table of Contents

Introduction

How Prettier Handles It

How I Ended Up Writing It

Another Example

It’s All Subjective

Observation: Clamp to Infinity

Table of Contents

Min and Max

A Problem with clamp() in CSS

Update from 2024-02-19

Looking for a Solution

Use Cases

Aside: Starting to Record Observations

Observation: color-mix and currentColor

Wait About CurrentColor?

Fixing the Custom Ident Docs

Dashed Idents for Everything

Extra Nesting Specificity

Observation: Range Input’s Thumb and Emerging CSS

Table of Contents

A Long Prelude

To the Point

An Occasion to share

Future Observation

My First “Fediversary”

Layer Overrides Update

Moving to Firefox

Table of Contents

What I Had Before

What I’m Moving To

Recommend Me Stuff!

My First Web Platform Tests

Table of Contents

Introduction

Why Contribute to WPT?

The Docs

A Problem with `clamp()` in CSS

3. Unit division and multiplication for mixed units of the same type within `calc()`

4. `attr()` support extended capabilities

5. CSS `element()` function

9. `text-box-trim`

The `scroll-start` Workaround