"When I first learned anchor positioning, I built a demo to help me figure out how it all worked. I had a goal of what I wanted and I was trying to figure out what properties I needed to make it happen. I had a profile picture, and, when you clicked on it, I wanted a menu to appear below it, but left aligned to the profile picture, like this:"
".profile-menu { position-anchor: --profile-button; position: absolute; position-area: block-end span-inline-end; } Most of this code is good and fine, but there's one bit that I found surprising and a bit unclear: span-inline-end. This property conveys a few things. The span tells me that I'm crossing columns and including more than one. Makes sense. The inline-end tells me that one of those columns is the inline-end . Great."
"I'm wondering if there should be a change to how CSS works, so that, instead, developers would write center-span-inline-end. That spells it out clearly. You start at the center and you span over to inline-end. Every piece of the puzzle is there. So the code above would be rewritten as this: .profile-menu { position-anchor: --profile-button; position: absolute; position-area: block-end center-span-inline-end; }"
A demo aligns a dropdown menu left to a profile picture using anchor positioning and logical direction. The example uses position-anchor with position-area set to block-end span-inline-end. The span-inline-end term indicates spanning columns and an inline-end boundary, but it leaves ambiguity about the span's starting column. A proposed alternative keyword center-span-inline-end would name both the start (center) and the end (inline-end) to remove that ambiguity. The alternative increases explicitness and verbosity. The change to the specification is under consideration and feedback is requested about preferring clarity versus conciseness.
Read at WebKit
Unable to calculate read time
Collection
[
|
...
]