-
Notifications
You must be signed in to change notification settings - Fork 720
[css-values-4] What happens to sign(%) when % has no meaning? #12204
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
Comments
https://drafts.csswg.org/css-values/#calc-type-checking
It seems to me that the "otherwise" covers the case of percentages not resolving against anything because they aren't valid. So |
@Loirooriol OK, thanks. I guess that would explain how |
My understanding is that |
@cdoublev Isn't
|
Yes, I have got things completely mixed up. (This is not the first time, sorry.) After a closer look at it, my (new) understanding is that the type made consistent is
|
Is it desirable for (Fixing it seems a little tricky since I think it requires a new percent hint concept that we don't already have: the concept that percentages resolve to something but we don't have a requirement for what.) |
It seems that Firefox and Chrome agree that both
It doesn't seem too unreasonable that |
Edit: nm, I'm misreading my own spec. One second.... |
Per spec, So Chrome and Firefox are currently correct, Safari is wrong. |
Is the "a percent hint of "percent", in resolving a type new? When I implemented this last summer, I was pretty sure that resolving a percentage like this did not set a hint at all. |
I found it, 0edbe98, changed in October! So when implemented, Safari was right, but the spec has changed. @tabatkins, what was the purpose of this change? |
Sorry, I failed to tag that edit against an issue. Searching in my email, looks like it was to address this comment #10840 (comment). It causes the calculation to capture the fact that the calculation context doesn't do anything with a percentage, so I don't try and resolve it against something else and only happen to fail it later, like |
I don't understand how that edit doesn't break the entire percent hint concept and cause every calculation like (I also still think it's desirable for |
I'm confused. The immediately preceding paragraph to that in the spec states that if percentages are resolved against another type, they get a percent hint of that other type. It's only percentages that stand on their own that get the "percent" percent hint.
Luckily that's exactly what happens, as I explain in #12204 (comment) |
Spin-off from #12192:
In e.g.
width: calc(1px * sign(10% - 10px))
, the result depends on what%
resolves to, and that's fine. However, what about:Percentages aren't accepted by
z-index
, and so they don't really resolve against anything. #12192 (comment) suggest thatsign()
should take the value "as-is" (use the sign of the literal percentage value), but that doesn't work for e.g.:By default I'd expect both examples to be invalid at parse-time.
The text was updated successfully, but these errors were encountered: