[css-typed-om-1] How does StylePropertyMap interact with CSSStyleDeclaration?

[bzbarsky]

The example in https://drafts.css-houdini.org/css-typed-om-1/#numeric-objects has:

myElement.attributeStyleMap.set("z-index", CSS.number(15.4));

After that, what does myElement.style.zIndex return? Is it 15? Something else?

This doesn't actually seem to be defined anywhere. In fact, it's not even defined that mutations to the .attributeStyleMap get reflected in .style and similar for the CSSStyleRule case.

[darrnshn]

If the .set call was valid, then the intention is that the "liveness" of the style map would cause .style to update.

In this case, I believe this would actually be invalid and throw an error. AFAIK z-index takes an <integer> and we currently don't have an algorithm for matching against an <integer> (maybe we should? @tabatkins).

[tabatkins]

We don't throw for numbers outside the supported range, so I don't know why we'd throw for non-integers on things that want an integer. We should round.

[darrnshn]

My interpretation is that z-index's grammar takes an <integer>, so we would fail at the grammar matching stage of StylePropertyMap.set (since nothing matches <integer> atm).

For numbers outside the supported range (e.g. width), we would match successfully against the grammar <length>, but technically it's invalid because the spec text for width says it's invalid (but not in the grammar?)

Not sure if my understanding is correct, but we should probably have a consistent behaviour for both cases.

[tabatkins]

Oh, hm, that's a good question. I suppose that CSS Syntax handwaves what it means to match the grammar, too; it's not clear whether range restrictions are included in that (but usually they should be, I think).

[darrnshn]

Yeah CSS handwaves it bit :/ Let's just go with #647 and just calcify both, to be consistent?