WHATWG
2023-06-21
plaintext logs
prev next
source on github
14:16
<bkardell>
happy to leave a similar comment on https://github.com/whatwg/html/pull/9166 but I feel like it might be better to get past simple confusions in chat, so I'd like to clarify something. annevk are you suggesting that you are opposed to the rearranging vs what we tried to do in the original PR that this was replacing - to weave shadow into that already complex but flat version? I found it very complex, some others here seemed to also think there was room for improvement. I tried and shopped it to at least 3 others before assuming this would be an improvement and make shadow dom fit easier, but... you don't think so?
14:16
<bkardell>
(I'd just like to clarify / not misunderstand the comment before I reply)
14:25
<annevk>
bkardell: I don't think it works as-is, you definitely need to introduce each <dl> list with a preceding sentence as we do elsewhere
14:26
<annevk>
bkardell: I would have preferred the restructuring to be a separate editorial change from the shadow tree changes, as reviewing the combination is hard
14:27
<bkardell>
bkardell: I don't think it works as-is, you definitely need to introduce each <dl> list with a preceding sentence as we do elsewhere
its not the only nested dl that's in there, I took the idea from others
14:29
<bkardell>
bkardell: I would have preferred the restructuring to be a separate editorial change from the shadow tree changes, as reviewing the combination is hard
yeah, I think that makes a lot of sense and regret not doing that. It's mainly the priority is to get the shadow dom stuff in more than make it easier to follow, but trying to weave the shadow dom stuff in is so much harder unless you rearrange it first, I think
14:29
<bkardell>
also, my time on this is just limited
14:29
<bkardell>
where do you prefer we go from here? I suppose I can try doing a lesser pull first
14:32
<annevk>
I'm not sure what precedent you mean. HTML has a lot of old algorithms that could do with some refactoring. They might not be a good source for inspiration. As for what to tackle next, if you feel tackling all the feedback at once is too much I'd recommend focusing on a restructuring PR first. It seems like it should then not be a whole lot of effort to put the shadow root stuff in.
14:33
<annevk>
But if you want to address it all at once that's okay too.
17:07
<bkardell>
I think the case for rearranging it is weaker without having to incorporate shadow dom but if you think we can be aware of that, I'm willing to try 2 steps
17:40
<annevk>
bkardell: yeah, we'd view it through that lens (and you can make it explicit in your commit message)
18:03
<bkardell>
interesting... does the html build use Prince XML?
18:03
<bkardell>
for what?
18:09
<Jeffrey Yasskin>
https://wicg.github.io/turtledove/ has a couple fields that are passed to the browser in one realm, stored for a while, and then passed to a function in another realm. The spec currently uses JSON for this, where it might be able to use StructuredSerializeForStorage() instead, but my question for this group is whether there's a good WebIDL pattern for documenting that restriction on types and creating the resulting objects in the right realm? https://w3c.github.io/IndexedDB/ does it all manually, but maybe something better has come along since then...
18:12
<Jeffrey Yasskin>
Ah, they don't use Structured Clone in order to defend the data's recipients from too-complex input (https://github.com/WICG/turtledove/issues/654), so if we add something in WebIDL for this, it couldn't be directly shared by IndexedDB (and maybe couldn't anyway since it would change the order of errors in IndexedDB).