- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Sep 2019 02:07:03 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `perf concerns of custom properties`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: perf concerns of custom properties<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/940<br> <iank_> smfr: One if the issues w/ this being a JS api, is that there isn't a good time to register the properties.<br> <iank_> smfr: e.g. stylesheet loads, prop registered, need to recalc stylesheet potentially.<br> <iank_> smfr: Similar to style recalc thrashing.<br> <iank_> smfr: Has been a proposal for a declarative version of registered custom properties.<br> <heycam> q+<br> <iank_> TabAtkins: It seems like you have the same issues, e.g. if the properties come later in a sheet, or a later style sheet.<br> <heycam> q-<br> <iank_> smfr: B/c you only have to parse the properties once. And it'll come in a "batch."<br> <iank_> dino: You could imagine a bunch of component libs, which each register a custom properties.<br> <iank_> dino: If delcarative, they come all at once.<br> <iank_> TabAtkins: How is this different to JS setting this to something different each time?<br> <iank_> TabAtkins: You need to rerun all the style on the root.<br> <iank_> smfr: It depends how much work you need to do if the type changes.<br> <iank_> TabAtkins: If you have an untyped its still the same.<br> <iank_> TabAtkins: If its still the same, is there much of a concern still?<br> <iank_> smfr: We should try not to add new APIs let authors pull trigger for a performance cliff.<br> <iank_> TabAtkins: Would we get everything from the declarative appraoch, yes at the moment, but future levels, e.g. hooks, then no.<br> <iank_> smfr: Can we just to declar version atm?<br> <iank_> TabAtkins: As they are equiv. in power. But would be in favour if rewriting the spec to make the declarative version much more promiment.<br> <iank_> dino: In the spec if it calls out - most optimal way to declare all of them at top, then use them. And explain in the spec to do this.<br> <iank_> smfr: Also call out how to correctly use the JS api.<br> <iank_> majidvp: In JS api, you only need to do this if you trigger style reclac.<br> <iank_> emilio: Did agree that JS -reg properties, @property do not conflict. JS API won't throw.<br> <iank_> TabAtkins: That's in the pending edits.<br> <iank_> TabAtkins: JS stuff is on a separate layer.<br> <iank_> dino: What would happen? Ignored?<br> <iank_> TabAtkins: JS api wins. Treated as the "last" one.<br> <iank_> dino: If browser only supports JS version, nothing special.<br> <iank_> smfr: I have another thing related to animating untyped custom properties.<br> <smfr> https://codepen.io/smfr/pen/JjPerWw<br> <iank_> smfr: Question is - to do animation of untyped animated propeties, do you need to rerun the style-recalc each frame?<br> <iank_> TabAtkins: No, it flips 1/2 way through the animation.<br> <iank_> TabAtkins: All unreg. custom props are discreet.<br> <iank_> smfr: ok<br> <iank_> fremy: If you animate the custom property, and use it in another property which animates?<br> <iank_> emilio: Everyone is different (only FF gets it right?)<br> <iank_> TabAtkins: We discussed this years ago, there are like 16 options.<br> <iank_> dbaron: 6.<br> <iank_> TabAtkins: There were sub-options.<br> <iank_> majidvp: What happens when you reg. a type for that custom prop while animationing.<br> <iank_> TabAtkins: Just changes the value of the custom prop.<br> <iank_> TabAtkins: If that's unclear, happy to add somethign.<br> <iank_> heycam: Thats different to when you change font-size?<br> <iank_> TabAtkins: Yes - it changes the value of the property, e.g. from a token-stream to a <length><br> <iank_> heycam: In web-anim is it possible to change the from value.<br> <iank_> TabAtkins: I believe it kicks off a new transition. Not entirely clear how this works.<br> <iank_> majidvp: web-anim for the duration of the animation, when you start the animtion the curve is computed, but transitions are different.<br> <iank_> TabAtkins: Sounds like it answers the relevant questions \o/<br> <iank_> smfr: Can we talk about the status?<br> <iank_> smfr: Hesitant to implement all the syntaxes.<br> <iank_> TabAtkins: Isn't that what we do right now?<br> <iank_> TabAtkins: A handful of primitive types, w/ + and *<br> <iank_> smfr: I thought it was more that that?<br> <iank_> TabAtkins: No there isn't the possibility for needing to decide what part of the syntax to match.<br> <iank_> TabAtkins: 3.1 describes all that you can do.<br> <iank_> TabAtkins: thing+ | other-thing+ etc,<br> <iank_> <br type="morning-tea" length="30m"><br> <majidvp> github: https://github.com/w3c/css-houdini-drafts/issues/945<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/940<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/940#issuecomment-533373807 using your GitHub account
Received on Friday, 20 September 2019 02:07:05 UTC