- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Sun, 01 Jul 2018 23:40:57 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Observer for property being applied?`, and agreed to the following: * `RESOLVED: Add custom property observers to L1 of Properties and Values` <details><summary>The full IRC log of that discussion</summary> <dbaron> Topic: Observer for property being applied?<br> <dbaron> github: https://github.com/w3c/css-houdini-drafts/issues/555<br> <heycam> TabAtkins: this has been something we're aiming for at some point<br> <heycam> ... you want to be able to observer when and where a given custom property is put on an element<br> <heycam> ... right now the best you can do, is you can do some processing on a custom prop, tell what grammar it's meant to have<br> <heycam> ... you can't say that for every element with this property, do this JS<br> <heycam> ... only way right now is to walk the tree and ask the style for every element, not great to do in a tight loop<br> <heycam> ... we already have things like this<br> <heycam> ... you can use the transition events to get at this<br> <heycam> ... but that's hacky, clearly<br> <heycam> s/you can use/xidorn pointed out you can use/<br> <heycam> ... we're planning on this for level 2<br> <heycam> ... at minimum, to observer specified values<br> <heycam> ... and older proposal shunted out is for computed value hooks, don't know if we want to do that immediately<br> <heycam> ... we have to define in more detail how that interacts with animations and transitions, which is complicated<br> <heycam> ... so at least getting the specified value out of things is probably worthwhile<br> <heycam> ... so we could put it in this level, or wait to the next level<br> <heycam> iank_: this would only be useful for non inherited properties<br> <heycam> ... otherwise you are going to walk the whole tree anyway, because everything is ...<br> <heycam> TabAtkins: you would only do it for everything that doesn't have the initial value<br> <heycam> shane: unless, like observers, they're applied prer element<br> <heycam> ... in which case the inheritance doesn't matter<br> <heycam> iank_: I think the use case is that you want to do some computation ...<br> <heycam> shane: here's an example from a script that does this<br> <heycam> ... a bunch of things they need extra JS for<br> <TabAtkins> http://endtwist.github.io/kerning.js/<br> <heycam> TabAtkins: so I think it will be find on specified values for now<br> <heycam> s/shane: here's an example/TabAtkins: here's an example/<br> <heycam> iank_: we're getting someone ramped up to finish teh P&V implementation<br> <heycam> ... ahd it landed behind a flag for 18 months now<br> <heycam> ... getting it finished off next quarter<br> <heycam> ... given the number of cool demos, shipping it before Christmas<br> <heycam> Rossen: end of 2018<br> <heycam> iank_: probably earlier<br> <heycam> Rossen: the reason I'm asking, is the current proposed feature for Level 1, that's fine, it's still a WD<br> <heycam> ... so I'm curious whether you're pressing to start shipping, we might need to start stabilizing this spec<br> <heycam> Rossen: with that said, I think it's still worthwhile to take this in L1 and see if we can make progress<br> <fantasai> TabAtkins: Anyone else have implementation?<br> <fantasai> heycam: We have half an impl, might pick up again in Q4 but probably not ready to ship in Q4<br> <heycam> TabAtkins: I'm going to fill in the parser section on how to parse a grammar string<br> <heycam> ... obvious but handwavy<br> <heycam> ... I have a lot of edits to apply to the spec<br> <heycam> Rossen: for this particular issue, we are resolving to have the observer for custom properties in L1, see how it goes<br> <heycam> ... concerns or objections?<br> <heycam> fantasai: I would say mark it as risk, I know we're not in CR now<br> <heycam> Rossen: we can do it once we get closer to CR<br> <heycam> dbaron: one other comment is, I think this is at a stage where it's ok to be adding new features, as long as they're reasonably solidly specified off the bat<br> <heycam> ... so I think it's ok to add this if the text gets written relatively soonish and gets reviewed relatively soonish<br> <fantasai> +1 to dbaron<br> <heycam> TabAtkins: I can promise to have the text written, and do as many other edits as I can, by the end of this meonth<br> <heycam> fantasai: stabilizing for CR takes time, we don't want freshly added text that is shaky<br> <heycam> dino: the way this spec is now, it allows you to specify a way to interpolate custom props<br> <heycam> iank_: you can define it to be non inherited<br> <heycam> ... and also give it an initial value<br> <heycam> TabAtkins: and a level of grammar checking<br> <heycam> dino: parse errors<br> <heycam> TabAtkins: yes<br> <heycam> iank_: a lot of demos atm are using it for animation, Ana Tudor has a bunch<br> <heycam> ... that's probably the biggest value as a standalone spec<br> <heycam> TabAtkins: this feature will be a huge uptick in use cases, when you can tell what elements have that element applied<br> <heycam> TabAtkins: so you think it should go in L1 to increase the value of the spec<br> <heycam> dino: I'm not necessarily saying that<br> <heycam> ... but I'm fine with it<br> <heycam> philipwalton: do we have any other observers?<br> <heycam> ... are we thinking too small just looking at custom properties?<br> <heycam> TabAtkins: possibly<br> <heycam> ... the API shape that's in my head right now can definitely work with any property, just a string name<br> <heycam> ... only defined it for custom properties at the moment, but no objection to widining it if there's reasonably use cases and implementation issues<br> <heycam> ... I know we handle custom props a bit differently from regular props<br> <heycam> ... if you have use cases, please put it into the issue<br> <heycam> philipwalton: I think a lot of these use cases would be handled by calc() on the property<br> <iank_> Ana Tudor demo: https://codepen.io/thebabydino/pen/MrZvNm (chrome canary + flag)<br> <heycam> dino: might be nice to put more examples in, beyond animations<br> <heycam> ... parse errors, non-inheriting, ...<br> <heycam> TabAtkins: definitely<br> <heycam> iank_: [demos]<br> <heycam> dino: so she's registering custom props for height, shadow, width, ...<br> <heycam> iank_: specifying things as angles, numbers<br> <heycam> ... and then she's plumbing them into a huge transform effectively<br> <heycam> ... so you can see scale affects fy, ...<br> <heycam> ... all driven by one big transform, but animating different parts of the animation separately<br> <heycam> ... and then setting a bumnch of animations on it<br> <heycam> TabAtkins: it's being driven by one big transform prop, but indepednent animations on bits of it<br> <heycam> TabAtkins: this is a one element demo<br> <heycam> ericwilligers: this is one of the motivations for the separate translate/scale/... props<br> <heycam> frremy: she also has a demo animating gradients<br> <heycam> TabAtkins: several examples of gradient animation<br> <heycam> RESOLVED: Add custom property observers to L1 of Properties and Values<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/555#issuecomment-401641201 using your GitHub account
Received on Sunday, 1 July 2018 23:41:02 UTC