You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The serialization rules for calc() have specified for several years that, if you're serializing a computed or used value that contains a calc(), and that calc() has been simplified into a single numeric value like calc(5) or calc(20px), you should clamp it the value to the allowed range for its context and then serialize it by itself, without the calc() wrapper.
Currently, TypedOM doesn't do this - per spec, if you write "width: calc(20px);" in your stylesheet, computedStyleMap.get('width') needs to return a CSSMathSum(CSS.px(20)).
Should we change this so the reification and serialization rules match? Or is it okay to treat the serialization unwrapping as a legacy quirk?
The CSS Working Group just discussed Simplifying away calc() wrappers around single numeric values when reifying, and agreed to the following:
RESOLVED: TypedOM reifies values as simplified form (mirroring getComputedStyle etc.)
The full IRC log of that discussion
<TabAtkins> Topic: Simplifying away calc() wrappers around single numeric values when reifying
<TabAtkins> github: https://github.com//issues/968
<fantasai> TabAtkins: If serializing ? or used value of calc(), gets simplified down
<fantasai> TabAtkins: at that point, you remove the calc() wrapper if simplifies down to a single component
<fantasai> TabAtkins: This behavior doesn't happen in TypedOM
<AmeliaBR> s/?/computed/
<fantasai> TabAtkins: it retains the calc() wrapper
<fantasai> TabAtkins: not sure if we should try to adopt or not
<fantasai> TabAtkins: if particular impl concern, I don't have a strong opinion...
<fantasai> AmeliaBR: from authoring side, if you wanted to go in and manipulate the value in the wrapper and still have clamping effects of calc()
<fantasai> AmeliaBR: e.g. calc(-5px) in property that's positive values only
<fantasai> AmeliaBR: ...?
<fantasai> TabAtkins: if you set a calc() it'll get that behavior, if you set a simple numeric value it won't
<fantasai> TabAtkins: if you want to do math, can do it without having already wrapped in calc regardless
<fantasai> TabAtkins: in particular, emilio brought this up in a CSS isue
<fantasai> s/isue/issue/
<AmeliaBR> s/...?/Where the clamping value would be different with a plain -5px. Not sure how clamping would be different in TypedOM./
<fantasai> emilio: I think getComputedValue is px value because can simplify away, so I think everyone should do the same
<fantasai> emilio: would be annoying in implemntation to maintain that information
<fantasai> emilio: about whethe was wrapped in calc or not
<fantasai> TabAtkins: ok, propose to resolve that TypedOM reifies value as simplified form
<fantasai> RESOLVED: TypedOM reifies values as simplified form (mirroring getComputedStyle etc.)
<TabAtkins> <br dur=10min>
The serialization rules for calc() have specified for several years that, if you're serializing a computed or used value that contains a calc(), and that calc() has been simplified into a single numeric value like
calc(5)
orcalc(20px)
, you should clamp it the value to the allowed range for its context and then serialize it by itself, without the calc() wrapper.Currently, TypedOM doesn't do this - per spec, if you write "width: calc(20px);" in your stylesheet,
computedStyleMap.get('width')
needs to return aCSSMathSum(CSS.px(20))
.Should we change this so the reification and serialization rules match? Or is it okay to treat the serialization unwrapping as a legacy quirk?
/cc @emilio for bringing this up in w3c/csswg-drafts#1968, cc @xiaochengh as Blink's implementer of some of this stuff.
The text was updated successfully, but these errors were encountered: