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

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-typed-om] What does lack of range restriction imply about serialization?<br>
&lt;dael> github: https://github.com/w3c/css-houdini-drafts/issues/574<br>
&lt;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<br>
&lt;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?<br>
&lt;dael> TabAtkins: I believe this is an issue for cssom to define, though typed om caused it.<br>
&lt;dael> dbaron: It's more relevent to other serialization. Of specified style not computed.<br>
&lt;dael> TabAtkins: Yeah.<br>
&lt;dael> TabAtkins: So if you set attribute style map width to negative and ask for .style.width what do you get?<br>
&lt;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.<br>
&lt;dael> xidorn: Can we do something like if we assign we wrap in a calc directly?<br>
&lt;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?<br>
&lt;dael> xidorn: Yeah.<br>
&lt;dael> TabAtkins: That would also be fine with me.<br>
&lt;TabAtkins> s/match sum/CSSMathSum/<br>
&lt;dael> Rossen_: In your current impl do you do anything at all? In your current version you'll serialize negative?<br>
&lt;dael> TabAtkins: I have no idea.<br>
&lt;dael> Rossen_: I know you guys are ahead of impl.<br>
&lt;dael> TabAtkins: But not publically available. I think we do -5px and it's invalid but we're not attached to that.<br>
&lt;dael> Rossen_: I was just wondering if someone did something close to what xidorn suggested.<br>
&lt;TabAtkins> (That's Darren Shen, our Typed Om implementor.)<br>
&lt;dael> ??: I'm doing Blink and I think currently we might reject the value, but I'm not sure. We have to check.<br>
&lt;dael> TabAtkins: That's violating another part of the spec that's more explicit.<br>
&lt;nainar> s/??/shend<br>
&lt;nainar> Darren Shen, Google isn't on IRC<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael> TabAtkins: sgtm<br>
&lt;dael> Rossen_: dbaron what do you think?<br>
&lt;dael> dbaron: I'm fine with it. Is the plan to do what xidorn desc?<br>
&lt;dael> Rossen_: Yeah.<br>
&lt;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.<br>
&lt;dael> dbaron: xidorn's eager thing sounds easier. Might be worth a note asking for impl feedback.<br>
&lt;dael> TabAtkins: Sure.<br>
&lt;dael> Rossen_: Seems like we're leaning toward spec as xidorn proposed wrapping a calc.<br>
&lt;dael> Rossen_: Other options or obj?<br>
&lt;dael> RESOLVED: typed OM values are wrapped in calc and then serialized as normal calc rules<br>
&lt;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/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/574#issuecomment-363957637 using your GitHub account

Received on Thursday, 8 February 2018 00:15:37 UTC