CSSWG Minutes Telecon (2024-09-18) | CSS-Tricks

For the past two months I have spent my entire living reading, researching, understanding, writing and editing about anchor positioning, and with many almanac entries published and a full guidebook on the way, I thought I was ready to give it a rest bind Think about it and call it done. I know the anchor positioning is still new and getting used to. However, the speed at which it moves is astonishing. And more and more is coming from the CSSWG!

That being said, I was looking at the latest CSSWG teleconference minutes and knew I was in for more anchor positioning when I came to the following conclusion:

If you compare names and at least one has a tree scope, then both have a tree scope and the scope must be exact (not a subtree) (Issue #10526: When is this the case? anchor-scope “match” a name?)

Resolutions aren’t part of the spec or anything, but rather the strongest indications of where they’re going. So I thought this would be a good opportunity to not just take a look at what to expect anchor-scope and explore other interesting aspects of telecommunications.

Remember that you can subscribe and Read the full transcript at W3C.org. 🙂 🙂

what is anchor-scope?

To register an anchor, we can give it a distinctiveness anchor-name and then absolutely positioned elements with a matching position-anchor are attached to it. Even if it looks like that, anchor-name doesn’t have to be unique – we can reuse an anchor element within a component with the same anchor-name.

   

	
Anchor 1
	
Target 1
   
   

	
Anchor 2
	
Target 2
   
   

	
Anchor 3
	
Target 3
   

However, when we try to connect them with CSS,

.anchor {
  anchor-name: --my-anchor;
}

.target {
  position: absolute;
  position-anchor: --my-anchor;
  position-area: top right;
}

Instead of each one, we get an unpleasant surprise .anchor have theirs .target Positioned at the top right edge, they all stack on top of the last one .anchor Example. We can see it better by rotating each target a little. Check out the next demo in Chrome 125+ to see the behavior:

The anchor-scope The property should ensure that an anchor element is only discoverable by targets in its individual subtree. So the previous example would be fixed in the future as follows:

.anchor {
  anchor-name: --my-anchor;
  anchor-scope: --my-anchor;
}

This is pretty simple – anchor-scope Makes the anchor element available only in this specific subtree. But then we have to ask another question: What’s that supposed to mean anchor-scope own scope? We can’t have any anchor-scope-scope property and then a anchor-scope-scope-scope and so on… so what behavior should it be?

This is how the conversation began, initially from a GitHub issue:

If a anchor-scope is indicated by a the name is restricted to that subtree if the anchor name “matches”. The problem is that this comparison can be interpreted in at least three ways: (Assuming that anchor-scope is a tree-wide reference, which is also not clear in the spec):

1. It only matches the identical part of the name and ignores any tree regions that would be associated with the name or
2. It matches in that the identity part and the associated tree region match exactly, or
3. The match occurs through a mechanism similar to dereferencing tree scope references, where a match occurs when the tree scope of the anchor scope name is an inclusive ancestor of the tree scope of the anchor query.

And then to the CSSWG protocol:

TabAtkins: In anchor positioning, anchor names and references are tree related. The anchor-scope Property that is scoped does not indicate whether the names are tree scoped or not. Key question: Should they be?

TabAtkins: I think the answer should be yes. If you have an anchor in a shadow tree that involves a part, problems arise when anchor areas do not have a tree area. This is bad, so I think it should be a tree

sounds pretty reasonable

makes sense to me as far as I can understand it 🙂

This solution expanded the scope of scoping properties to include view transitions, which also rely on tree scoping to function:

khush: Think about this in the context of view transitions: in this API you specify names, and the tree scope must be the same for them to match. There is another feature for view transitions that I’m not sure if the spec says is tree pane

khush: You want to make sure this feature is covered by the more general resolution

TabAtkins: Suggested more general solution: If you are comparing names and at least one has a tree scope, then both have a tree scope and the scope must be exact (not a subtree).

So the scope of anchor-scope is tree-related. Say that five times fast!

SOLVED: If you compare names and at least one has a tree scope, then both have a tree scope and the scope must be exact (not a subtree).

The next solution was pretty simple. Apart from the fact that a that says The The specific anchor is designed in three ways anchor-scope Property can take one all Keyword meaning all anchors have a tree scope. So the question was whether all is also a tree-related value.

TabAtkins: anchor-scopeIn addition to Idents, the keyword ‘all‘, which includes all names. Should this be a tree related ‘all‘? (i.e. only applies to the current tree area)

TabAtkins: Proposed decision: the “allThe keyword ‘ is also tree related in the same way as sgtm +1, again using the same pattern view-transition-group

SOLVED: The ‘allThe keyword ‘ is tree related

The conversation shifted its focus to new properties coming in 2019 CSS Scroll Snap Module Level 2 Draft, which is all about changing the user’s initial scrolling with CSS. Let’s take an example straight from the spec: Suppose we have an image carousel:

We could set the initial scroll to show a different image by setting it scroll-start-target To auto:

.carousel {
  overflow-inline: auto;
}

.carousel .origin {
  scroll-start-target: auto;
}

Currently the only way to achieve this is to use JavaScript to scroll an element into the view:

document.querySelector(".origin").scrollIntoView({
  behavior: "auto",
  block: "center",
  inline: "center"
});

The last example is probably a carousel that is only scrollable in the inline direction. Still, there are doubts about whether the container is scrollable in both inline and block directions. As seen in the First GitHub issue:

The scroll snap 2 spec says that when there are several elements that could be scroll-start-targets For a scroll container, user agents should select the one that arrives first Tree order“.

Selecting the first element in the tree order seems to be a natural way to resolve the competition between multiple targets that would be scrolled to in a given axis, but may not be as flexible as would be required for the second case where an author wants to scroll to an element in one axis and another element in the other axis.

And back to the CSSWG protocol:

DavidA: We add a property named scroll-start-target This indicates that an element in a scrolling container should start scrolling with that element on the screen. The question is, what happens when there are multiple targets?
DavidA: Suggest doing this in reverse DOM order. This would result in the first being applied last and then appearing on the screen. Additionally, the scroll position should only be changed when necessary.

After discussing why we need to define scroll-start-target when we have it scroll-snap-alignthe discussion went in reverse DOM order:

Fantasy: There has been a lot of debate about regular vs. reverse DOM order. Where did we end up and why?
flackr: Currently we assume that it scrolls to the first element in the DOM order. We probably want that to happen anyway. For this reason, it is suggested to scroll to each element one at a time in reverse DOM order.

So we do it in reverse order to scroll the element, but only as necessary so that the following elements are displayed as much as possible:

flackr: There is also the question of the nearest…
Fantasy: Can you explain this to me closest?
flackr: Same as scrolling into view
Fantasy: ?
flackr: This is needed when you want to scroll multiple things into view and find a good position(?)
Fantasy: They scroll in reverse DOM order. When adding the spec, can you really make it clear that this is the end result of the algorithm?
flackr: Yes, absolutely
Fantasy: Otherwise it seems to make sense

And this is how it was solved:

Proposed Decision 2: When scroll-start-target targets multiple elements. Scroll to each in reverse DOM order with text to indicate priority is the first element

Finally there was the debate about it text-underline-positionthat when it is set to auto says: “The user agent can use any algorithm to determine the position of the underline; However, it must be placed on or below the alphabetical baseline.” The discussion was about whether the auto The value should automatically adjust the underlined position according to certain language rules, such as to the right of text for vertical writing modes such as Japanese and Mongolian.

Fantasy: The initial value of text-underline-position Is autowhich is defined as “Find a good place to put the underline.”
There are three options there: (1) below the alphabetic baseline, (2) completely below the text (good for cases with a lot of descenders), (3) for vertical text on the right side
Fantasy: The Auto value is defined in the spec by how far below the text goes, but says nothing about flipping. The current specification says “at or below”. To address language-specific aspects, there is a standard UA stylesheet that has differences for Chinese, Japanese, and Korean for these languages. Some implementations do this
Fantasy: Should we change the spec to mention these things?
Fantasy: Or should we stick with the UA stylesheet approach?

The thing is that Chrome and Firefox already place the underline on the right in vertical Japanese if text-underline-position Is auto.

The group was left with three options:

A) Keep the spec, update Gecko + Blink accordingly (using the UA language switching stylesheet).
B) Introduce car text-emphasis-position and use it in both text-emphasis-position And text-underline-position to carry out language switching
C) Adopt inconsistent behavior: text-underline-position used ‘auto‘ And text-emphasis-position uses UA stylesheet

Many CSSWG members such as Emilio Cobos, TabAtkins, Miriam Suzanne, Rachel Andrew and fantasai cast their votes, resulting in the following resolution:

SOLVED: Add a value of “auto” for “text-emphasis-position” and change the meaning of “text-underline-position: auto” to account for left and right in vertical text

I definitely encourage you to read the entire minute! Or if you don’t have time, you can do it There is only one list of resolutions.