Skip to content
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-4] Should <percentage> be invalid in calculations matching <number>? #9661

Closed
cdoublev opened this issue Nov 30, 2023 · 4 comments
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-values-4 Current Work

Comments

@cdoublev
Copy link
Collaborator

cdoublev commented Nov 30, 2023

I suspect that determining the type of <percentage> should be a failure when the grammar does not accept <percentage>, instead of defaulting to [percent: 1]:

  • calc(1% / 1%) should be an invalid z-index because its grammar only accepts <number>
  • calc(1% / 1% * 1px) should be a valid width because its grammar accepts both <length> and <percentage>, which resolves to a <length> based on the width or height of the containing block

Note: I assume that the type of calc(1% / 1%) as a value for z-index is currently [percent: 0], which matches <number>.

Or am I missing something?

@tabatkins
Copy link
Member

No, the current behavior is somewhat intentional; it's similar to how z-index: calc(2em / 10px) is valid despite z-index not accepting lengths.

Note: I assume that the type of calc(1% / 1%) as a value for z-index is currently [percent: 0], which matches .

Correct.

@cdoublev
Copy link
Collaborator Author

cdoublev commented Dec 1, 2023

Relative lengths can always be resolved with an absolute base in px: font-size of the element, the viewport width, etc.

So <percentage>s in 1% / 1% do not have any absolute base and are not resolved before applying the operation, which results to 1, ok. Thanks.

@cdoublev cdoublev closed this as completed Dec 1, 2023
@cdoublev cdoublev added css-values-4 Current Work Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. labels Dec 1, 2023
@cdoublev
Copy link
Collaborator Author

cdoublev commented Dec 1, 2023

Please note that step 9.4 of simplify a calculation tree requires to resolve 2em / 10px with a value expressed in the result’s canonical unit, whereas this cannot be achieved (at parse time) with 2em. I reported this problem in #7456 but at the time I created it, I was confused by other questions and preferred to close it.

Related to this issue and this problem: should calc(1% / 1% * 1px) (or calc(1em / 1em * 1px)) be resolved to calc(1px)? I would say no because when 1% === 0px, the result is NaN * 1px. It all depends on whether relative numerics must be assumed to be resolved before resolving operations (except sums, eg. 2em - 1em can be resolved to 1em) or math functions (eg. sign(1%)).

Basically, I think products and math functions can be resolved (simplified) when they only include <percentage>s, if they do not resolve to another type (except <number>). They can not when they include relative dimensions.

@Loirooriol
Copy link
Contributor

Related: #9667

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-values-4 Current Work
Projects
None yet
Development

No branches or pull requests

3 participants