| 05:27 | <annevk> | Hmm, no event discussion ugh |
| 06:50 | <MikeSmith> | oh man |
| 06:51 | <MikeSmith> | I was going to post a link to https://twitter.com/w3c/status/723167929395605509 here for the lulz |
| 06:52 | <MikeSmith> | but I see Domenic and hsivonen are already way ahead of me and have favorited it |
| 06:52 | <annevk> | I saw that, hsivonen make a point of retweeting those events |
| 06:52 | <annevk> | mkaes* |
| 06:52 | <annevk> | makes* |
| 08:27 | <Ms2ger> | annevk, yt? |
| 08:28 | <annevk> | Ms2ger: yeah |
| 08:28 | <annevk> | Ms2ger: fixing non-dispatchy things |
| 08:28 | <Ms2ger> | annevk, so origins are shared and mutable now, right? |
| 08:28 | <annevk> | Ms2ger: partially mutable, yes |
| 08:28 | <annevk> | Ms2ger: and yes, they are shared freely |
| 08:29 | <Ms2ger> | About that "partially" bit... It can't change opaque <-> tuple, or if it's a tuple, change scheme/host/port, correct? |
| 08:29 | <annevk> | Ms2ger: if it's tuple, it can change domain, that's it |
| 08:29 | <Ms2ger> | Okay, great |
| 08:30 | <annevk> | scheme/host/port never change, opaque never changes, they never change from opaque to tuple |
| 08:30 | <Ms2ger> | That's what I thought, thanks |
| 08:30 | <annevk> | If you file an issue I can add a note underneath that details these invariants |
| 08:30 | <annevk> | at some point |
| 08:32 | <Ms2ger> | https://github.com/whatwg/html/issues/1093 |
| 09:36 | <jochen__> | what's the implication of a "relevant mutation" of an img element? |
| 09:36 | <annevk> | zcorpan should know |
| 09:38 | <annevk> | jochen__: so I think that referrerpolicy should probably be part of relevant mutations |
| 09:39 | <zcorpan> | jochen__: it runs "update the image data" |
| 09:39 | <annevk> | jochen__: it seems that the eventual request happens asynchronously at a later point so can be updated |
| 09:48 | <jochen__> | ok |
| 09:48 | <jochen__> | i guess we should have a test for that |
| 10:03 | <Ms2ger> | Yes |
| 13:03 | <Ms2ger> | zcorpan, fyi https://github.com/whatwg/html/issues/1099 |
| 13:50 | <annevk> | smaug____: so I guess I'll wait a bit with defining events until that issue is sorted |
| 13:51 | <annevk> | smaug____: it's a little annoying feedback from the others is slow since everything else seems to depend on it |
| 13:51 | <annevk> | smaug____: e.g., I created a patch for <script> in HTML, but the "load" event it dispatches needs to be scoped... |
| 13:52 | <smaug____> | annevk: "that issue"? |
| 13:52 | <smaug____> | event dispatching in shadow DOM? |
| 13:52 | <annevk> | smaug____: https://github.com/w3c/webcomponents/issues/485 |
| 13:52 | <annevk> | smaug____: yeah |
| 13:55 | <smaug____> | annevk: I wonder...this iframe + session history. |
| 13:56 | <smaug____> | if the top level page is navigated back() and then forward(), I assume the iframe in shadow dom will get a new session history |
| 13:56 | <smaug____> | (bfcache is different since that keeps the iframe alive) |
| 13:57 | <annevk> | smaug____: I'm not sure I know enough about it, but that sounds right if there's no cache |
| 14:00 | <smaug____> | and random note, I _think_ having separate session history for iframes should be easy to implement in Gecko. In xul:browser (which internally uses the same code as html:iframe), we support disablehistory attribute. If not set, session history is created for the contained browsing context (and its descendants) |
| 14:22 | <wanderview> | JakeA: does chrome return workers as Client objects from matchAll() yet? I wonder if that will confuse sites when we start doing that |
| 14:30 | <annevk> | wanderview: not working on streams just yet? |
| 14:30 | <wanderview> | annevk: I started this week, but then Matt Gaunt wrote a bug that has been ruining my day for a few days now |
| 14:33 | <annevk> | 😢 |
| 14:36 | <gsnedders> | Uh, how am I meant to animate a changing SVG path nowadays? |
| 14:36 | <gsnedders> | I presume with JS? |
| 14:37 | <JakeA> | wanderview: hm, not sure. It won't show up unless you pass an option to matchAll though right? |
| 14:37 | <wanderview> | thats true |
| 14:37 | <wanderview> | ok, that seems safe |
| 14:38 | <JakeA> | https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#enumdef-clients-clienttype |
| 14:38 | <wanderview> | yea... I forgot about that |
| 14:39 | <wanderview> | JakeA: the whole "order by most recently focused" thing might be interesting with workers in the mix |
| 14:39 | <JakeA> | wanderview: hmm, good point, we need to define that |
| 14:40 | <wanderview> | JakeA: like workers count as never being focused... so always at the end |
| 14:40 | <JakeA> | That's probably good enough tbh |
| 14:41 | <wanderview> | I'll write an issue |
| 16:20 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/887 |
| 16:21 | <JakeA> | Taa! |
| 16:22 | <TabAtkins> | gsnedders: The 'd' property is in the process of being specced/implemented, so you can animate that. |
| 16:22 | <TabAtkins> | Now if you want to animate it *today*, SMIL still works everywhere but IE. |
| 16:22 | <TabAtkins> | But if you want IE support, yeah, JS is the way to go. |
| 18:24 | <Mek> | hmm, to properly specify Link rel=serviceworker support in http response headers I'd like to somehow express that: for subresource requests the request was made from a secure context, and for non-subresource requests the resulting document/worker will be a secure context. For the subresource case I can just check if the requests client is a secure context. For workers the requests client is the new worker, so that same check should work. But for |
| 18:24 | <Mek> | navigations the settings object for which I care if it is a secure context doesn't exist yet until well after the fetch is complete... |
| 20:47 | <wanderview> | Mek: err... why would we allow it on http response headers at all? regardless of how it was initiated it could have be mitm'd, right? |
| 20:49 | <Mek> | wanderview: the regular registration checks already ensure that various origins match, are all secure origins, http/https only etc. |
| 20:49 | <Mek> | so I meant http the protocol, not http vs https |
| 20:49 | <wanderview> | oh, sorry |
| 20:51 | <gsnedders> | TabAtkins: this freakin' sucks |
| 23:54 | <Mek> | woot, I filed html issue 1111 :P (okay, not sure why that number amuses me) |