Yes, SDA can work for something like this, but in a pretty hacky way: kizu.dev/position-dri...

At #cssday I heard from someone on the Chrome team that it is possible that they will look into #css linked parameters. For example, for passing them into #svg.

Do you need this too? Are you tired of bundles with hundreds of inlined SVG icons as jsx?

Write about your use cases! Either here, or […]

This one actually does not use them — it uses container query and captured custom properties :D

The one with SDA was in my previous article — kizu.dev/fit-to-width...

(the bug itself is also pretty weird, in that it might be a symptom of some more serious underlying issue with SDA, so probably better to look into it earlier than later)

(I will still look into some other issues I saw, but most of them stemmed from this bug, but not all)

For visibility, I replied to Jen on Mastodon with one bug I found and managed to isolate: front-end.social/@kizu/114185...

The bug itself: bugs.webkit.org/show_bug.cgi...

This bug affects most of my demos, so I would prefer to wait until it will be fixed before further testing :)

Around half of my SDA examples (kizu.dev/tags/scroll_...) work (great!) in 213.

Should I report the specifics for those that don't, or better to wait until 214 and check there?

Mm, with the value based on `em`, things seem to work perfectly in my example: because we scale the font-size proportionally after laying things once, anything that uses `em` will scale at the same rate, so both the line will continue to fit and the proportions between elements inside the line stay.

In the example at the start of the thread, it is totally ok to keep the inner elements with not increased size, and the whitespace between them growing: there are always ways to shoot yourself in the foot when you're an author, and we can always get used to weird stuff once we learn how it works.

Cases where the elements inside have calculated dimensions like `calc(30px - 1em)` are much harder, but that's an edge case where it is ok to not get the proper “fit to width” behavior and to bail out earlier, either bumping not to full width, or not doing anything if the result is narrower.

Mm, the way I see it: we take a line, separate it into fragments, check which depend on the font-size of the container, subtract the combined width of the static fragments, and calculate the fit-to-width based on the rest.

Old example (with one static element, a square): codepen.io/kizu/pen/Rwz...

Am I using macOS exclusively for more than 17 years? Yes. Do I still remember the alt+0151 shortcut to write the em-dash on Windows? Also yes.

That would be great! Even better if it was possible to do the same for just any custom properties, including not registered — even without a known type, it is possible to check if it matches a certain type and calculate it, see kizu.dev/preview-mixin/ :)

As usual, the credits:

- @lea.verou.me (conditions!)
- @tldraw.com (schemes!)
- @5t3ph.bsky.social (smol grid!)
- @heydonworks.bsky.social (original question!)
- @miriam.codes (mixins!)