| 00:02 | <Panos Astithas> | Sounds like a plan |
| 01:17 | <Ari Entlich> | I have one additional question about how the spec is written. To define the dirty checkedness flag, it says: "[the dirty checkedness flag] must be set to true whenever the user interacts with the control in a way that changes the checkedness". However, elsewhere it states that setting the checked IDL attribute also sets the flag. Is this some special definition of "user" that the spec is using, including both human and script "users"? Or is it just incorrect/incomplete/ambiguous? The definition of the dirty value flag includes similar language but also says "(It is also set to true when the value is programmatically changed, as described in the definition of the value IDL attribute.)", which makes me think the answer is the latter? |
| 02:38 | <Domenic> | Hmm. For https://github.com/whatwg/html/pull/10085 how should I properly refer to `NavigationHistoryEntry`, which is defined in browsing-the-web, in Location, which is part of nav-history-apis? |
| 06:32 | <annevk> | Ari Entlich: those are complementary requirements. |
| 06:35 | <Domenic> | It doesn't say "must be set to true only when the user interacts". |
| 08:15 | <zcorpan> | annevk: with URLSearchParams no longer being serializable, we have a problem for such objects stored in an indexeddb. The spec afaict assumes deserialization steps will be defined (step 22 .. 24 in https://html.spec.whatwg.org/multipage/structured-data.html#structureddeserialize ) |
| 08:18 | <zcorpan> | annevk: options: throw (data loss), {} (data loss), serialize to a string, serialize to a plain object, serialize to URLSearchParams |
| 08:22 | <zcorpan> | I think deserializing to URLSearchParams is best. At some point in the future we can throw or return null instead |
| 08:35 | <annevk> | It never was serializable? But maybe it was in Gecko? In any event, throwing or continuing to return the object seems okay I suppose. But that's not really a web platform problem as the web platform didn't support serialization to begin with. |
| 08:39 | <zcorpan> | annevk: it was in Gecko |
| 09:37 | <freddy> | how did gecko serialize? toString? |
| 09:38 | <annevk> | TabAtkins: heya, just in case you didn't see my GitHub ping: https://github.com/whatwg/url/pull/812 |
| 09:53 | <zcorpan> | freddy: to something that deserializes back to a URLSearchParams object |
| 09:54 | <freddy> | oh, so a custom serialization that wasn't fully exposed in itself, just as observable behavior. Gotcha :) |
| 09:55 | <zcorpan> | freddy: see step 19 onwards in https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal (but the spec didn't specify that URLSearchParams was serializable) |
| 15:04 | <Dominic Farolino> | Why do WHATWG steps do this weird thing now that can be reproduced by going to https://infra.spec.whatwg.org/#strings, clicking on the "string" definition and not being able to immediately get a link to that term even by clicking on #string at the top of the grey box? |
| 15:05 | <Dominic Farolino> | When I click on #string in the grey box, I don't get navigated to #string (which is what happened in the past), and the grey box moves really slowly in this animation to the bottom left of the screen |
| 15:05 | <Dominic Farolino> | I guess the reference box just seems a tiny bit harder to use now, is what I'm trying to articulate. |
| 15:06 | <Dominic Farolino> | If I click on anything else in the box, and then click on #string at the top, I finally get the fragment navigation to #string |
| 15:06 | <annevk> | Dominic Farolino: I noticed that too, mind filing at https://github.com/speced/bikeshed/issues/new? Would help TabAtkins with fixing. |
| 15:07 | <Dominic Farolino> | Sure thing |
| 15:07 | <Dominic Farolino> | I don't see this on other bs specs so I figured it was a WHATWG thing maybe. But yeah, filing an issue is a good start. |
| 15:29 | <Dominic Farolino> | annevk: Do you know the difference between https://html.spec.whatwg.org/C#insert-an-element-into-a-document and https://html.spec.whatwg.org/C#becomes-connected? The question reduces to what is the difference between "in a document tree" and "connected". Sorry if that's a dumb question, it probably has to do with shadow DOM which I don't know much about. |
| 15:38 | <annevk> | Dominic Farolino: I think you found the answer, no? If you follow the links those terms are explained. |
| 15:55 | <Dominic Farolino> | Can a node's a shadow-including root ever be a ShadowRoot itself? Or is the top-most root always a "normal"(?) node, under which Shadows can exist? |
| 16:54 | <annevk> | Dominic Farolino: You cannot create a shadow root without a host. So the shadow-including root is always an Element, DocumentFragment, or Document I think. |
| 16:56 | <annevk> | Above I should also have said that generally we prefer the "becomes connected" concept when we can move things toward it. The former is a bit of a leftover from the "before shadow tree days", iirc. |
| 17:18 | <Dominic Farolino> | Makes sense, thank you. |
| 18:23 | <Dominic Farolino> | annevk: https://github.com/speced/bikeshed/issues/2772 |