-
Notifications
You must be signed in to change notification settings - Fork 647
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-values] specification for calc() should be clearer about when the result has a percentage #10017
Comments
Unit division is actually well-defined, by reference to Typed OM's concept of "matching". Something matches In-flight edit: actually it looks like I am invoking the types wrong for cases like min(); there I just say the args must have "the same type" and define that the function resolves to that type. This doesn't handle percent hints properly. I'll need to tweak it. sign() does indeed currently erase the percentage information, tho, as does anything that returns a value of a different type than its input calculations. We should think about whether it should transfer that information thru - doing so via the calculation type (copying the percent hint of the input calculation) would mean it doesn't match The progress() family just need to define their type as the sum of their input calculation's types, same as min()/etc. (Subject to the changes I just discovered I need to make.) calc-size() makes an end-run around the issue, since it defines that it simply acts like its basis argument in all ways. |
If they contain a percentage, I think they should be treated as containing a percentage, no matter how much nested into math functions it appears. The exception should be e.g. @tabatkins You are mentioning types, but percentages in
|
Yup, that's also part of what I noticed was wrong. Percents resolved against another type should gain that as a percent hint. |
Oops, I had misunderstood the statement in determine the type of a calculation that "In all cases, the associated percent hint is null" as applying to the whole section rather than just the terminal values, so I thought that the |
Yeah, I'm gonna do a quick rewrite of that bit, I also read it wrong before realizing the scope of that line. :( |
…s that type as a percent hint. #10017
Okay, fixed up the first two issues. After giving it some thought, I'm fairly certain that the type-changing functions should also retain the percent hint of their arguments. I think in practice it's fine; Typed OM has to worry about percentages that aren't yet resolved (thus the percent hint, which indicates what we've assumed the percent will resolve to), while in general use the calculation will know where it's used, so percents will all have a consistent type. Still, tho, I'm gonna go ahead and define that they preserve the type hint. |
I think I also agree that the type-changing functions should preserve the percent hint, with the probable exception of Is there someplace that defines that it's the percent hint that affects the layout behaviors I mentioned? I don't think defining whether the value is accepted for a (Also see #10018, which I filed as a separate issue since it's at least somewhat distinct.) |
…ercent hint of their inputs. #10017
Yup, that's now in the spec.
What do you mean by this?
No, not yet. Values is probably the right place to define it, one sec. |
I mean that |
Oh, yeah, a % in the calculation argument of calc-size() shouldn't have any effect; I censor the bad cases away by making the % resolve to 0 in that case. Only a % in the basis argument matters, and that should be already handled by the spec. Anyway, "contains a percentage" is now defined in terms of the percent hint in the value's type, and I made Sizing 3 ref that. I'm sure there are other places we need to reference this from, but I'd have to hunt them down. |
Okay, I've finished up the edits to Values 5 as well. Making progress() correctly preserve percentage-ness into a calc-mix() was a little tricky, but it should be correct now, so As far as I can tell, this is fully resolved now. |
Should I am asking this because they are defined to take calculation(s) resolving either to I also note that Typo:
|
I believe percentage-ness should also be preserved in these functions. It should never be removed once added into a calculation. The implementation in Chrome doesn't fully comply with the spec. There's no exact equivalence of percentage-ness in the impl, and it assumes that there's percentage-ness iff the result type involves percentages. |
@cdoublev See the explanation in https://drafts.csswg.org/css-values/#exponent-funcs "Why does hypot() allow dimensions (values with units), but pow() and sqrt() only work on numbers?" It's not even clear what sine and friends would do with a dimension (other than an angle, which is dimensionless in math) That said, things like I think Tab forgot about |
Ah yes, I had forgotten that divisions like |
I might be missing something again but
|
Mm, yeah, I guess |
Whoops, that's an oversight on my part. In the source, there's a huge details block separating the log/exp definitions from the preceding pow/sqrt/hypot ones, so I just missed that they were there. |
Re: the percent hint making things not match, I'm thinking now if I ever actually needed that restriction. What I really want to capture is the idea that the context the calculation finds itself in supplies the ability to resolve percentages (or not). I ran into this as an issue when dealing with progress()/*-mix(), and kinda manually hacked it in, but you're right that this is a larger issue. Let me fiddle with the wording a bit. |
…percentage tokens to be equivalent to a number. #10017
Okay, yeah, I've gone ahead and loosened the text in Typed OM; it now just requires that the context in which the value is used allow percentages; if that's true, it can then match a I've also tweaked |
The argument calculations in The modulus functions <dfn lt="mod()">mod(A, B)</dfn>
and <dfn lt=rem()>rem(A, B)</dfn>
[...]
The argument [=calculations=] can resolve to any <<number>>, <<dimension>>, or <<percentage>>,
- but must have the <em>same</em> [=determine the type of a calculation|type=],
+ but must have a [=consistent type=]
or else the function is invalid;
- the result will have the same [=CSSNumericValue/type=] as the arguments.
+ the result's type will be the [=consistent type=]. The input calculations in The <dfn lt="log()">log(A, B?)</dfn> function
contains one or two [=calculations=]
[...]
which must resolve to <<number>>s,
and returns the logarithm base B of the value A,
as a <<number>>
- with the return type [=made consistent=]
- with the input [=calculation’s=] type.
+ The input [=calculations=]
+ must have a [=consistent type=]
+ or else the function is invalid;
+ the result's type will be the [=consistent type=]. The return value type of All of the [=calculation=] arguments can resolve to any <<number>>, <<dimension>>, or <<percentage>>,
- but must have the <em>same</em> [=determine the type of a calculation|type=], or else the function is invalid;
- the result will have the same type as the arguments.
+ but must have a [=consistent type=], or else the function is invalid;
+ the result's type will be the [=consistent type=]. And - <progress> = [ <percentage> | <number> | <'animation-timeline'> ]? && by <easing-function>
+ <progress> = [ <percentage-token> | <number> | <'animation-timeline'> ] [ by <easing-function> ]? |
My first thought was that I did not considered that the context should supply the ability to resolve percentages as a valid reason, because I thought edit: hmm, no, there is no percent hint involved in my example, which is valid, but I do not see when a percent hint can appear when the context does not allow it. |
An expression having a percent hint means that the expression only makes sense if percentages in that expression are the type of the percent hint. For example, So if we don't check percent hints at all for values of type |
Another relevant example showing something that we do want to accept is |
I think the presence of a percent hint should indicate that the context allows resolving percentages as that type. So in |
(Thanks for the examples. I missed that a percentage can get a percent hint when it is added to a dimension type.) Returning failure when adding a percentage type without a percent hint to anything but a percentage without a percent hint, also makes sense to me. edit: no because "when you're doing operations on plain |
There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage. In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against: inside of something with
auto
height aheight: calc(30px)
is a fixed value but aheight: calc(30px + 0%)
is treated asheight: auto
.With
calc()
as it was specified in css-values-3, this could essentially be implemented as part of the type computation; acalc()
expression could effectively be either a<length>
or a<length-percentage>
as its toplevel type, and those that were<length-percentage>
act as though they have a percent.Newer levels of the specification introduce features that make this approach insufficient:
sign()
progress()
and related functionscalc-size()
(I think this is clearly defined for
calc-size()
because it's very important there, but I don't think it's clearly defined for the other cases.)It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage.
The text was updated successfully, but these errors were encountered: