Bug 255280 – CSS bug: Support division/multiplication of mixed units

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Brandon McConnell]

# Summary:
When dividing a length by another length, the CSS parser in the browser should return a number as specified in the `css-values-4` spec. However, this functionality is not yet implemented and instead throws an error or produces an unexpected result.

# Steps to Reproduce:
1. Create a CSS file with the following rule:
```css
div {
  width: 200px / 20px;
}
```
2. Link the CSS file to an HTML file with a `div` element.
3. Open the HTML file in the browser.

### Expected Results:
The `div` element should have a `width` of `10` since `200px / 20px` equals `10`.

### Actual Results:
The `div` element either does not have a `width` set or has an unexpected value such as `NaN` or an error message is thrown.

# Environment:
- Browser: [insert browser name and version]
- Operating System: [insert operating system name and version]

# Additional Information:
- The `css-values-4` spec specifies that multiplication and division are no longer restricted to specific argument types and can produce complex intermediate results. This change in functionality should be implemented in the browser's CSS parser.
- The lack of this functionality can lead to unexpected behavior in web pages and hinder the ability of developers to create responsive designs.
- This issue affects all web pages that use division of lengths in CSS rules.
- This issue can be worked around by manually calculating the result of the division and using that value instead of the division operation. However, this is not ideal and can lead to less readable and maintainable code.

# Related resources and discussions
- Discussion: https://github.com/w3c/csswg-drafts/issues/7448
- Specification: https://drafts.csswg.org/css-values/#calc-type-checking
  > NOTE: In previous versions of this specification, multiplication and division were limited in what arguments they could take, to avoid producing more complex intermediate results (such as 1px * 1em, which is <length>²) and to make division-by-zero detectable at parse time. This version now relaxes those restrictions.

[Brandon McConnell]

For transparency across bug fix implementations/discussions across browser engines:
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=255280
- Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1827404
- Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1432187

[Brandon McConnell]

** One addtl important note— My `200px / 20px` example above uses `px / px`, but imperatively, this should support mixed units as well, so someone should be able to do `100% / 20px` (`% / px`, etc.) to get a number representing how many times the second number fits into the first expression, such as how many times `20px` fits into `100%` of the currently evaluated dimension.

[Brandon McConnell]

Here is a minimal example of this bug:
https://codepen.io/brandonmcconnell/pen/OJByEBO/126b86e86107bda0133813141da9108e

The screen appears red, because of this rule:

```css
main {
  width: 100vw;
  height: 100vh;
  background-color: red;
}
```

However, it should appear blue, due to this style:

```css
main > div {
  width: calc(100% / 20px * 20px);
  height: calc(100% / 20px * 20px);
  background-color: blue;
}
```

The `/ 20px * 20px` should naturally cancel each other out, making those values `100%` once again. This is per the current `css-values-4` spec.

This can also be used, for example, to determine how many times a static number like `25px` fits into a dynamic size like `100vh` and then store that number for use anywhere the number type is accepted.

This will be especially useful once `round()` is implemented (via [#1407473](https://bugs.chromium.org/p/chromium/issues/detail?id=1407473)).

[Radar WebKit Bug Importer]

<rdar://problem/108195400>

[Brandon McConnell]

Any update here? This is essential for many foundational computations in CSS.

[Tim Nguyen (:ntim)]

This looks easy at the surface, but https://github.com/w3c/csswg-drafts/issues/8169 shows some examples where this is not trivial to do.

[Ahmad Saleem]

> https://codepen.io/brandonmcconnell/pen/OJByEBO/126b86e86107bda0133813141da9108e

It seems to show 'blue' now on WebKit ToT (282636@main).

It would've been fixed by calc work done by Sam.

I think we can close this. @Sam & @Tim - any thoughts?

[Sam Weinig]

Yep, this can be closed now. Thanks!

[Brandon McConnell]

Are all related WPT tests passing?

[Sam Weinig]

(In reply to Brandon McConnell from comment #9)
> Are all related WPT tests passing?

I believe so. Do you know of any that are not?

[Tim Nguyen (:ntim)]

*** This bug has been marked as a duplicate of bug 278244 ***

[Brandon McConnell]

Yes, see the related tests can be seen here:
https://wpt.fyi/results/css/css-values?label=pr_head&max-count=1&pr=42517


I spec'd them here:
https://github.com/web-platform-tests/wpt/pull/42517

[Brandon McConnell]

@:ntim Bug 278244 should be marked as a duplicate of this bug, as this bug report is older and contains more context and historical research.

[Tim Nguyen (:ntim)]

While I agree there's more context on this bug, the engineering work landed in bug 278244. 

It's confusing for tracking purposes for a bug with engineering changes to marked as duplicate.

*** This bug has been marked as a duplicate of bug 278244 ***

[Tim Nguyen (:ntim)]

The other option is to mark this bug as "RESOLVED CONFIGURATION CHANGED", I don't have a strong opinion, but this bug's status is "RESOLVED" either way.

[Tim Nguyen (:ntim)]

This is in STP 203 btw: https://webkit.org/blog/15860/release-notes-for-safari-technology-preview-203/

[Brandon McConnell]

It’s in STP but still incomplete. I’ll leave my comment in the other ticket. Thanks!