| 08:19 | <zcorpan> | hello y'all |
| 08:21 | <annevk> | morning zcorpan |
| 08:23 | <zcorpan> | did i miss anything interesting last week? :-) |
| 08:35 | <annevk> | zcorpan: we might almost be done with synthetic click events |
| 08:35 | <annevk> | zcorpan: but it hasn't landed yet, so I guess you didn't miss that |
| 08:38 | <zcorpan> | thanks, checking now |
| 09:57 | <MikeSmith> | https://github.com/w3c/push-api/issues/211 “ We sort of assume that the browser is at some point going to start enforcing origin isolation, but never really point out the place where that happens.” |
| 11:44 | <smaug> | annevk: I think https://github.com/whatwg/dom/pull/342 looks ok. (I'm still not too used to review spec changes though). |
| 11:44 | <smaug> | It is still a bit unclear to me why we need so much special casing there though. |
| 11:46 | <smaug> | I mean when (post) default handling for click isn't really different to other default handling events. It just happens with untrusted events too |
| 11:47 | <annevk> | smaug: per spec the handling of non-click events does not happen as part of dispatch |
| 11:47 | <smaug> | I know |
| 11:47 | <smaug> | and that is casing this special casing with click |
| 11:47 | <smaug> | causing |
| 11:47 | <smaug> | I think |
| 11:47 | <annevk> | Yeah |
| 12:50 | <annevk> | Domenic: changing the appcache stuff is feeling really pointless now |
| 12:50 | <annevk> | dominicc: all the default action stuff there is about showing UI |
| 12:50 | <annevk> | Domenic: something all UAs have removed I believe since it's rather bad |
| 13:23 | <annevk> | smaug: so did we decide that click() should set composed? |
| 13:23 | <annevk> | smaug: it apparently sets view as well |
| 13:24 | <smaug> | not sure if we decided, but I think it should be composed |
| 13:30 | <zcorpan> | JakeA: re http://logs.glob.uno/?c=freenode%23whatwg&s=13+Oct+2016&e=13+Oct+2016#c1007958 need to escape <!-- <script> also (or just any < ) |
| 13:31 | <JakeA> | zcorpan: Cheers! That's what I'm doing now. It's also what the Ember people do |
| 13:41 | <zcorpan> | Domenic: re http://logs.glob.uno/?c=freenode%23whatwg&s=12+Oct+2016&e=12+Oct+2016#c1007866 , probably https://webcompat.com/ |
| 15:46 | <tobie> | Merged jyasskin's open dictionaries (records). |
| 15:47 | <jyasskin> | tobie: \o/ |
| 16:12 | <annevk> | Oooh cool |
| 16:12 | <annevk> | Now bikeshed / idlparser need patches and we can start fixing specs |
| 16:21 | <gsnedders> | nox: plz file a bug |
| 16:21 | <gsnedders> | nox: I have a fever and the odds of my doing anything right now are low :P |
| 16:28 | <nox> | gsnedders: Sure! |
| 16:42 | <jgraham> | I imagine that hallucinating gsnedders will be an awesome source of code |
| 16:52 | <gsnedders> | jgraham: … |
| 17:08 | <smaug> | iank___ write the worklet spec? |
| 17:09 | smaug | is trying to understand https://drafts.css-houdini.org/worklets/#dom-worklet-import 6.1.2 of that algorithm |
| 17:16 | <smaug> | oh, I see |
| 17:17 | <smaug> | this is one of the most complicated piece of spec I've seen for awhile... all this fetch taking a callback function in spec level text |
| 17:19 | <annevk> | Yeah, script loading is getting rather complicated |
| 17:20 | <annevk> | Maybe there's some way of refactoring it that we haven't thought about, but satisfying workers / shared workers / service workers / worklets is hard |
| 17:23 | <smaug> | annevk: but the idea with 'Fetch a module script tree' is that module will be loaded and any dependencies and each fetch will use the callback provided by the caller? |
| 17:24 | <annevk> | smaug: think so, Domenic would know for sure |
| 17:46 | <Domenic> | smaug: annevk: yep, that's the idea. The callback is optional; there is a reasonable default. But worklets need to maintain their own cache thingy. |
| 18:15 | <smaug> | Domenic: why do they need to have their own cache? |
| 18:19 | <Domenic> | smaug: I don't remember, but it seemed plausible at the time. iank___ will know. I guess a non-normative note in the spec explaining would be good. |
| 18:20 | <Domenic> | Hmm I guess it's kind of outlined in https://drafts.css-houdini.org/worklets/#module-responses-map |
| 18:20 | <Domenic> | Without it the modules would be reloaded every time a worklet is re-instantiated |
| 19:04 | <annevk> | Domenic: very similar to service workers in that respect |
| 19:11 | <Domenic> | Hmm I wonder if we could let them bring their own module map |
| 19:11 | <Domenic> | Well, hmm, we kind of already do |
| 19:12 | <Domenic> | If their settings object specifies a shared module map, they'd be good to go |
| 19:17 | <Domenic> | Filed https://github.com/w3c/css-houdini-drafts/issues/324 |
| 19:18 | <Domenic> | service workers actually require the hook, e.g. to set the skip service worker flag, redirect mode to error, and so on. |
| 20:01 | <jdalton> | for fetching urls that redirect (say site.com/docs/ which 302 redirects to site.com/docs/v1.2.3) the fetch will by default follow but that means the page that loads is site.com/docs/ and it doesn't redirect to site.com/docs/v2.1.3) if I set the fetch to "manual" I can't see where the request was redirected to so I can't replace it with a Response.redirect(). Is there a way to have a fetch redirect without getting the full redirected response (comparing |
| 20:01 | <jdalton> | the uri to fetch vs the response.url and then replacing with a redirect) ? |
| 20:48 | <rodneyrehm> | hey there! is there any sensible way to figure out who added a particular section the the spec, since blame via github isn't really an option? |
| 20:50 | <jyasskin> | Command-line blame? |
| 20:51 | <rodneyrehm> | sure, but that would require cloning the repo |
| 20:51 | <rodneyrehm> | particularly I'm looking for insight on https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps - namely if <body> is considered a focusable area |
| 21:01 | <iank___> | Domenic & smaug the basic idea is that a user agent can create and destroy worklet global scopes at any time. But when we do so we want them to be "consistent" with the other contexts. I.e. they have had exactly the same script run in them. |
| 21:02 | <smaug> | iank___: and the stays alive forever? |
| 21:02 | <smaug> | cache |
| 21:02 | <smaug> | the cache |
| 21:02 | <iank___> | for the lifetime of the page at least. |
| 21:03 | <iank___> | you only really need it if you are planning on killing the contexts or creating new ones at some arbitrary point. |
| 21:03 | <darobin> | rodneyrehm: just clone the repo man, it's a great excuse to go do something else while git is churning :) |
| 21:04 | <TabAtkins> | It doesn't even take that long, really. ^_^ |
| 21:04 | <rodneyrehm> | darobin: cloning at 29% ~70KBit/s (Hotel WiFi), while watching Madam Secretary ;) |
| 21:05 | <darobin> | TabAtkins: it can if your network isn't all that great |
| 21:05 | <darobin> | rodneyrehm: enjoy! |
| 21:05 | <TabAtkins> | Yeah, 70kbps is, uh, not exactly great. |
| 21:08 | <rodneyrehm> | the only thing missing here is modem dial-up sounds ;) |
| 21:14 | <Domenic> | did you do a shallow clone? That helps a lot. |
| 21:16 | <rodneyrehm> | unless that's the default, no. googling shallow clone now ;) |
| 21:16 | <jgraham> | Not for blame though? |
| 21:16 | <jgraham> | Unless git caches that information in some way I am unaware of |
| 21:17 | <Domenic> | oh right lol |
| 21:17 | <Domenic> | that would in fact defeat the purpose |
| 21:17 | <rodneyrehm> | good to know `--depth 1` anyway :) |
| 22:05 | <rodneyrehm> | ok, so that probably could've gone quicker… https://github.com/whatwg/html/commit/f96b1997 is the commit I was looking for |
| 22:17 | <Domenic> | but now you're equipped for future spelunking! |
| 22:34 | <Domenic> | terinjokes: \o/ |
| 22:34 | <Domenic> | your original whatwg/console issue #3 to make web developers lives better has now almost-fully percolated into the ecosystem :D. Only Edge is the holdout. |
| 22:45 | <terinjokes> | \o/ |
| 22:48 | <Domenic> | TabAtkins: does this index seem correct to you? The duplicate (data), (data...) seems strange to me... https://console.spec.whatwg.org/#index-defined-here |
| 22:50 | <TabAtkins> | I think something about the "...data" is confusing it. |
| 22:51 | <TabAtkins> | That's not a valid signature, so something's going a little bit wonky and generating two `lt` values, one with "data..." and one with "data". Dunno what the first is about. |
| 22:53 | <TabAtkins> | In the middle of some complex edits, so will load that up in a bit; please file an issue so I don't forget. |
| 22:55 | <Domenic> | OK cool |
| 23:00 | <Domenic> | TabAtkins: I forgot how to make a <h4> that is also a definition. <h4 id="clear" method for="console">clear()</h4> isn't working. Halp? |
| 23:02 | <jyasskin> | Domenic: dfn-type |
| 23:02 | <jyasskin> | I mean, you probably have to use dfn-type="method" instead of just method. |
| 23:03 | <Domenic> | that did it; thanks! |
| 23:03 | <TabAtkins> | You really shouldn't have to do that, tho - I'm staring at that code right now. |
| 23:04 | <TabAtkins> | It explicitly looks for <dfn> or <hN>, then checks them for attributes with the dfn-type names, and sets data-dfn-type appropriately. |
| 23:04 | <TabAtkins> | Domenic: What's the outerHTML you get from the earlier code? |
| 23:05 | <Domenic> | TabAtkins: outerHTML looks correct, but the Web IDL autolinker couldn't find it |
| 23:06 | <Domenic> | Wait, no, it can |
| 23:06 | <Domenic> | I must have messed something else up |
| 23:06 | <TabAtkins> | Heh, kk, phew. |
| 23:41 | <TabAtkins> | Domenic, annevk: I just pushed what *should* just be an internal rename, affecting only internal stuff and error messages, but if you suddenly get link failures or new messages about statuses, let me know. |
| 23:41 | <TabAtkins> | (I switched internal terminology from referring to specs/links as "ED" or "TR" to instead be "current" and "snapshot".) |
| 23:43 | <Domenic> | Good to know! |
| 23:43 | <TabAtkins> | No tests changed, so fingers crossed that nothing changes in production either. |
| 23:48 | <Domenic> | That's the dream :D |
| 23:50 | <TabAtkins> | Okay, now that that yak's shaved, time to figure out wtf I'm doing defaulting the requested ref status to the spec's status and not letting link-defaults override that. >_< |
| 23:54 | <Domenic> | this sounds relevant to my interests |
| 23:56 | <TabAtkins> | Probably not - you only work with current-status specs anyway. But it fucks with people trying to prefer a snapshot link while publishing a current spec. |
| 23:56 | <rniwa> | Domenic: fyi, there's another PR for custom elements testing: https://github.com/w3c/web-platform-tests/pull/3968 |
| 23:56 | <TabAtkins> | But sure, I'm trying to untangle this spaghetti-code mess of an autolinker. |
| 23:56 | <TabAtkins> | So it'll eventually be relevant to your interests. |
| 23:56 | <Domenic> | TabAtkins: well I was hoping it would fix issues like https://github.com/tabatkins/bikeshed/issues/837 |
| 23:57 | <TabAtkins> | Probably not! |
| 23:57 | <Domenic> |