| 01:02 | <Domenic> | annevk: Fwiw, Mozilla have a positive position now https://github.com/mozilla/standards-positions/issues/677. But I'm also happy not to rush the changes to the HTML spec. It isn't getting in the way, just want to make sure we integrate properly |
| 04:50 | <sideshowbarker> | Progress on HTML Modules seems to be stalled. Is that due to lack of sufficient implementor interest? Or is it due to it being blocked by particular problems? Or because nobody has yet fully specified it? |
| 04:56 | <beau87> | I’ve yet to get an assignment |
| 05:21 | <sideshowbarker> | as far as HTML Modules being specified in detail, I see that https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-module-spec-changes.md seems to have quite detailed spec changes …but I also see that it’s now been 3 years since it was last updated |
| 07:30 | <annevk> | sideshowbarker: there's no detailed proposal I think and the last one got a bunch of feedback (probably not all properly recorded) that was never dealt with |
| 08:09 | <sideshowbarker> | sideshowbarker: there's no detailed proposal I think and the last one got a bunch of feedback (probably not all properly recorded) that was never dealt with About other features like DSD, much has been made (rightfully) of developers speaking up to say they need the feature. It seems like client-side HTML includes is something that we’ve had many developers asking for relatively forever now. (A developer contacted me today to ask about it, which is why I ended up asking here.) |
| 09:10 | <annevk> | sideshowbarker: probably because it's a quite complex idea that involves a lot of tradeoffs |
| 09:11 | <annevk> | sideshowbarker: and there being more pressing problems, such as Web Components accessibility |
| 11:52 | <Domenic> | Client-side includes are also very different from HTML imports |
| 11:52 | <Domenic> | Client-side includes are just a way to have worse performance for more developer convenience, basically |
| 12:21 | <Ms2ger> | annevk: I was just about to file https://github.com/w3c/hr-time/issues/152 😅 |
| 13:49 | <Jake Archibald> | <dialog> and popover seem to queue tasks to fire open/close events, even though these things always happen on the main thread. Anyone know the reasons? |
| 16:03 | <annevk> | Jake Archibald: popover doesn't do that for beforetoggle |
| 16:12 | <Jake Archibald> | annevk: but it does for toggle, meaning that event could come after the next render |
| 16:12 | <Jake Archibald> | https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute:queue-a-popover-toggle-event-task |
| 16:17 | <annevk> | Jake Archibald: yeah sorry, I forgot exactly why dialog did that; I suppose conceivably it could be moved to "update the rendering", but "update the rendering" is doing a lot which is a problem of its own |
| 16:18 | <annevk> | Jake Archibald: one thing we've historically tried to avoid is node tree mutations triggering events, but in the select case of attribute mutations it might be okay |
| 16:19 | <Jake Archibald> | yeah, if it was debouncing stuff, I'd expect microtasks or render steps |
| 16:21 | <annevk> | Jake Archibald: it seems reasonable to try to change this to be closer to sync; not sure if fully sync would be compatible or desirable |
| 16:22 | <annevk> | Jake Archibald: for popover the main reason for the timing was consistency with dialog |
| 17:27 | <Jake Archibald> | annevk: yeah, I wondered if there was some case where a popover opens, but immediately closes or something, and in that case they didn't want an event |
| 17:28 | <Jake Archibald> | I made some notes while reading the spec https://github.com/whatwg/html/issues/9036. Some of those might just be misunderstandings though. |
| 17:50 | <annevk> | Jake Archibald: for a case like that we don't want two events, though that also follows dialog |
| 17:51 | <annevk> | Jake Archibald: you prolly want to tag mfreed and ntim there (and Joey, doesn't seem to be here anymore) |
| 17:51 | <annevk> | Jake Archibald: oh, and add the popover label |
| 19:46 | <Dominic Farolino> | Someone asked a question today that I didn't immediately know the answer to: why must we enforce CORS check on redirects that required a preflight? Is the explicit preflight opt-in not enough to act as a proper opt-in for the redirect? |
| 19:58 | <Dominic Farolino> | I guess the redirect could be computed based on the credentials of the initiator, in which case it could expose sensitive information to the redirectee withour CORS... |