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

For the previous two months, all my livelihood has gone in the direction of studying, researching, understanding, writing, and modifying about Anchor Positioning, and with many Almanac entries revealed 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 accomplished. I do know that Anchor Positioning continues to be new and settling in. The velocity at which it’s moved, although, is wonderful. 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 after I got here to the next decision:

At any time when you might be evaluating names, and no less than one is tree scoped, then each are tree scoped, and the scoping must be actual (not subtree) (Difficulty #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 great alternative not solely to take a peek at what we would get in anchor-scope and contact on different attention-grabbing bits from the telecon.

Bear in mind which you can subscribe and learn the total 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 hooked up to it. Although it might appear to be 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>

Nonetheless, if we attempt to join them with CSS,

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

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

We get an disagreeable shock the place as an alternative of every .anchor having their .goal positioned at its top-right edge, 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 wish to try the subsequent demo in Chrome 125+ to see the conduct:

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 mounted sooner or later like this:

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

That is pretty easy — anchor-scope makes the anchor component obtainable solely in that particular subtree. However then now we have 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 conduct 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 title to that subtree when the anchor title is “matching”. The issue is that this matching may be interpreted in no less than 3 ways: (Assuming that anchor-scope is a tree-scoped reference, which can be not clear within the spec):

1. It matches by the ident a part of the title solely, ignoring any tree-scope that will be related to the title, or
2. It matches by actual match of the ident half and the related tree-scope, or
3. 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 must be sure. If in case you have an anchor in a shadow tree with a component concerned, then issues end result if anchor scopes will not be tree scoped. That is dangerous, so I feel it must be tree scoped

<khush> sounds fairly cheap

<fantasai> is smart to me so far as I can perceive it 🙂

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

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

khush: Need to be sure that function is roofed by the extra basic decision

TabAtkins: Proposed extra basic decision: at any time when you might be evaluating names, and no less than one is tree scoped, then each are tree scoped, and the scoping must be actual (not subtree)

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

RESOLVED: at any time when you might be evaluating names, and no less than one is tree scoped, then each are tree scoped, and the scoping must be actual (not subtree)

The subsequent decision was fairly easy. In addition to permitting a <dashed-ident> that claims that particular anchor is three-scoped, the anchor-scope property can take an all key phrase, which signifies that all anchors are tree-scoped. So, the query was if all can 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 be tree-scoped in the identical means sgtm +1, once more similar 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 person’s preliminary scroll with CSS. Taking an instance instantly from the spec, say now we have a picture carousel:

<div class="carousel">
  <img src="https://css-tricks.com/csswg-minutes-telecon-2024-09-18/img1.jpg">
  <img src="https://css-tricks.com/csswg-minutes-telecon-2024-09-18/img2.jpg">
  <img src="https://css-tricks.com/csswg-minutes-telecon-2024-09-18/img3.jpg" class="origin">
  <img src="https://css-tricks.com/csswg-minutes-telecon-2024-09-18/img4.jpg">
  <img src="https://css-tricks.com/csswg-minutes-telecon-2024-09-18/img5.jpg">
</div>

We may set the preliminary scroll to indicate one other picture by setting it’s scroll-start-target to auto:

.carousel {
  overflow-inline: auto;
}

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

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

doc.querySelector(".origin").scrollIntoView({
  conduct: "auto",
  block: "heart",
  inline: "heart"
});

The final instance might be a carousel that’s solely scrollable within the inline path. 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 could possibly be scroll-start-targets for a scroll container “user-agents ought to choose the one which comes first in tree order“.

Deciding on the primary component in tree-order looks as if a pure technique to resolve competitors between a number of targets which might be scrolled to in a single specific axis however is probably not as versatile as could be wanted for the second case the place an creator needs to scroll to at least one merchandise in a single axis and one other merchandise within the different axis.

And again to the CSSWG minutes:

DavidA: We’ve got 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 end result within the first one utilized final after which be on display. Additionally, ought to solely change the scroll place if you must.

After discussing why now we have to outline scroll-start-target when now we have scroll-snap-align, the dialogue went 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 count on that it scrolls to the primary merchandise in DOM order. We most likely 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 displaying as a lot as potential:

flackr: There may be additionally the difficulty of nearest…
fantasai: Are you able to clarify nearest?
flackr: Similar as scroll into view
fantasai: ?
flackr: That is wanted with you scroll a number of issues into view and wish to discover a good place (?)
fantasai: You scroll in reverse-DOM order…whenever 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 in regards to the text-underline-position, that when set to auto says, “The person agent might use any algorithm to find out the underline’s place; nonetheless it should be positioned at or below the alphabetic baseline.” The dialogue was about whether or not the auto worth ought to mechanically modify 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) absolutely under textual content (good for lots-of-descenders circumstances), (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 view to deal with language-specific features, there’s a default UA model sheet that for Chinese language and Japanese and Korean there are variations for these languages. A few implementations do that
fantasai: Ought to we alter the spec to say these items?
fantasai: Or ought to we keep on with the UA stylesheet strategy?

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

The group was left with three choices:

<fantasai> A) Maintain spec as-is, replace Gecko + Blink to match (utilizing UA stylesheet for language swap)
<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 conduct: 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 that means of text-underline-position: auto to care about left vs proper in vertical textual content

I undoubtedly encourage you to learn on the full minutes! Or in case you don’t have the time, you may there’s a listing simply of resolutions.