| 00:38 | <terinjokes> | does XHR2 no longer care about ArrayBuffers as a request body? |
| 00:40 | <terinjokes> | annevk: ^^ |
| 07:32 | <annevk> | terinjokes: sure does |
| 07:32 | <annevk> | Hixie: pretty sure, yes |
| 07:33 | <Hixie> | why? |
| 07:33 | <annevk> | Hixie: there's nothing about event listeners that goes back to the microtask thing, we just iterate through them synchronously and run them |
| 07:34 | <Hixie> | how do you run the callbacks? |
| 07:34 | <annevk> | Hixie: through IDL's "call ..." thingie for that |
| 07:34 | <Hixie> | http://heycam.github.io/webidl/#es-invoking-callback-functions ? |
| 07:34 | <annevk> | Hixie: yeah |
| 07:36 | <Hixie> | huh |
| 07:37 | <Hixie> | when did they stop calling "clean up after running a callback"? |
| 07:37 | <annevk> | Hixie: note that in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27046#c5 I asked for clarification about this since I thought I had the wrong mental model |
| 07:38 | <Hixie> | maybe this changed at some point |
| 07:38 | <annevk> | It does seem quite weird to me to run microtasks between two registered event listeners that run in the same task |
| 07:38 | <Hixie> | i could have sworn we wanted mutation observers to run after each event listener |
| 07:38 | <annevk> | Though smaug always maintains that is the model, so maybe... |
| 07:38 | <Hixie> | at some point i thought heycam|away had webidl calling the "clean up after running a callback" logic |
| 07:38 | <annevk> | Hixie: yeah I thought so too, but then it wasn't really supported by any specification |
| 07:38 | <Hixie> | maybe bz changed it? |
| 07:39 | <Hixie> | oh well |
| 07:39 | <Hixie> | bed time for me |
| 07:39 | <Hixie> | nn |
| 07:40 | <annevk> | have a good night |
| 07:40 | <annevk> | I might try to sort it out once more if I have some time left |
| 07:49 | <terinjokes> | annevk: i just don't see it in the version up on the site |
| 07:50 | <annevk> | terinjokes: "void send(optional (Document or BodyInit)? body = null);" |
| 07:50 | <annevk> | terinjokes: "typedef (Blob or BufferSource or FormData or URLSearchParams or USVString) BodyInit;" (if you follow the BodyInit link) |
| 07:51 | <terinjokes> | i promise you |
| 07:51 | <annevk> | terinjokes: http://heycam.github.io/webidl/#common-BufferSource (if you're curious about BufferSource and look into IDL to find out) |
| 07:51 | <terinjokes> | that does not look like a link to me |
| 07:52 | <annevk> | terinjokes: you need to hover the IDL block these days I think, we made the styles a bit less distracting for when you're just reading |
| 08:00 | <annevk> | Ms2ger: ta, done |
| 08:58 | <annevk> | Does anyone else get a lot of these GitHub user surveys? |
| 08:58 | <annevk> | Is there a way to opt out? |
| 09:05 | <JakeA> | annevk: I got one this morning |
| 09:23 | <mathiasbynens_> | annevk: you didn’t respond to this part “https://url.spec.whatwg.org/#origin reads as though the default port is included.” |
| 09:25 | <mathiasbynens> | fwiw, i always thought origin didn’t include implicit/default ports, only what’s explicitly part of the URL |
| 09:28 | <annevk> | mathiasbynens: I made a mistake, origins are tuples, not strings |
| 09:28 | <annevk> | mathiasbynens: and the tuple includes the origin |
| 09:28 | <annevk> | mathiasbynens: includes the port, oops |
| 09:29 | <mathiasbynens> | ok, so the url spec is correct then |
| 09:29 | <mathiasbynens> | so https://example.com/ and https://example.com:443/ are same-origin? |
| 09:35 | <annevk> | mathiasbynens: yes |
| 11:37 | <MikeSmith> | https://w3c.github.io/webappsec/specs/credentialmanagement/#security-considerations seems to be kind of defining a Somewhat Similar Origin Policy |
| 11:38 | <MikeSmith> | I wonder what other specs might have the same need |
| 11:39 | <MikeSmith> | i.e., for this Credential Management it's about credential sharing among non-exact origins, but it's imaginable that there might other use cases for sharing across non-exact origins |
| 11:40 | <MikeSmith> | well I guess there are lots of other use cases, if you listen to the people who think the same-origin policy is a problem |
| 11:41 | <MikeSmith> | "MUST NOT offer credentials to an origin in response to request() without user mediation if the credential’s origin is not an exact match for the calling origin" |
| 11:55 | <smaug____> | annevk: what is the current plan, will shadow dom be merged to dom, or will it stay a separate spec? |
| 11:56 | <smaug____> | (just thinking about bug filing ) |
| 12:06 | <zcorpan_> | Ms2ger: in quirks spec source i have this: |
| 12:07 | <zcorpan_> | <h2>Quirks that maybe can be removed from implementations</h2> |
| 12:07 | <zcorpan_> | <dl> |
| 12:07 | <zcorpan_> | <dt>In quirks mode, text-decoration is propagated into floating and absolutely positioned elements</dt> |
| 12:07 | <zcorpan_> | <dd><p>Opera, WebKit and IE9 (except in compat view quirks mode) don't support this quirk.</dd> |
| 12:07 | <zcorpan_> | (commented out) |
| 12:07 | <Ms2ger> | There we are |
| 12:09 | <annevk> | smaug____: there's no good plan for shadow DOM yet I think |
| 12:09 | <annevk> | smaug____: there's not really consensus on what it should look like |
| 12:11 | <smaug____> | ok, so keep filing bugs on shadow dom spec for now, not dom spec |
| 12:12 | <annevk> | smaug____: yeah |
| 12:12 | <annevk> | smaug____: I'd like to do custom elements first, but we can't seem to get agreement on how to do upgrades :-( |
| 12:13 | <smaug____> | right |
| 12:13 | <smaug____> | I haven't been following that too closely |
| 12:18 | <annevk> | Okay, so I tested and yes, there are bugs around microtasks and callbacks |
| 12:18 | <annevk> | Baaah |
| 12:27 | <annevk> | Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27874 |
| 12:28 | <annevk> | Note that mutation are from 2011 |
| 12:32 | <smaug____> | don't understand what that bug is about |
| 12:34 | <annevk> | smaug____: you can't explain when the callbacks are supposed to run from reading the specs |
| 12:34 | <smaug____> | oh, spec text issue |
| 12:35 | <annevk> | smaug____: well it's a bug against a spec |
| 12:35 | <smaug____> | hmm, webidl? |
| 12:35 | <smaug____> | why webidl |
| 12:35 | <annevk> | smaug____: it defines running callbacks |
| 12:36 | <smaug____> | ah, right... |
| 12:36 | <smaug____> | ok, I would add some hook to webidl and make HTML spec to use that to invoke end-of-microtask stuff |
| 12:36 | <smaug____> | HTML or DOM |
| 12:36 | <annevk> | yeah there is such a hook |
| 12:37 | <annevk> | however, the problem is that we don't want to invoke it all the time |
| 12:37 | <smaug____> | yes, only when there isn't any other script on stack |
| 12:37 | <smaug____> | and that would be up to the HTML or DOM to spec |
| 12:37 | <smaug____> | I guess HTML |
| 12:37 | <annevk> | such a weird model |
| 13:18 | Ms2ger | pokes dglazkov |
| 13:37 | <annevk> | JakeA: did you talk to devdocs.io about AppCache vs SW? |
| 13:37 | <annevk> | JakeA: seems like they're lacking TLS |
| 13:39 | <JakeA> | annevk: I haven't, but shall. But yeah, I guess TLS is an initial blocker. If they've got it working with appcache, they may not want to move to something with worse support |
| 13:39 | <annevk> | JakeA: well, we're going to remove AppCache from Firefox |
| 13:40 | <JakeA> | annevk: I'll reach out to them |
| 13:48 | <annevk> | JakeA: that site is really fast btw |
| 13:49 | <JakeA> | annevk: it's great isn't it? Just in time for my 23hr flight tomorrow too |
| 13:51 | <annevk> | JakeA: Oceania? |
| 13:51 | <JakeA> | annevk: Yeah, Sydney |
| 14:57 | <JakeA> | annevk: re https://github.com/slightlyoff/ServiceWorker/issues/609 - I can't see how client objects can have onmessage, windows have no access to their client |
| 15:14 | <iandevlin2> | annevk: appcache is being removed from Firefox? |
| 15:59 | <annevk> | iandevlin2: not yet, but with service workers coming the writing is on the wall |
| 15:59 | <iandevlin2> | annevk: ok, interesting |
| 15:59 | <Ms2ger> | "enemies of the heir beware"? |
| 15:59 | <JakeA> | Appcache has some security howlers. Chrome's security team would like to see it gone |
| 16:01 | <annevk> | Ms2ger: I'm not sure I comprehend the question |
| 16:02 | <jgraham> | annevk: Not a Harry Potter fan? |
| 16:02 | <annevk> | iandevlin2: I suspect there will be an announcements of sorts, once we've confirmed that service workers actually works |
| 16:02 | <annevk> | jgraham: been a while |
| 16:03 | <jgraham> | Think Chamber of Secrets |
| 16:05 | <annevk> | heh |
| 16:40 | <wanderview> | JakeA: can appcache be polyfilled with SW? (I'm not too familiar with appcache api) |
| 16:41 | <JakeA> | wanderview: appcache allows one tab to be using version n, and another to be using version n+1. I think that's the only part SW (deliberately) can't do |
| 16:42 | <wanderview> | JakeA: version of the SW script, right? I assume they could be using separate cache objects for versions of the site |
| 16:43 | <JakeA> | wanderview: yeah, but you can't tell which tab you're serving, so you can't give them items from different caches |
| 16:43 | <JakeA> | & there can only be one active SW in a registration |
| 16:43 | <wanderview> | JakeA: oh... right... that makes sense :-) |
| 16:44 | <JakeA> | You can get really close though. You can probably make it work under the hood by finding a way to allow that bit |
| 16:45 | <JakeA> | Eg, if an appcache SW creates a new registration for each version, but at the same scope, that would work (you can't do that with the currently exposed API) |
| 16:46 | <JakeA> | But that means the old tab would be using the old registration & active worker, whereas the new tab uses the new registration & active worker |
| 16:46 | <wanderview> | JakeA: or we could just de-orbit appcache... I was just wondering if polyfill was easy or not |
| 16:46 | <JakeA> | heh yeah |
| 17:24 | <annevk> | JakeA: can't you do that with Client objects? |
| 17:26 | <annevk> | Man, the pseudo-security on www-tag just keeps going |
| 17:26 | <annevk> | I wish there were at least some memes to alleviate some of the 386 pull |
| 17:50 | <TabAtkins> | Does somebody have Chrome Canary and can tell me what this logs? |
| 17:50 | <TabAtkins> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3381 |
| 17:50 | <miketaylr> | TabAtkins: heres what i got https://gist.github.com/miketaylr/ecbf5d97337dc871c90e |
| 17:50 | <TabAtkins> | Cool, it's still lolbroke. |
| 17:51 | <TabAtkins> | Just checking before I file a bug. |
| 17:51 | <TabAtkins> | That is one *broke-ass* background serialization. |
| 17:52 | <TabAtkins> | miketaylr: What's your Canary version? |
| 17:52 | <miketaylr> | TabAtkins: Version 42.0.2282.0 canary (64-bit) |
| 17:52 | <TabAtkins> | OS? |
| 17:52 | <TabAtkins> | Not that it matters, but I'm filling out the fields. |
| 17:53 | <miketaylr> | OSX Yosemite |
| 17:53 | <miketaylr> | 10.10.2 |
| 18:06 | <wanderview> | Domenic: so if we have the request.stream() to reify to a js stream... and request.text() to reify to text... does this mean that request.stream() will set bodyUsed to prevent request.text() from being called? |
| 18:06 | <wanderview> | even if the data has not been read? |
| 18:07 | <Domenic> | wanderview: bodyUsed is a whole 'nother thread of questions... but I think that is @horo-t's proposal. It seems somewhat self-consistent at least. |
| 18:07 | <wanderview> | I think thats how I would expect it to work if I was a developer... "I can only call one of these reify methods and then bodyUsed is set" |
| 18:07 | <Domenic> | Yeah. |
| 18:07 | <wanderview> | makes sense to me |
| 18:07 | <wanderview> | Domenic: sorry I'm always so confused about this stuff on github... I was once familiar with node streams... but its all a bit mixed up for me now |
| 18:08 | <Domenic> | wanderview: no problem! it's confusing stuff!! |
| 18:08 | <wanderview> | can't keep track of how things have changed recently |
| 18:15 | <wanderview> | annevk: why is request.text() a method and not a getter? |
| 18:15 | <annevk> | wanderview: because it returns a fresh promise |
| 18:16 | <annevk> | wanderview: request.text === request.text wouldn't hold |
| 18:16 | <wanderview> | annevk: I guess I would like to see a method like request.stream() so that it can set bodyUsed and return a stream on first call... then reject because of bodyUsed after that |
| 18:16 | <wanderview> | which of course can be done with a getter... but would be confusing |
| 18:16 | <annevk> | I see, rationale in the ticket? |
| 18:16 | <annevk> | I have to go now :-( |
| 18:17 | <wanderview> | annevk: k, thanks |
| 18:26 | <aklein> | annevk: re: microtasks, did you see my comment? |
| 20:14 | <Ms2ger> | So has anything been made public about this Spartan thing? |
| 20:24 | <miketaylr> | Ms2ger: seems like the public message is "more details soon" |
| 20:26 | <smaug____> | something new about spartan? |
| 20:26 | <TabAtkins> | And holograms. |
| 20:27 | <wanderview> | they've said "not webkit" |
| 20:35 | smaug____ | wonders what is happening @nokia. All the activate@w3c employees are gone? |
| 21:16 | <jarek> | Hi |
| 21:16 | <jarek> | Is <template> element allowed inside <svg> element? |
| 21:17 | <jarek> | The spec says it should inherit from HTMLTemplateElement : HTMLElement |
| 21:17 | <jarek> | it would make sense to make it more generic (TemplateElement : Element) |
| 21:19 | <Ms2ger> | No |
| 21:20 | <jarek> | SVG already has <defs> element which is has very similar functionality |
| 21:20 | <jarek> | but I guess it's already too late to rename HTML 5 <template> to <defs> |
| 21:28 | <jamesr___> | the html/svg ns split is not very useful nowadays |
| 21:38 | <tantek> | jamesr___: it was never useful, but rather XML/SGML dogma. |
| 21:39 | <jamesr___> | true, but dogma is less useful these days (not that it was terribly useful technically before, but it had more weight) |
| 22:00 | <TabAtkins> | jamesr___: I keep trying to get people to agree to merge the namespaces, but they keep whining about "compatibility" and other such nonsense. ^_^ |
| 22:13 | <annevk> | aklein: yeah, thanks for that |
| 22:13 | <annevk> | aklein: makes total sense, so it's just up to bz or heycam to tie things up |
| 22:27 | <aklein> | annevk: sounds good. I was just worried that you actually wished the ordering was always 1, 2, 3, and that I definitely didn't want to mess with |
| 22:29 | <annevk> | aklein: if I had better understood things from the get go I might have argued for that, but at this point I'd just like to have the implemented rules written down |
| 22:30 | annevk | read Spartan as SPARTAN, Opera's test infrastructure |
| 22:30 | <wanderview> | annevk: whenever I try to comment on one of those stream github issues... I end up feeling like a complete idiot... not sure my opinion should really matter much :-) |
| 22:32 | <annevk> | wanderview: please just view it as having a very different perspective, which is very valuable |
| 22:33 | <wanderview> | annevk: I just want someone to tell me what bodyUsed means if someone has read half the body through the stream.... its really weird for me if bodyUsed==false there |
| 22:34 | <annevk> | wanderview: I think several views are conflated |
| 22:35 | <wanderview> | annevk: I gotta run to dinner, but I'll pick up being confused in the morning! good night! |
| 22:35 | <annevk> | wanderview: e.g. I think Domenic wants text() et al to just consume the stream (whatever is in there at the moment) and decode as appropriate (ignoring anything like bodyUsed) |
| 22:35 | <annevk> | wanderview: hah okay, nn |
| 22:41 | <gsnedders> | annevk: Spartan: better tested than SPARTAN. |