- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Mar 2018 16:31:59 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?`, and agreed to the following resolutions: * `RESOLVED: Reverse the previous resolutions of this issue and keep the spec as it currently is.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Does the is2D design allow for inconsistent interpretation of CSSTransformComponents?<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/610<br> <dael> Rossen: This has been brought back week after week.<br> <dael> Rossen: This is typed OM. It's high on the agenda because it's related to transforms and it would be good to make progress. Can we discuss?<br> <dael> TabAtkins: I'm ready. My point is summerized in the thread. When trying to impl the resolution I realized it's quite problematic. We need something very different or go back to the original which was you don't pay attentio to the 3d attributes when you're set to be 2d.<br> <dael> TabAtkins: Should I go over the core issue?<br> <dael> Rossen: We had a resolution from last week [reads]<br> <dael> Rossen: That was from 3 or 4 weeks ago.<br> <dael> TabAtkins: That's not enough. Idea behind this was making things like translate.z attribute throw or ignore would be easy, but it's actually not. You have a completely separate object stored here that needs to know it's read only. Only thing easier the dom matrix is it's my spec so I can do the edits. I need a whole hierarcy so when you swap to 3d you have a read only 0px not a real 0px.<br> <dael> TabAtkins: It exposes oddness to the author and isn't particularly better then what we have.<br> <dael> Rossen: Okay.<br> <dael> TabAtkins: My first post after the minutes outlines the basic issue where I'd have to do something really weird to implement.<br> <dael> Rossen: Do you have any proposal of this weird thing?<br> <dael> TabAtkins: My preferred resolution would be void the preivious and return to the 3d are ignored if transform is set to 2d.<br> <dael> TabAtkins: That's the easiest way without a parallel hiererchy.<br> <dael> Rossen: To recap: we started with what you described. We resolved to, when you set a 3d on a 2d we throw. Then a week after we said let's not throw, just ignore it. Now we're saying nevermind let's go back to the original. Is that where we are?<br> <dael> TabAtkins: Yeah. Note that throw and do nothing distinction is very small. THe original is a substantial difference. It's difficult to impl either resolution.<br> <dael> Rossen: Since you were furthest in impl I'd like to hear if Moz or Apple have any objections.<br> <dael> TabAtkins: dbaron posted a question and I responded to him. We haven't discussed further.<br> <dael> smfr: What if we back away from maintining the special translate behavior? Anyone using hte new typed om is working on new content where they can change from the magic 0 to a will change transform which is the better way going forward. Then get rid of the is2d attribute.<br> <dael> TabAtkins: Only works if we get rid of the distinctions between 2d and 3d. If we key off of does it look planer we'll have a behavior difference when you animate and happen to pass through z=0.<br> <dael> smfr: Sounds like you'r considered the typed om to be the om and I"m thinking it's an API<br> <dael> TabAtkins: It's an API but we can't ignore 2d and 3d. When you ask what the transform is you need to indicate if it's 2d or 3d because when you set it back you might geta behavior change.<br> <dael> smfr: YOu want roundtripping to not have side effects. If you keep it to the attribute and if you set anything 3dish you remove the 2d does that work?<br> <dael> TabAtkins: Proposal we go back to is if 2d attribute is set we ignore 3d parts of it. It serializes to translate, not translate 3d etc. That's what the spec was and currenlty is since I never commited the change.<br> <dael> smfr: You're saying 2d values from any attribute you set...why not the opposite where if you set something z-ish you set the 3d attribute.<br> <dael> TabAtkins: We could...problem is the object we have to monitor is not the transform object, but it's a math value or a dom matrix.<br> <dael> TabAtkins: Wouldn't be reversable<br> <dael> smfr: Is the is2D independant fro the matrix?<br> <dael> TabAtkins: If you don't say it explicitly it will derive, but you can only flip manually.<br> <dael> smfr: I still don't see the problem with...if you say it's okay to raise the 0 thing I don't see the problem in allowing people to set a z property on a 2d matrix.<br> <dael> TabAtkins: You have a translat object that's set to 2d. You can poke it to z and set it to 5. What does transform is 2D return?<br> <dael> smfr: It would turn into a translate 3D.<br> <dael> TabAtkins: YOu're okay with that communication between nested objects?<br> <dael> smfr: It sounds okay, but there's a tear off issue<br> <dael> dbaron: That sort of communication isn't that big of a deal. You have to do that for all things in the DOM. If you use a setter it needs to reflect back to where it came from. Even if the API doesn't let you walk back the internals need to allow it.<br> <dael> TabAtkins: You can have a multi-parent relationship unlike the dom.<br> <dael> dbaron: That's an interesting point that should be called out explicitly in the spec<br> <dael> TabAtkins: We don't have detail on moving things around because they're objects.<br> <dael> myles: What's the use case of multi-parent thing?<br> <dael> TabAtkins: No particular use case, it's how JS works when you don't attach extra magic which the dom does.<br> <dael> TabAtkins: dom behavior is extra magic. JS is what everyone expects. Unless we want to attach the extra dom magic to the object we get to the JS behavior by default.<br> <dael> myles: One possible solution, I'm not suggesting it's an option<br> <dael> TabAtkins: The idea a 5px value is unique and special so you can set it in one place and not others seems very weird.<br> <myles> s/I'm not suggesting it's an option/I'm not suggesting it, but it's an option/<br> <dael> TabAtkins: Elements in the dom are unique and that makes sense. But a 5px value doesn't suggest that sort of identity. It should only rely on structural equality. We don't do that now in JS but I'd like to keep it open.<br> <dael> dbaron: The 5px value if you manipulate it via its setters it gets reflected where used.<br> <dael> TabAtkins: Only when you set it at which point you can do a tree call. There's no need to monitor all the time because it's not live. Style property maps are live as of the moment you query, but the object produced are dead and of no value until set back into property maps. That's intentional so you can use these objects multiple times and avoid object contruction costs.<br> <dael> dbaron: But the transform stuff...that's true at the lowest but not next up?<br> <dael> TabAtkins: It is. THere's no sense of a knowledge connection. What are you thinking is happening?<br> <dael> dbaron: I'm trying to think through what you said about dom matrix.<br> <dael> TabAtkins: Upon construction you pass in a dom matrix. We examine if it's 2d or 3d and decide. If you query the is2D object...there's no cross communication after you set these things.<br> <dael> Rossen: Question to dbaron and smfr. Do you have reservations to going back to the original design? Or are you trying to further where we are today. What I'm hearing and from reading hte issue I'm feeling we want to take the time to make this thing right without locking ourselves in the previous resolution. THat's a fine path forward.<br> <dael> Rossen: My question would be would that have any kind of effect on the transform spec? If not is there a reason we shouldn't resolve to revert and then move on?<br> <dael> smfr: I don' think this has baring on the transform spec. Maybe something different with dom matrix. But I thought TabAtkins wasn't happy witht he resolution. Might be easier to talk about this in Berlin. I don't have my head wrapped around hte previous proposal.<br> <dael> Rossen: GOing back to the people in the discussion, do we want to revert the current resolutions and continue working either in the F2F or in a breakout in Houdini or CSS time and make progress that way?<br> <dael> Rossen: Would that satisfy everyone?<br> <dael> ??: Works for me<br> <smfr> s/??/smfr/<br> <dael> Rossen: prop: reverse the previous resolutions of this issue and keep the spec as it currently is.<br> <dael> Rossen: Objections?<br> <dael> smfr: If this is in flux I don't know if we need to resolve anything.<br> <dael> Rossen: WE have previous resolutions.<br> <dael> smfr: Rollback I guess is okay.<br> <dael> RESOLVED: Reverse the previous resolutions of this issue and keep the spec as it currently is.<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-373087235 using your GitHub account
Received on Wednesday, 14 March 2018 16:32:12 UTC