[css-values-5] calc-size(any, ...) keyword feels confusing

[fantasai]

calc-size() can accept all the sizing keywords as its first argument, plus the keyword any. But what does any mean? It took me awhile (and reorganizing the spec) to figure it out.

AFAICT, it just represents a generic fixed size, i.e. a non-intrinsic size. Which is actually a pretty simple concept, but not one I would associate with any.

I suspect the naming came from the fact that it's compatible with "any" other calc-size() type, but that's not what it is. Can we rename it to a keyword that better represents what it is, like fixed or something?

[tabatkins]

I suspect the naming came from the fact that it's compatible with "any" other calc-size() type

Exactly correct.

I couldn't come up with any better name that wasn't a completely non-obvious keyword, and harder to type to boot.

[tabatkins]

Okay, pushed some reorg of the intro section defining all the basises in a more standard way (dl with each possible value) so it shouldn't require reading between the lines anymore. ^_^

[fantasai]

New proposal: none.

[css-meeting-bot]

The CSS Working Group just discussed [css-values-5] calc-size(any, ...) keyword feels confusing, and agreed to the following:

• RESOLVED: change any to none

The full IRC log of that discussion

<ydaniv> fantasai: have a lot of trouble understanding the any keyword, does it have a basis with other bases
<ydaniv> ... my current proposal for a new name is none
<TabAtkins> q+
<astearns> ack TabAtkins
<ydaniv> TabAtkins: the reaason for any is to indicate the calculation part, which is any size
<ydaniv> ... don't care much about the actual name
<ydaniv> ... fantasai suggests none which I'm ok with
<ydaniv> fantasai: I think it makes it clear that you can't use the calc-size because there's no basis
<weinig> q+
<ydaniv> astearns: other opinions?
<fantasai> s/calc-size/size keyword/
<astearns> ack weinig
<ydaniv> weinig: would that work with the max-size use of none?
<ydaniv> TabAtkins: no
<estelle> q+
<astearns> ack estelle
<ydaniv> estelle: I thought it would be more understanable to use auto
<ydaniv> fantasai: auto means the basis is auto, can't use that
<fantasai> calc-size(basis, size * 3 + 100%)
<ydaniv> TabAtkins: yes, agree
<TabAtkins> (agree that "auto" is already taken, that is)
<ydaniv> fantasai: when you set it to this keyword you can use the size in your expression
<fantasai> s/3/3px/
<fantasai> s/3px/3/
<ydaniv> ... you can't put size because there's no basis, it can't be calc'ed
<ydaniv> ... so this is why I'm proposing none
<astearns> ack dbaron
<ydaniv> dbaron: I'm a little worried about weinig's issue, that we'll never want to use the none of max-size and max-width
<JoshT> q+
<ydaniv> ... since none is a value, and when you learn what calc-size is, so it looks like you're using none as tha basis
<kizu> q+
<ydaniv> TabAtkins: the confusion seems valid, but don't have a strong opinion
<astearns> ack JoshT
<ydaniv> JoshT: I think it's a good keyword, but maybe null?
<ydaniv> TabAtkins: because we don't use null
<astearns> ack kizu
<lea> +1 to no new syntax
<weinig> q+
<ydaniv> kizu: do we need a keyword at all? Could we just use the value?
<ydaniv> TabAtkins: current spec requires 2 values
<ydaniv> dbaron: I think when we added interpolate-size it became more useful?
<ydaniv> TabAtkins: first argument can be the calc, and also the second, so it's not clear if you omit one
<ydaniv> ... you can take an existing calc, remove 2nd arg... so won't to keep a keyword there to reduce confusion
<astearns> ack weinig
<ydaniv> weinig: wanted to clarify, none is not a valid word for min-width, only for max
<TabAtkins> calc-size(50% + 10px, 50% + 10px) is valid, for example, so it's not clear that calc-size(50% + 10px) is meant to treat that as the *second* argument
<fantasai> PROPOSED: Change any to none
<fantasai> +1
<ydaniv> astearns: objections?
<dbaron> I think I lean against but I don't object.
<JoshT> +1
<ydaniv> RESOLVED: change any to none

[dbaron]

So the one other piece here is that this is something we've been shipping for slightly over two years -- I think a new name at this point is something that should have a slightly stronger justification. The calc-size() use counter is at almost 0.3%, and the interpolate-size use counter is at almost 11%. (Note that use of interpolate-size could cause calc-size() values to be serialized.)

So I could probably go add both parsing and serialization use counters for calc-size(any, ...), but I'm also not convinced that it's worth going ahead with that when it's not clear that I could get the intent to ship and particularly the intent to remove approved by API owners based on the justification given in this issue.

So I'd actually like to reopen this discussion.