[css-typed-om] What does lack of range restriction imply about serialization?

[dbaron]

The section on CSSNumericValue says:

CSSNumericValue objects are not range-restricted. Any valid numeric value can be represented by a CSSNumericValue, and that value will not be clamped, rounded, or rejected when set on a declared StylePropertyMap or inline StylePropertyMap. Instead, clamping and/or rounding will occur during computation of style.

(It then proceeds to give an example demonstrating this.)

What this doesn't seem to address is what implications this has for CSS's existing object model APIs that involve serialization. It's long been a principle of these APIs that they always give output that is valid CSS. This means that, for example, getting element.style.cssText, modifying it, and setting it back to element.style.cssText should change only the thing that was modified. Likewise for getPropertyValue and setProperty, or the element.style.propertyName that is equivalent to them. However, the rules for these setters require following the rules of CSS parsing and dropping any declarations that are not valid. This means that serializing things that don't round-trip correctly would break anything that depends on this round-tripping.

It seem like there are a bunch of bad options here (listed in the order that seems best to worst to me at first glance, although I'm sure I'm missing many considerations):

• serialize CSSUnitValue that are out-of-range as calc() expressions
• not do the thing quoted above, but instead do rejection of CSSNumericValues when they're set in some cases
• serialize all CSSUnitValue as calc() expressions
• break round-tripping as the spec currently does

I tried to look through the spec to see if one of these options was specified later, but I didn't see anything. If there is something I missed, it would be good to have a pointer to it from this section.

It's also entirely possible that the WG has discussed this and I've forgotten (or missed it).

[tabatkins]

We have not discussed this, but I think serializing out-of-range values as calc() makes the most sense.

[tabatkins]

(That said, I think this thus ends up being a CSSOM issue, not a TypedOM issue; this spec is the source of the bad values, which previously couldn't occur due to being rejected at parse time, but CSSOM is the source of the stringification.)

[dbaron]

(BTW, I think this is the most interesting of the issues I raised from a high-level or architectural perspective.)

[tabatkins]

It's definitely an interesting issue, but do you agree that it's a CSSOM issue?

(Serialization of actual TypedOM objects is defined completely independently of what property they appear in; it's only CSSOM that serializes values in the context of a property, where it's possible for them to be invalid.)

[dbaron]

I think which spec it's an issue on depends on which solution we end up with...

I think this is a substantive enough issue that it's probably worth bringing to the working group, although we might want some preparation in advance of that discussion.

[nainar]

@atanassov just making sure you know we want to add this to the agenda for the next APAC friendly CSSWG call as well

[css-meeting-bot]

The Working Group just discussed [css-typed-om] What does lack of range restriction imply about serialization?, and agreed to the following resolutions:

• RESOLVED: typed OM values are wrapped in calc and then serialized as normal calc rules

The full IRC log of that discussion

<dael> Topic: [css-typed-om] What does lack of range restriction imply about serialization?
<dael> github: https://github.com//issues/574
<dael> TabAtkins: David raised an issue we hadn't thought of. typed om allows certain values to enter absteract css value space. Specifically thigns that are invalid based on grammar. Like a width can't be negative value. It's rejected at parse time
<dael> TabAtkins: In typed om we say you can cocnstruct a numeric value that's negative and assign it to width and that's not invalid. That has implications on how to serialize based on old string based. getComputedStyle.width() what do you get?
<dael> TabAtkins: I believe this is an issue for cssom to define, though typed om caused it.
<dael> dbaron: It's more relevent to other serialization. Of specified style not computed.
<dael> TabAtkins: Yeah.
<dael> TabAtkins: So if you set attribute style map width to negative and ask for .style.width what do you get?
<dael> TabAtkins: I am weakly of the opinion we should serialize as calc, but I don't have a strong opinion and can go with easiest for impl.
<dael> xidorn: Can we do something like if we assign we wrap in a calc directly?
<dael> TabAtkins: Very possible. You're saying we turn it into a calc in css value space immediately so when you read it back out you'd get a calc or a match sum with a -5px. Right?
<dael> xidorn: Yeah.
<dael> TabAtkins: That would also be fine with me.
<TabAtkins> s/match sum/CSSMathSum/
<dael> Rossen_: In your current impl do you do anything at all? In your current version you'll serialize negative?
<dael> TabAtkins: I have no idea.
<dael> Rossen_: I know you guys are ahead of impl.
<dael> TabAtkins: But not publically available. I think we do -5px and it's invalid but we're not attached to that.
<dael> Rossen_: I was just wondering if someone did something close to what xidorn suggested.
<TabAtkins> (That's Darren Shen, our Typed Om implementor.)
<dael> ??: I'm doing Blink and I think currently we might reject the value, but I'm not sure. We have to check.
<dael> TabAtkins: That's violating another part of the spec that's more explicit.
<nainar> s/??/shend
<nainar> Darren Shen, Google isn't on IRC
<dael> Rossen_: Sounds like options are we wrap values in calc if they're not alread a calc and let calc work as does today.
<dael> Rossen_: That sounds good to me. Doesn't require much custom code to handle this and it will be fairly easy to understand and teach to anyone that's used calc. I'd be good with that one.
<dael> TabAtkins: sgtm
<dael> Rossen_: dbaron what do you think?
<dael> dbaron: I'm fine with it. Is the plan to do what xidorn desc?
<dael> Rossen_: Yeah.
<dael> TabAtkins: Alt the notion that when you pull it out if it's invalid at that point. it gets calc wrapped at that point.
<dael> dbaron: xidorn's eager thing sounds easier. Might be worth a note asking for impl feedback.
<dael> TabAtkins: Sure.
<dael> Rossen_: Seems like we're leaning toward spec as xidorn proposed wrapping a calc.
<dael> Rossen_: Other options or obj?
<dael> RESOLVED: typed OM values are wrapped in calc and then serialized as normal calc rules
<Rossen_> s/RESOLVED: typed OM values are wrapped in calc and then serialized as normal calc rules/RESOLVED: typed OM values are wrapped in calc and then serialized as normal calc rules apply in invalid cases/