Re: [css-houdini-drafts] [css-layout-api] Assorted TAG feedback

The Houdini Task Force just discussed `layoutNextFragment`.

<details><summary>The full IRC log of that discussion</summary>
&lt;iank_> topic: layoutNextFragment<br>
&lt;emilio> github: https://github.com/w3c/css-houdini-drafts/issues/760<br>
&lt;emilio> iank_: so we previously resolved to keep layoutNextFragment, but the more I use it it feels very long<br>
&lt;emilio> iank_: so I want to rename to layout<br>
&lt;emilio> iank_: so this LayoutChild.layoutNextFragment will become just layout, which also matches the callback name<br>
&lt;emilio> dbaron: I guess I think short names are good. I'm also a little hesitant about making people less aware of fragmentation. But I suppose that in many cases you don't fragment, so as long as when you do what happens is documented it's ok<br>
&lt;emilio> Rossen: initially in the early stages of houdini we thought that this was mostly for middleware / framework authors and they need to understand it and that's why we chose to be consistent with layoutNextFragment<br>
&lt;emilio> Rossen: I'm leaning about keeping it, but I won't object to renaming it<br>
&lt;emilio> Rossen: so you haven't made any of the changes yet<br>
&lt;emilio> iank_: nope, one other option is to rename this to layoutFragment and rename the callback to layoutFragment, which is a bit clearer and shorter<br>
&lt;emilio> Rossen: and layoutFragment will be important when you start doing inline layout<br>
&lt;emilio> Rossen: so you wanted to revisit it based on feedback you got, you haven't made the changes yet, so the options is renaming layoutNextFragment to layout, or changing both the callback and the idl to layoutFragment<br>
&lt;emilio> Rossen: thughts?<br>
&lt;emilio> surma: I lean to have the same name for both<br>
&lt;bkardell_> q+<br>
&lt;emilio> Rossen: oh sure, if we don't communicate that fragmentation can and will happen people won't care<br>
&lt;bkardell_> ?+<br>
&lt;emilio> iank_: third proposal is layoutNextFragment for both of them<br>
&lt;emilio> heycam: I'm not actually super-sure about the symmetry since it seems like calling into layoutFragment to your child would call directly into the callback, but that's not what it's happening right?<br>
&lt;emilio> iank_: right, though we have that symmetry for inline sizing<br>
&lt;Rossen> q?<br>
&lt;Rossen> q?<br>
&lt;emilio> cbiesinger: I think I really like layoutNextFragment, it's clearer<br>
&lt;Rossen> q?<br>
&lt;fantasai> s/clearer/clearer that there might be more than one/<br>
&lt;fantasai> +1 to cbiesinger<br>
&lt;Rossen> q?<br>
&lt;cbiesinger> s/inline sizing/intrinsic sizing/<br>
&lt;emilio> Rossen: I think first choice... do we want to insist for symmetry and keeping the same name? Since it's not really the same, so there needs not to be a symmetry between the two, which then leaves the question of just renaming layoutNextFragment<br>
&lt;emilio> smfr: layoutFragment is slightly ambiguous because I maybe interpret it as a name<br>
&lt;bkardell_> if there is not symmetry here, for reasons - I think we need to be careful to follow that example in all the places<br>
&lt;emilio> smfr: where is the magic layout function used?<br>
&lt;emilio> iank_: it's on registerLayout<br>
&lt;emilio> iank_: there's a bug in WebIDL to handle classes instead of https://drafts.css-houdini.org/css-layout-api/#dom-layoutworkletglobalscope-registerlayout<br>
&lt;emilio> chrishtr: so if there are two fragments you may get called twice?<br>
&lt;emilio> iank_: yeah, if you return a break token you get called multiple times<br>
&lt;emilio> chrishtr: so layout() calls layoutNextFragment and that calls layout() potentially multiple times on the child right?<br>
&lt;emilio> chrishtr: so that example is not really exercising it right?<br>
&lt;emilio> iank_: yeah the line-by-line example exercises it<br>
&lt;emilio> iank_: it's calling layoutNextFragment on the child multiple time until it's done<br>
&lt;emilio> chrishtr: I think layoutNextFragment makes more sense since it indicates an iterator pattern<br>
&lt;emilio> Rossen: that was the initial intent yeah<br>
&lt;emilio> iank_: first question is should the callback have the same name<br>
&lt;emilio> surma: layout doesn't return fragments right?<br>
&lt;emilio> iank_: yeah it does<br>
&lt;emilio> Rossen:  layout() is called once for each fragment<br>
&lt;emilio> chrishtr: I'd keep the `Next`<br>
&lt;emilio> Rossen: so, keeping layoutNextFragment and renaming layout() to be either layoutFragment or layoutNextFragment?<br>
&lt;dbaron> I'm leaning towards the idea that it's better for the names to be different so that it's clearer that one isn't calling the other, though I don't feel that strongly right now...<br>
&lt;emilio> Rossen: can we live with layoutFragment? That'd make TabAtkins a little bit happier?<br>
&lt;emilio> TabAtkins: a third less happy<br>
&lt;bkardell_> I think layoutFragment/layoutNextFragment is less confusing actually<br>
&lt;emilio> surma: I think the symmetry helps it to be less confusing<br>
&lt;emilio> plinss: having the same name I think it's more confusing<br>
&lt;emilio> plinss: seems like it's calling the function directly instead of going through the engine<br>
&lt;bkardell_> +1 to what plinss said actually<br>
&lt;emilio> TabAtkins: you can think a bit over it and ping us on a call or something<br>
&lt;gregwhitworth> I agree with bkardell_ and plinss (layoutFragment and layoutNextFragment)<br>
&lt;emilio> Rossen: so no resolution?<br>
&lt;emilio> Rossen: what else is keeping the module from going forward?<br>
&lt;emilio> iank_: the precision stuff<br>
&lt;iank_> https://github.com/w3c/css-houdini-drafts/issues/796<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/760#issuecomment-432954770 using your GitHub account

Received on Thursday, 25 October 2018 08:07:41 UTC