CSSWG Minutes Telecon (2024-09-18)

For the previous two months, all my livelihood has gone in direction of studying, researching, understanding, writing, and modifying about Anchor Positioning, and with many Almanac entries printed and a full Information information on the best way, I believed I used to be able to tie a bow on all of it and name it executed. I do know that Anchor Positioning remains to be new and settling in. The pace at which it’s moved, although, is superb. And there’s increasingly coming from the CSSWG!

That every one mentioned, I used to be perusing the final CSSWG minutes telecon and knew I used to be in for extra Anchor Positioning once I got here to the next decision:

Each time you’re evaluating names, and at the least one is tree scoped, then each are tree scoped, and the scoping needs to be actual (not subtree) (Challenge #10526: When does anchor-scope “match” a reputation?)

Resolutions aren’t a part of the specification or something, however the strongest of indications about the place they’re headed. So, I believed this was a very good alternative not solely to take a peek at what we’d get in anchor-scope and contact on different attention-grabbing bits from the telecon.

Keep in mind which you could subscribe and learn the complete minutes on W3C.org. 🙂

What’s anchor-scope?

To register an anchor, we can provide it a particular anchor-name after which completely positioned components with an identical position-anchor are connected to it. Though it could seem like it, anchor-name doesn’t need to be distinctive — we might reuse an anchor component inside a part with the identical anchor-name.

<ul>
<li>
<div class=”anchor”>Anchor 1</div>
<div class=”goal”>Goal 1</div>
</li>
<li>
<div class=”anchor”>Anchor 2</div>
<div class=”goal”>Goal 2</div>
</li>
<li>
<div class=”anchor”>Anchor 3</div>
<div class=”goal”>Goal 3</div>
</li>
</ul>

Nevertheless, if we attempt to join them with CSS,

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

.goal {
place: absolute;
position-anchor: –my-anchor;
position-area: prime proper;
}

We get an disagreeable shock the place as an alternative of every .anchor have their .goal positioned at its top-right edge, which means all of them pile up on the final .anchor occasion. We are able to see it higher by rotating every goal a bit of. You’ll need to try the following demo in Chrome 125+ to see the habits:

The anchor-scope property ought to make an anchor component solely discoverable by targets of their particular person subtree. So, the prior instance could be fastened sooner or later like this:

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

That is pretty simple — anchor-scope makes the anchor component obtainable solely in that particular subtree. However then we’ve got to ask one other query: What ought to the anchor-scope personal scope be? We are able to’t have an anchor-scope-scope property after which an anchor-scope-scope-scope and so forth… so which habits ought to it’s?

That is what began the dialog, initially from a GitHub situation:

When an anchor-scope is specified with a <dashed-ident>, it scopes the identify to that subtree when the anchor identify is “matching”. The issue is that this matching could be interpreted in at the least 3 ways: (Assuming that anchor-scope is a tree-scoped reference, which can also be not clear within the spec):

It matches by the ident a part of the identify solely, ignoring any tree-scope that might be related to the identify, or

It matches by actual match of the ident half and the related tree-scope, or

It matches by some mechanism much like dereferencing of tree-scoped references, the place it’s a match when the tree-scope of the anchor-scope-name is an inclusive ancestor of the tree-scope of the anchor question.

After which onto the CSSWG Minutes:

TabAtkins: In anchor positioning, anchor names and references are tree scoped. The anchor-scope property that scopes, doesn’t say whether or not the names are tree scoped or not. Query to determine: ought to they be?

TabAtkins: I feel the reply ought to be sure. When you have an anchor in a shadow tree with an element concerned, then issues outcome if anchor scopes usually are not tree scoped. That is dangerous, so I feel it ought to be tree scoped sounds fairly affordable is sensible to me so far as I can perceive it 🙂

This answer of the scope of scoping properties expanded in direction of View Transitions, which additionally depend on tree scoping to work:

khush: Eager about this within the context of view transitions: in that API you give names and the tree scope needs to be the identical for them to match. There may be one other view transitions function the place I’m unsure if the spec says it’s tree scoped

khush: Need to ensure that function is roofed by the extra common decision

TabAtkins: Proposed extra common decision: each time you’re evaluating names, and at the least one is tree scoped, then each are tree scoped, and the scoping needs to be actual (not subtree)

So the scope of anchor-scope is tree-scoped. Say that 5 instances quick!

RESOLVED: each time you’re evaluating names, and at the least one is tree scoped, then each are tree scoped, and the scoping needs to be actual (not subtree)

The following decision was fairly simple. Moreover permitting a <dashed-ident>, the anchor-scope property can take an all key phrase, which signifies that all anchors are tree-scoped, whereas the <dashed-ident> says that particular anchor is three-scoped. So, the query was if all can also be a tree-scoped worth.

TabAtkins: anchor-scope, along with idents, can take the key phrase ‘all‘, which scopes all names. Ought to this be a tree-scoped ‘all‘? (i.e. solely applies to the present tree scope)

TabAtkins: Proposed decision: the ‘all‘ key phrase can also be tree-scoped in the identical approach sgtm +1, once more identical sample with view-transition-group

RESOLVED: the ‘all‘ key phrase is tree-scoped

The dialog switched gears towards new properties coming within the CSS Scroll Snap Module Degree 2 draft, which is all about altering the consumer’s preliminary scroll with CSS. Taking anexample instantly from the spec, say we’ve got a picture carousel:

<div class=”carousel”>
<img src=”img1.jpg”>
<img src=”img2.jpg”>
<img src=”img3.jpg” class=”origin”>
<img src=”img4.jpg”>
<img src=”img5.jpg”>
</div>

We might begin our scroll to point out one other picture by setting it’s scroll-start-targe to auto:

.carousel {
overflow-inline: auto;
}

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

As of proper now, the one solution to full that is utilizing JavaScript to scroll a component into view:

doc.querySelector(“.origin”).scrollIntoView({
habits: “auto”,
block: “heart”,
inline: “heart”
});

The final instance might be a carousel that’s solely scrollable within the inline course. Nonetheless, there are doubts as far when the container is scrollable in each the inline and block instructions. As seen within the preliminary GitHub situation:

The scroll snap 2 spec says that when there are a number of components that may very well be scroll-start-targets for a scroll container “user-agents ought to choose the one which comes first in tree order“.

Choosing the primary component in tree-order looks like a pure solution to resolve competitors between a number of targets which might be scrolled to in a single explicit axis however is probably not as versatile as could be wanted for the 2nd case the place an writer needs to scroll to 1 merchandise in a single axis and one other merchandise within the different axis.

And again to the CSSWG minutes:

DavidA: We now have a property we’re including known as scroll-start-target that signifies if a component inside a scroll container, then the scroll ought to begin with that component onscreen. Query is what occurs if there are a number of targets?
DavidA: Suggest to do it in reverse-DOM order, this is able to outcome within the first one utilized final after which be on display. Additionally, ought to solely change the scroll place if it’s important to.

After discussing why we’ve got to outline scroll-start-target when we’ve got scroll-snap-align, the dialogue went on focus on the reverse-DOM order:

fantasai: There was a bunch of debate about common vs reverse-DOM order. The place did we find yourself and why?
flackr: At present, we anticipate that it scrolls to the primary merchandise in DOM order. We in all probability need that to nonetheless occur. That’s the reason the proposal is to scroll to every merchandise in sequence in reverse-DOM order.

So we’re coming in reverse to scroll the component, however solely as required so the next components are exhibiting as a lot as potential:

flackr: There may be additionally the problem of nearest…
fantasai: Are you able to clarify nearest?
flackr: Identical as scroll into view
fantasai: ?
flackr: That is wanted with you scroll a number of issues into view and need to discover a good place (?)
fantasai: You scroll in reverse-DOM order…once you add the spec are you able to make it actually clear that that is the top results of the algorithm?
flackr: Sure completely
fantasai: In any other case it appears to make sense

And so it was resolved:

Proposed decision 2: When scroll-start-target targets a number of components, scroll to every in reverse DOM order with textual content to specify precedence is the primary merchandise

Lastly, there was the talk concerning the text-underline-position, that when set to auto says, “The consumer agent might use any algorithm to find out the underline’s place; nevertheless it have to be positioned at or below the alphabetic baseline.” The dialogue was about whether or not the auto worth ought to robotically alter the underlined place to match particular language guidelines, for instance, on the proper of the textual content for vertical writing modes, like Japanese and Mongolian.

fantasai: The preliminary worth of text-underline-position is auto, which is outlined as “discover a good place to place the underline”.
Three choices there: (1) below alphabetical baseline, (2) totally under textual content (good for lots-of-descenders instances), (3) for vertical textual content on the RHS
fantasai: auto worth is outlined within the spec about ‘how far down under the textual content’, however doesn’t say issues about flipping. The present spec says “at or under”. With a purpose to deal with language-specific features, there’s a default UA fashion sheet that for Chinese language and Japanese and Korean there are variations for these languages. A few implementations do that
fantasai: Ought to we modify the spec to say this stuff?
fantasai: Or ought to we keep on with the UA stylesheet method?

The factor is that Chrome and Firefox already place the underline on the correct in vertical Japanese when text-underline-position is auto.

The group was left wiuth three choices:

<fantasai> A) Preserve spec as-is, replace Gecko + Blink to match (utilizing UA stylesheet for language change)
<fantasai> B) Introduce auto to text-emphasis-position and use it in each text-emphasis-position and text-underline-position to impact language switches
<fantasai> C) Undertake inconsistent habits: text-underline-position makes use of ‘auto‘ and text-emphasis-position makes use of UA stylesheet

Many CSSWG members like Emilio Cobos, TabAtkins, Miriam Suzanne, Rachel Andrew and fantasai casted their votes, ensuing within the following decision:

RESOLVED: add auto worth for text-emphasis-position, and alter the which means of text-underline-position: auto to care about left vs proper in vertical textual content

I positively encourage you to learn on the full minutes! Or for those who don’t have the time, you possibly can there’s an inventory simply of resolutions.

CSSWG Minutes Telecon (2024-09-18) initially printed on CSS-Methods, which is a part of the DigitalOcean household. You need to get the publication.