| 00:26 | <domfarolino> | Hm my generated single page index.html is 10mb |
| 00:27 | <domfarolino> | Domenic: Do you think we can just get rid of this: https://github.com/whatwg/html/pull/4031#discussion_r245355186 I honestly don't quite get what it means, is it just saying the element must still exist in the DOM even if its resource doesn't get applied? |
| 00:28 | <domfarolino> | It almost sounds more like it is saying something like a style sheet will still be available via DOM apis even if it is not applied maybe? |
| 00:28 | <domfarolino> | Yeah that might be it |
| 00:29 | <Domenic> | I think getting rid of it would be goos |
| 00:30 | <Domenic> | I think it's saying either "even if the stylesheet is disabled, document.styleSheets should still contain it" or "even if the resource is never fetched, the link element must still be accessible via the DOM". |
| 00:30 | <Domenic> | Neither are very useful |
| 00:31 | <domfarolino> | yeah |
| 01:40 | <Domenic> | domfarolino: maybe we should move the "Queue a task on the networking task source" out of the "process this type of linked resource" steps? I.e. make the default fetch-and-process step 12.5 be "Queue a task on the networking task source to process the linked resource given el, success, and response." |
| 01:47 | <domfarolino> | I like that idea. As long as it wouldn't be a problem performing the content-type metadata check in the task and not earlier (seems fine) |
| 01:47 | <Domenic> | Yeah the response can't change in such a way |
| 01:49 | <domfarolino> | 👍 |
| 06:23 | <TimothyGu> | annevk: is there a reason why we are suddenly trying to remove [NoInterfaceObject] from everywhere? I feel like it was just something on the backlog |
| 07:38 | <annevk> | TimothyGu: Ms2ger filed a PR which made me go through the backlog a bit |
| 07:38 | <TimothyGu> | ah I see |
| 13:43 | <Ms2ger> | annevk, do you still feel the same way about https://github.com/heycam/webidl/issues/236 ? |
| 13:46 | <annevk> | Ms2ger: yeah, pretty much, DOMString -> JavaScript string and USVString -> scalar value string, too |
| 13:47 | <annevk> | (and also have that conversion on the way out) |
| 13:47 | <annevk> | So I can return a byte sequence, and ByteString ensures JavaScript gets a DOMString |
| 13:48 | <annevk> | (This again makes me wonder why Domenic thinks that return values are useless. It seems they're quite necessary at times.) |
| 20:38 | <a-ja> | i know there's been fieldset/legend work underway recently. is this up to date with that work? https://html.spec.whatwg.org/multipage/rendering.html#the-fieldset-and-legend-elements |
| 20:39 | <a-ja> | been pondering whether legend should align right in rtl |
| 22:42 | <Domenic> | TabAtkins: no good linking syntax for slots, right? [=StorageArea/\[[DatabaseName]]=] doesn't work |
| 22:42 | <Domenic> | a-ja: that is up to date as far as I know |
| 22:42 | <TabAtkins> | {{StorageArea/[[DatabaseName]]}} |
| 22:43 | <TabAtkins> | slots are just a private part of the interface, they live in the idl attr namespace |
| 22:43 | <Domenic> | Ah for some reason I thoguht that gave me the biblio error but on trying it again it does not. |
| 22:43 | <a-ja> | tks Domenic |
| 22:44 | <TabAtkins> | You still need to escape the [ when you define the slot, but not when you link it |
| 22:44 | <TabAtkins> | (and as soon as IDL grows a slot syntax (/ implicit backing slots), you won't generally need to do that anyway |
| 22:48 | <Mek> | (calling something storage area when the local storage/session storage specs already extensively talk about storage areas seems like it might be confusing btw, although I guess at least in that case it isn't ever formally defined as a term, and certainly isn't a IDL interface (although in blink the implementation of the Storage IDL interface is called StorageArea...)) |
| 23:44 | <domfarolino> | Domenic: one thought I had for testing task sources was to perform two operations that would definitely queue tasks on the same source and assert their order is correct. That would at least catch impls that queue the tasks on different sources AND prioritized the sources in a way that doesn’t jive well with the test. Would not catch impls that queue them on different sources but happen to prioritize them in a way that |
| 23:44 | <domfarolino> | the test accepts. But in general it’s pretty pedantic yeah |
| 23:45 | <Domenic> | Anyone have an opinion on the right fix for https://github.com/WICG/kv-storage/issues/45 ? I am feeling indecisive. |
| 23:46 | <Domenic> | domfarolino: yeah I guess that's a pretty simple stochastic test. I'd be worried about impls that don't explicitly prioritize the task sources against each other, or not in any principled way, so that you'd end up passing half the time and failing half the time depending on which task source it decided to pick. Still might be worthwhile though. |