stylo: Stylo simplifies calc() expressions, Gecko doesn't.

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
P2
normal
4 months ago
a month ago

People

(Reporter: emilio, Unassigned)

Tracking

(Blocks: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 months ago
See https://github.com/servo/servo/pull/16144#issuecomment-289310428, Servo seems to be correct per the CSS values spec as of right now.

> To serialize a calc() value:
>   Simplify the expression by:
>     Replacing nested calc() values with parentheses containing their contents
>     Resolving all multiplications and divisions
>     Combining identical units
>
>   The result must be a summation of unique units. (Terms with a value of zero
>   must be preserved in this summation.)
>
>   If this simplification process results in only a single value (one <number>,
>   one <dimension>, or one <percentage>), and the value being serialized is a
>   computed value or later, serialize it just as that one value, without the
>   calc() wrapper. If this value is outside the allowed range for the context,
>   it must be clamped to the nearest allowed value.
>
>   Otherwise, serialize as a calc() containing the summation, with the units
>   ordered ASCII case-insensitive alphabetically, the number (if present)
>   coming before all units, and the percentage (if present) coming after all
>   units.

Simple test:

<!doctype html>
<div style="line-height: calc(1px + 2px);"></div>
<script>
  alert(document.querySelector('div').style.lineHeight);
</script>

Blink and Stylo alert "calc(3px)", Gecko alerts "calc(1px + 2px)".

With integers is funnier:

<!doctype html>
<div style="line-height: calc(1 + 2);"></div>
<script>
  alert(document.querySelector('div').style.lineHeight);
</script>

Blink: 3
Stylo (before that PR): 3
Stylo (after that PR): calc(3)
Gecko: calc(1 + 2)

I believe we want to go with that PR and file a bug against chromium.
I have some patches for bug 1350069 that makes Gecko behave more like
Blink for <integer> and <number> calc() expressions.  So "calc(1 + 2)"
would compute to "3".

I believe the spec allows for this behavior, with some restrictions:
https://drafts.csswg.org/css-values/#calc-computed-value
(Reporter)

Comment 2

4 months ago
(In reply to Mats Palmgren (:mats) from comment #1)
> I believe the spec allows for this behavior, with some restrictions:
> https://drafts.csswg.org/css-values/#calc-computed-value

I don't think it allows for that in the test case I'm mentioning, given element.style.lineHeight is a specified value, not a computed value, right?

> If this simplification process results in only a single value (one <number>, one <dimension>, or one <percentage>), and the value being serialized is a computed value or later, serialize it just as that one value, without the calc() wrapper. If this value is outside the allowed range for the context, it must be clamped to the nearest allowed value.

In particular, note the _and the value being serialized is a computed value or later_. Otherwise, we should go to the next step, which would be:

> Otherwise, serialize as a calc() containing the summation, with the units ordered ASCII case-insensitive alphabetically, the number (if present) coming before all units, and the percentage (if present) coming after all units.

(Which would produce "calc(3)" if I understood it correctly).
Right, in your case it's bullet 3 that applies.  For a computed value, I think
it's bullet 2, i.e. "without the calc() wrapper".  (I was only talking about
computed values, sorry for the confusion.)
Hmm, I just tested your case with my gecko patches:
<div style="initial-letter: calc(1 + 1)"><x></x></div>
<script>
  alert(document.querySelector('div').style.initialLetter);
</script>

results in "2", fwiw.
Probably doesn't impact that many tests or pages, but may require spec or alignment work, so p2.
Priority: -- → P2
Blocks: 1243581
(Reporter)

Updated

2 months ago
See Also: → bug 1296209, bug 1350069
Blocks: 1376206
You need to log in before you can comment on or make changes to this bug.