Re: [css-houdini-drafts] [css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?

The Working Group just discussed `[css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?`, and agreed to the following resolutions:

* `RESOLVED: attempting to set any 3d attribute on a 2d transform will throw`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-typed-om] Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?<br>
&lt;dael> github: https://github.com/w3c/css-houdini-drafts/issues/610<br>
&lt;dael> TabAtkins: The issue is that there's a lot of diff ways we could represent 2d vs 3d split in transform functions. We settled on all are combined to a single form so expose the same api.<br>
&lt;dael> TabAtkins: There's additionally a is 2d boolean flag. It's set true or false and set via constructuor but you can set yourself.<br>
&lt;dael> TabAtkins: dbaron complaint is you can still set hte z value to something. If is 2d is set it'll searlize and the z axis does nothing. It seems weird, but we decided that's the way to do it.<br>
&lt;dael> TabAtkins: alt we could blank out the values in 3d when you set the bool to true and fill them with null-ish things.<br>
&lt;AmeliaBR> +1 for making is2D = true make the z/w columns and rows force to the identity matrix values<br>
&lt;dael> TabAtkins: more extreme is to split into 2 interfaces, but we didn't want that because you can't write generic transform code.<br>
&lt;dael> TabAtkins: Question is, is the current design choice where z value is ignored but can be set fine or should we go for a different design where we replacec with a null and ignore sets.<br>
&lt;dael> dbaron: I'd add one options is ignore set and the other is throw.<br>
&lt;dael> TabAtkins: Yes, sure. I had put them together because they're similar in my mind.<br>
&lt;dael> Rossen_: Is there impl experience in this area?<br>
&lt;dael> shend: Yes.<br>
&lt;AmeliaBR> +1 specifically for the ignore option; consistent with how bad values are treated in most of the rest of CSS<br>
&lt;dael> Rossen_: Other opinions on this?<br>
&lt;dael> dbaron: I don't know if my opinion was clear, but I'm not happy with what's in the spec. I prefer ignore or throw with a slight prefernce for throw.  I think AmeliaBR said she pref ignore.<br>
&lt;dael> dbaron: I think throw because it's a bit more like if you have an object that's just the 2d thing, but really you'd set an extendo property so maybe ignore is the right analog.<br>
&lt;dbaron> s/extendo/expando/<br>
&lt;dael> TabAtkins: I wouldn't treat js syntax as being nececssarily informative here. We throw eagerly in other placec sin the OM when something is wrong.<br>
&lt;dbaron> s/I think AmeliaBR said/AmeliaBR said on IRC/<br>
&lt;dael> Rossen_: I think throwing would be a little easier to surface up to devs and tools. It would give a little more ability for those trying to use typed OM to fix their code. So I htink I'm with dbaron to prefer throwing or at least throw by spec it throws.  If it's a pain point we can fall back to ignore.<br>
&lt;dael> TabAtkins: I'm fine with that.<br>
&lt;dael> smfr: Would you throw when you assign any values to z or any that makes it 3d?<br>
&lt;dael> TabAtkins: Any value because any value makes it 3d when it's 3d. A 0 value in 3d doesn't make it not 3d.<br>
&lt;dael> smfr: So the 2d rep it will serialize as 2d transform.<br>
&lt;dael> TabAtkins: Yes.<br>
&lt;dael> smfr: I could go throw or ignore.<br>
&lt;dael> TabAtkins: I'm fine with throw.<br>
&lt;dael> Rossen_: Obj on throwing in cases when z index is spec on 2d transforms?<br>
&lt;dael> TabAtkins: When you try and set any 3d related attribute of a transform set in 2d<br>
&lt;dael> smfr: Will you annotate 3d attr somehow?<br>
&lt;dael> TabAtkins: Yes.<br>
&lt;dael> TabAtkins: I'll have explicit setters for those attributes.<br>
&lt;dael> RESOLVED: attempting to set any 3d attribute on a 2d transform will throw<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/610#issuecomment-363959406 using your GitHub account

Received on Thursday, 8 February 2018 00:24:43 UTC