[css-typed-om] Calc representation not compatible with Custom Properties + var()

[FremyCompany]

The current proposal https://lists.w3.org/Archives/Public/public-houdini/2015Aug/0004.html cannot accurately represent things like:

width: calc(var(--a) * var(--b));
--a: 3;
--b: 5px;

I think the TypedOM proposal is stuck somewhere between the specified and the computed style. Both need a possibly different OM, even if converting from the latter one to the first one is trivial and should be natively supported by the API.

Under this proposal, the Computed.CalcPercentLength would only contain "px" and "percent", while the Specified.CalcPercentLength would contain something more abstract which can contains additions, products, etc... We could allow user agents to simplify those calculations to pixels and percentages when it is possible to do so without impacting the result (calc(3px + 3cm) could be memorized as calc(158px)).

Anyway, this needs further thought.

[EDIT] Another option would be to support only the ComputedValue Typed OM and have one extra value ({value:string}) which would be returned for specified styles which cannot accurately be converted to a value of the ComputedValue Typed OM. Or we could just disallow this entirely and mark the specified style write-only.

[tabatkins]

On Mon, Sep 14, 2015 at 8:55 AM, François REMY notifications@github.com wrote:

The current proposal https://lists.w3.org/Archives/Public/public-houdini/2015Aug/0004.html cannot accurately represent things like:

width: calc(var(--a) * var(--b));
--a: 3;
--b: 5px;

This is nothing to do with calc(). Any use of var() in a property
removes our ability to present that property in a typed OM until the
var() is resolved. Properties with an unresolved var() must instead
be presented as a simple token stream or string; this isn't yet
reflected in the draft.

I think the TypedOM proposal is stuck somewhere between the specified and the computed style. Both need a possibly different OM, even if converting from the latter one to the first one is trivial and should be natively supported by the API.

No, they don't need different OMs. Sometimes properties are just
represented differently based on the value computation phase you're
querying them from. For example, "width: calc(1px + 2em)" returns a
CalcLength for specified style, but a SimpleLength for computed style.
Nothing strange here.

~TJ

[FremyCompany]

This is nothing to do with calc(). Any use of var() in a property
removes our ability to present that property in a typed OM until the
var() is resolved.

Oooh, I see what you meant now. I see how this doesn't only apply on "calc(...)" which makes any "calc(...)"-specific fix moot.

So, what we seem to agree on is something along the lines of a "special" value for things which cannot be represented as a parsed value yet, for instance if it includes "var" (either a string, or a token stream if we take a dependency on CSS Parser). I'm fine with this, is that what you proposed too?

NOTE: We may have to think about "attr(...)" too.

[tabatkins]

I'm fine with this, is that what you proposed too?

That's exactly what I said, so yes. ^_^

NOTE: We may have to think about "attr(...)" too.

Good point. And toggle(), and any other functions which can represent simple types.

[shans]

For now these and other unsupported values are going to be represented by UnsupportedStyleValue objects. We'll get more sophisticated later.

[shans]

Actually we're going introduce a TokenStreamValue which will capture these.

[FremyCompany]

👍

[shans]

Added in #169