@miunau

Anchor positioning is powerful, but that power comes with a lot of complexity — of course any built-in solution that targets a specific use case like tooltips will work from the box much better than any low-level code, but we will get mixins and custom functions in CSS, and will be able to abstract any complexity away. And, over time, improve the syntax to support the more common cases in more streamlined ways as well.

@miunau

- The `position-anchor` and explicit anchor inside functions have their meaning and usage as well. An anchored element can have only one associate element that would be used for various things like attaching to that element's scrolled position, but as mentioned above you could want to use multiple anchors (and no need to use the same anchor in both places, as in `anchor()` it can be omitted if `position-anchor` is present).

@miunau

- There is place for both logical and physical units: not always you're working with purely text content — when attaching things to images, in print context, and many other cases the physical units _are_ the correct choice.

- Positioning to multiple anchors is super useful for a myriad of cases if we put aside tooltips/popovers. Stuff like https://kizu.dev/anchor-positioning-experiments/#using-the-connections (and some other cases from this very early article) cannot be done in any other way.

@miunau Any details on what exactly didn't work or was awkward? :)

Safari 26.2 is here with 65 features + 165 bug fixes — including `field-sizing`, Navigation API, Largest Contentful Paint, `command` & `commandfor`, CHIPS opt-in partitioned cookies, `scrollend` event, `random()`, WebGPU in WebXR, `scrollbar-color`, `hidden=until-found` and *much* more! https://webkit.org/blog/17640/webkit-features-for-safari-26-2/

@frehner Ooh, nice! Good job!

Friday fun with the web.

I made this with MathML and CSS only 📏📐

Kids learn by having fun. Fun makes everything better.

As adult professionals, we tend to forget this and take ourselves too seriously sometimes.

Make something silly today! I guarantee you'll learn something along the way.

@knowler @davatron5000 was using it recently, can confirm, it works! :blobcatgiggle:

@cheeaun Yep! I did not participate, but observed from outside at all the CSS crimes that were happening there.

@suricrasia did a short write-up on CSS tricks about it: https://css-tricks.com/the-lost-css-tricks-of-cohost-org/, and a much more in-depth breakdown of one such crime: https://suricrasia.online/blog/inline-css-puzzle-box/

Request: a federated network, which is like cohost, but which not just allows inline styles, but `<style></style>`, contents of which could be automatically wrapped with `@scope{}` to apply only to the post itself.

I think the element-based `@scope` could potentially be a really nice way to introduce styling in various user-generated contexts in general.

@nicolaschevobbe Nice :D The original case shows that when you resize the last element, the position is stateful, I guess this one is the extention of that.

@nicolaschevobbe I wanted to reduce it a bit more before submitting, but I think this one is close enough: https://codepen.io/kizu/pen/ByKMEwy?editors=1100 — compare what happens in Firefox and Chrome. It is also buggy in Safari, but I already reported one related bug to chained anchors there, and need to check if that's the same case or not first.

@mia I remember looking at it some time ago, noticing the demo instance used tailwind, and bouncing off right away…

One of the main requirements from me for a social network is for its styles being overrideable, and anything using tailwind is purely hostile to that.

Obviously, that's just frontend, it is possible to use external clients, etc., but if I were to choose “home”, it won't be it.

I am more curious about https://gotosocial.org/ — that looked much closer to what I'd want.

Rendering 1000 elements unconditionally chained one after another (or maybe ~2000 elements including pseudos) took around 17 seconds on my m1 max.

When trying to render true 10k I tired of waiting and killed the tab.

Ok, I guess “conditionally” was the keyword: in fact while there were 10000 elements (actually… 30000 + another 20000 pseudos), it did not use the full chaining for all of them, only for initial ones, and the rest were still using anchor positioning, but falling back to one of the earlier items.

Testing the “full chaining, one after another” in my setup with the performance profiler, when the count reached ~100, long tasks started to appear, and layout time started increasing.

I don't know who needs to hear it, but I just test out an attempt to conditionally chain more than 10000 elements one to each other with anchor positioning, and in Chrome it works. Neither Safari nor Firefox don't currently work well with even a few chained elements, but, I guess, I now have a good benchmark :blobcatknife:

@yatil Thank you for the extensive answer!

@yatil Should that one element you'll move focus to be some actual element that is used for something else, or is it ok to create an extra element just for this purpose?

Is the “you should never blur” because of how browsers handle it? Do you think it would be worth it trying to fix the root of the problem, and specifying the best possible behavior for `blur()` so eventually it could be a useful feature?

@yatil A specific common use case: something like a code editor textarea that overrides the `tab` to insert the indentation. `esc` to blur could be a way to “escape” such focus trap, but `.blur()` seems to be problematic. I can think of alternatives like focusing something else on esc, but that feels fragile and I am not sure what is the best way to handle it.

@yatil Yes. Chrome and Firefox after that allow you to continue keyboard navigation from the same place you were before, while Safari will navigate from the `activeElement` seemingly.