-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-anchor-position] anchor-size() argument should be optional #10318
Comments
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. Something more CSS-like would probably be a keyword: |
It doesn't seem odd to me. The |
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. |
So how does block-size match the default value?
Does this contain too much magic? It ends up confusing the writer even more. |
@yisibl I think this is the obvious interpretation. |
The CSS Working Group just discussed
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 |
The
anchor-size()
function, which is defined as a function of the sizing properties (width/height/etc.) has the following syntax: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?The text was updated successfully, but these errors were encountered: