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

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 printed and a full Information information on the way in which, I believed I used to be able to tie a bow on all of it and name it carried out. I do know that Anchor Positioning remains to be new and settling in. The pace at which it’s moved, although, is wonderful. And there’s increasingly coming from the CSSWG!

That each one stated, 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:

Every time you might be evaluating names, and a minimum of one is tree scoped, then each are tree scoped, and the scoping needs to be actual (not subtree) (Subject #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 superb alternative not solely to take a peek at what we would get in anchor-scope and contact on different fascinating bits from the telecon.

Keep in mind you could 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 parts with an identical position-anchor are connected to it. Regardless that it could appear to be it, anchor-name doesn’t need to be distinctive — we could reuse an anchor component inside a element 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 having their .goal positioned at its top-right edge, all of them pile up on the final .anchor occasion. We will see it higher by rotating every goal just a little. You’ll wish to try the subsequent 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 can be fastened 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 will’t have an anchor-scope-scope property after which an anchor-scope-scope-scope and so forth… so which habits ought to or not it’s?

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

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 might be interpreted in a minimum of 3 ways: (Assuming that anchor-scope is a tree-scoped reference, which can also be not clear within the spec):

1. It matches by the ident a part of the identify solely, ignoring any tree-scope that may be related to the identify, 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 an element concerned, then issues consequence if anchor scopes usually are not tree scoped. That is unhealthy, so I feel it must be tree scoped

<khush> sounds fairly cheap

<fantasai> is sensible 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: Occupied with 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 guarantee that function is roofed by the extra common decision

TabAtkins: Proposed extra common decision: every time you might be evaluating names, and a minimum of 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: every time you might be evaluating names, and a minimum of one is tree scoped, then each are tree scoped, and the scoping needs to be actual (not subtree)

The subsequent decision was fairly easy. Apart from permitting a <dashed-ident> that claims that particular anchor is three-scoped, the anchor-scope property can take an all key phrase, which implies that all anchors are tree-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 method 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 Stage 2 draft, which is all about altering the consumer’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 might 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 method to obtain 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 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 subject:

The scroll snap 2 spec says that when there are a number of parts that might 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 as if a pure method to resolve competitors between a number of targets which might be scrolled to in a single specific axis however is maybe not as versatile as could be wanted for the 2nd case the place an creator desires 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 a property we’re including referred to 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 might consequence within the first one utilized final after which be on display screen. Additionally, ought to solely change the scroll place if it’s important to.

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: Presently, we anticipate 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 parts are exhibiting as a lot as attainable:

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…while 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 parts, 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 could use any algorithm to find out the underline’s place; nonetheless 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) absolutely beneath 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 beneath the textual content’, however doesn’t say issues about flipping. The present spec says “at or beneath”. So as to deal with language-specific points, 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 alter the spec to say these items?
fantasai: Or ought to we stick to 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) Preserve 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 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 that 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 may there’s a listing simply of resolutions.