[css-anchor-position] anchor-size() argument should be optional

[fantasai]

The anchor-size() function, which is defined as a function of the sizing properties (width/height/etc.) has the following syntax:

anchor-size() = anchor-size( <anchor-element>? <anchor-size>, <length-percentage>? )
<anchor-size> = width | height | block | inline | self-block | self-inline

That means in most cases, authors will be writing something like height: anchor-size(height). This seems silly. Shouldn't the <anchor-size> argument be optional, defaulting to the dimension matching the sizing property's effect?

[nt1m]

A function computing to a different value depending on which property it's used on is a bit odd and unlike CSS in general.

e.g. height: anchor-size() and width: anchor-size() shouldn't compute to different values.

Something more CSS-like would probably be a keyword: height: anchor-size or height: match-anchor or similar.

[fantasai]

It doesn't seem odd to me. The anchor() function itself does that also.

[tabatkins]

My only concern is that if we wanted to allow more information to come in (the anchor's margin, or the anchor's right inset-area track, etc), it might not be as clear what the "default" is.

But I don't think I'm opposed to this, if you think that's reasonable given that sort of possible future development.

[yisibl]

So how does block-size match the default value?

block-size: anchor-size() matches to block-size: anchor-size(block)?

Does this contain too much magic? It ends up confusing the writer even more.

[fantasai]

@yisibl I think this is the obvious interpretation.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] anchor-size() argument should be optional, and agreed to the following:

• RESOLVED: Make anchor-size() default to the keyword matching the axis of the property it's used in

The full IRC log of that discussion

<TabAtkins> q+
<emilio> q+
<keithamus> fantasai: often allow dropping args with obvious default. anchor-size has obvoious default of dimension in same axis as the one you're using it on, so height is top, width is other axis. Straightforward to do automatically. Proposal to make it optional
<Rossen4> ack TabAtkins
<keithamus> TabAtkins: only objection is that anchor-size has reasonable extension points in future. eg referring to size of tracks of inset areas.
<keithamus> ... might be less clear what the appropriate defaults are for those
<keithamus> ... right now very clear with width/height. In the future it might be somewhat less.
<keithamus> ... don't object necessarily as it's quite clear for reasonable defaults.
<keithamus> ... but wanted to make sure we felt decent about that.
<Rossen4> ack emilio
<keithamus> emilio: can this be used in min/max properties?
<keithamus> ... should it use regular size?
<keithamus> fantasai: this is just to drop the axis keyword. Doesn't change what you're referencing in terms of size
<keithamus> emilio: Right but it makes it more confusing? Also what happens if anchor is orthogonal to the thing you're using it on?
<keithamus> TabAtkins: That's in the spec it makes the function invalid, resolves to fallback size
<keithamus> emilio: That's not what's expected but okay
<keithamus> fantasai: this is literally just a default keyword
<TabAtkins> https://drafts.csswg.org/css-anchor-position/#anchor-size-valid
<keithamus> Rossen4: any other points or objections?
<fantasai> PROPOSED: Make anchor-size() default to the keyword matching the axis of the property it's used in
<keithamus> Rossen4: I'm calling this resolved.
<fantasai> RESOLVED: Make anchor-size() default to the keyword matching the axis of the property it's used in