- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Jul 2018 00:18:00 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `TAG feedback`, and agreed to the following: * `RESOLVED: No change in behavior, add a note as to why constructors are not exposed` * `RESOLVED: Add a new LayoutFragmentResult object with a constructor.` * `RESOLVED: Keep the layoutNextFragment name.` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: TAG feedback<br> <heycam> github: https://github.com/w3c/css-houdini-drafts/issues/760<br> <heycam> iank_: this is a bunch of assorted TAG feedback<br> <heycam> ... a lot of editorial stuff, but 3 or 4 issues we can talk about<br> <heycam> ... the first one is having a constructor for layout fragments<br> <heycam> ... in summary, currently today the only thing that can produce a layout fragment is the rendering engine<br> <heycam> ... call on the child, hey lay out this fragment, it does some work, and gives back a fragment<br> <heycam> ... the useful information is the width and height of the fragment, and you can return it in your list of children<br> <heycam> ... do we want a constructor for this?<br> <heycam> ... we can add this, I'm not objecting, but the constraint is that this isn't a valid fragment you could return to the engine<br> <heycam> ... just a placeholder for testing<br> <heycam> Rossen: the current design has a farily rigid assumption of who can produce fragments<br> <heycam> ... and be responsible for their lifteime<br> <heycam> ... and it's not the script, it's the layout engine<br> <heycam> ... exposing a constructor, you are fooling the user that they have control over it<br> <heycam> ... so I would push back on this issue with that reasoning<br> <heycam> eae: unless it's a valid fragment, it would be more confusing than it's worth<br> <heycam> Rossen: again, it would lead down the path of considering those as user space objects when they're actually browser objects<br> <heycam> dbaron: what would it mean to have a real constructor for a fragment?<br> <heycam> iank_: what Travis brings up here is events in the platform<br> <heycam> ... synthesizing an event through the system<br> <heycam> ... this is quite often used for testing<br> <heycam> ... it's not a real event<br> <heycam> ... they're already second class citizens<br> <heycam> ... for us, I'm struggling to come up with use cases for synthesizing events like that<br> <heycam> Rossen: again, the fragment projection we give back to the user is just an interace with a bunch of functionality to interrogate properties<br> <heycam> ... ti's meant to be a black box that you can move around and that's it<br> <heycam> iank_: the things you can read from it are teh width, height, baseline info (in the future0, and basically just position it<br> <heycam> ... if the child is also a custom layout it can pass information up via structured cloning<br> <heycam> ... but that's basically it<br> <heycam> iank_: dbaron or plinss anythign to add?<br> <heycam> plinss: that's reasonable<br> <heycam> Rossen: probably something that they didn't grok entirely, and they look similar on the surface but they're not<br> <heycam> plinss: in general the TAG likes to see constructors on everything<br> <heycam> ... but I agree here<br> <heycam> astearns: would it make sense to add a note saying usually we have constructors but not here?<br> <heycam> Rossen: if it's lacking explanation let's add that<br> <heycam> RESOLVED: No change in behavior, add a note as to why constructors are not exposed<br> <heycam> iank_: the second point, is that we return an options bag from layout<br> <heycam> ... which does some magic<br> <heycam> ... explicitly you return the child fragments, auto block size, some other info<br> <heycam> ... the engine goes and synthesizes a fragment fro you with correct internal representation<br> <heycam> ... shoudl that operation have a constructor, so you can create a new layout result fragment<br> <heycam> ... and check if that operation fails<br> <heycam> ... there are some cases where that operation could fail<br> <heycam> s/shoudl/should/<br> <heycam> ... for example, you pass it auto block size, create a new result fragment, atm it's just an options bag<br> <heycam> ... and then inspect what your output box size is going to be, maybe do something different based on that<br> <heycam> ... the other thing that can fail is when you deserialize the extra data you can pass up the tree<br> <heycam> ... when you try to structured clone that, like adding a SharedArrayBuffer or something<br> <heycam> ... currently we just say it threw an exception<br> <heycam> ... with a constructor the user could detect that it threw an exception<br> <heycam> ... I think it's reasonable, but would need to work out what the constructor's option bag argument would be<br> <heycam> ... it's not entirely clear to me yet<br> <heycam> frremy: when I tried it, something I found frustrating is you can have a big option you want to give, only a few props on the object can't be serialized<br> <heycam> ... then you have to clone the entire object yourself, by removing the stuff you can't serialize<br> <heycam> ... maybe would be nicer to set null for props you can't serialize for example<br> <heycam> iank_: I think that's a bigger ask<br> <heycam> ... structured clone is painful for people to use<br> <heycam> ... would that have been useful? there's a bit out of your control<br> <heycam> ... would it be useful to ensure that operation doesn't fail?<br> <heycam> frremy: something like JSON.stringify, with a callback to handle the unserializable stuff<br> <heycam> iank_: that would be a slightly larger change in the HTML spec<br> <heycam> frremy: I don't think having a constructor would change anything<br> <heycam> ... only solution is to clone<br> <heycam> iank_: would it have been useful to just get say the auto block size?<br> <heycam> frremy: not sure<br> <heycam> iank_: I think that's a reasonable ask, shouldn't be too much work, not sure many people would use it<br> <heycam> ... can always add it and use count it, remove if it's unused<br> <heycam> iank_: we need to add a constructor, not jsut returning a FragmentResultOptions, but a constructor for a type like FragmentResult<br> <heycam> ... then run all the steps for userland layout, structure clone, sanitize the output<br> <heycam> ... by running the constructor you could catch an error that would happen during that process<br> <heycam> Rossen: as to the larger question, about expectations of what happens if the script starts throwing?<br> <heycam> iank_: I think we just fall back<br> <heycam> ... I think that larger question is just a misunderstanding, editorial<br> <heycam> Rossen: objections to adding the new LayoutFragmentResult object?<br> <heycam> RESOLVED: Add a new LayoutFragmentResult object with a constructor.<br> <heycam> iank_: final piece of discussable feedback here<br> <heycam> ... confusion about layoutNextFragment name<br> <heycam> ... do we want to go back to layout?<br> <heycam> Rossen: no<br> <heycam> ... that's like call everything object<br> <heycam> iank_: David or Peter?<br> <heycam> dbaron: I already disagreed with Travis on that one<br> <heycam> frremy: I like that "next fragment" knowing that you're getting a fragment<br> <heycam> ... "layout" is too general<br> <heycam> iank_: Rossen and David want layout<br> <heycam> plinss: I tend to prefer verbosity<br> <heycam> iank_: Ian and Francois don't care<br> <heycam> Rossen: other opinions or objections?<br> <heycam> RESOLVED: Keep the layoutNextFragment name.<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-401643323 using your GitHub account
Received on Monday, 2 July 2018 00:18:08 UTC