2015-11-02
[23:55:49.0000] <annevk>
wanderview: https://github.com/whatwg/fetch/pull/146

[01:50:21.0000] <philipj>
Ms2ger: How is one supposed to use promise_rejects in testharness.js? You added it but I can't see it used anywhere.

[01:50:35.0000] <philipj>
annevk: yt?

[01:52:01.0000] <Ms2ger>
philipj, https://github.com/w3c/web-platform-tests/pull/1490/files

[01:52:24.0000] <Ms2ger>
(In case you ever wanted to write tests for webcrypto: don't bother)

[01:52:31.0000] <annevk>
philipj: more or less

[01:56:02.0000] <philipj>
Ms2ger: so it depends on promise_rejects being called before the then() and catch() inside promise_test are registered. I thought maybe it was intended to be used together with a bare async_test.

[01:56:42.0000] <Ms2ger>
You ask me like you think I have code from a year ago paged in :)

[01:57:16.0000] <gsnedders>
Well, you should. Obviously.

[01:57:17.0000] <philipj>
Ms2ger: I expect nothing less from you :)

[01:57:30.0000] <philipj>
annevk: Do you expect that Gecko will implement webkitMatchesSelector()?

[01:58:13.0000] <philipj>
annevk: And do you have the full story about how it went from matchesSelector() to just matches()?

[01:58:36.0000] <annevk>
philipj: I expect we will

[01:58:50.0000] <Ms2ger>
I expect we have

[01:59:07.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=1216193 shipping in 44

[01:59:26.0000] <philipj>
Ms2ger: was this the first webkit-prefixed method to be added to Gecko?

[01:59:30.0000] <annevk>
philipj: not the full story, I ended up taking it from http://dev.w3.org/2006/webapi/selectors-api2/ which I assumed had agreement

[01:59:47.0000] <annevk>
philipj: I believe it was renamed because the other name was too long

[01:59:59.0000] <philipj>
annevk: I'm using this as a case study in the talk Rick Byers and I are giving at BlinkOn

[02:00:26.0000] <annevk>
philipj: it has been matches() since June 2012 it seems in the draft

[02:00:41.0000] <annevk>
philipj: well, per the published draft, not sure when it changed in the editor's copy

[02:01:07.0000] <philipj>
annevk: jQuery noticed the change in 2013-03: http://bugs.jquery.com/ticket/13629

[02:02:40.0000] <philipj>
Ms2ger: grep says the answer is yes. Would you happen to know what the first webkit-prefixed CSS properties in Gecko were?

[02:05:01.0000] <philipj>
Ms2ger: And if you have any good stories about site compat that contains lessons for Blink developers, I'm making a collection :)

[02:07:48.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=837211 is relevant

[02:08:01.0000] <Ms2ger>
Also https://bugzilla.mozilla.org/show_bug.cgi?id=1132745

[02:08:13.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=1160281

[02:09:08.0000] <annevk>
philipj: ah right, only the prefix variant was implemented

[02:09:34.0000] <annevk>
philipj: that's probably why editors assumed the change was safe while in fact it was already too late

[02:14:35.0000] <philipj>
annevk: Right, it was prefixed only for a very long time, and I guess this was before anyone had understood what fallback code looks like, or they thought that libraries would update and propagate the change.

[02:15:08.0000] <philipj>
Ms2ger: thanks!

[02:15:25.0000] <Ms2ger>
> they thought that libraries would update and propagate the change.

[02:15:26.0000] <Ms2ger>
lol

[02:15:40.0000] <philipj>
Ms2ger: right, but there must have been a time where that seemed plausible

[02:16:09.0000] <gsnedders>
and they thought that people would update the libraries

[02:17:59.0000] <philipj>
gotta go

[02:26:12.0000] <jgraham>
/me doesn't remember a time when people believed that libraries would update

[02:26:20.0000] <jgraham>
Well maybe in 2005 or something

[02:26:37.0000] <jgraham>
"people" being clueful people ofc

[02:26:41.0000] <jgraham>
Some peopel still think that

[02:32:08.0000] <annevk>
philipj: I think it's very similar to the fullscreen situation

[02:32:38.0000] <annevk>
philipj: which I suppose is largely my fault for insisting fullscreen is a single word

[04:07:44.0000] <annevk>
mkwst: https://github.com/whatwg/fetch/issues/39#issuecomment-141043738

[04:08:51.0000] <annevk>
Would https://github.com/whatwg/fetch/issues/19 be fitting for the HTML Standard?

[04:08:58.0000] <annevk>
/me isn't quite sure where to move it

[04:49:52.0000] <philipj>
annevk: yep, I guess that one's on you :)

[04:50:27.0000] <annevk>
fullScreen is fairly hideous though

[05:58:23.0000] <Ms2ger>
annevk, so is webkitFullScreen ;)

[06:03:31.0000] <philipj>
annevk: navigator.onLine is my favorite capitalization

[06:06:13.0000] <gsnedders>
philipj: wat.

[06:07:24.0000] <philipj>
gsnedders: awesome, right?

[06:08:00.0000] <gsnedders>
philipj: if by "awesome" you mean "makes me want to rip my eyes out", yes.

[06:08:24.0000] <philipj>
yes, isn't that what the dictionary says?

[06:09:18.0000] <gsnedders>
uhhh

[07:27:36.0000] <zcorpan>
https://zcorpan.github.io/live-webvtt-viewer/

[07:28:16.0000] <zcorpan>
i don't know why it doesn't work in firefox

[07:34:27.0000] <gsnedders>
Hixie: the csswg-test contains tests originally from hixie.ch that have been imported, but with some images. I presume you're happy licensing-wise to include them?

[07:34:40.0000] <gsnedders>
Hixie: with some images still referencing hixie.ch, I mean

[07:56:05.0000] <rits>
annevk: Hello, submitted the proposal, do you want to suggest any particular ideas for it, the deadline is today for the proposal submissions

[08:08:25.0000] <wanderview>
JakeA: ping

[08:08:54.0000] <wanderview>
sorry, unping

[08:11:05.0000] <JakeA>
wanderview: no worries! Let me know if there's anything else you don't need me for :D

[08:11:17.0000] <wanderview>
I found the text in the spec

[08:11:57.0000] <wanderview>
JakeA: was wondering if the waitUntil() timeout killing a long running worker was spec'd to fail install... and it is

[08:12:27.0000] <JakeA>
ahhhh, yeah, that sounds like the right thing to do

[08:12:40.0000] <wanderview>
" If task is discarded or the script has been aborted by the termination of installingWorker, set installFailed to true."

[08:36:31.0000] <hsivonen>
https://streams.spec.whatwg.org/#transform-stream talks about a text decoder being a kind of a transform stream

[08:36:34.0000] <hsivonen>
but

[08:36:54.0000] <hsivonen>
streames otherwise seem to deal with bytes while text in JS is UTF-16

[08:37:05.0000] <hsivonen>
are there actually byte streams and UTF-16 streams?

[08:37:27.0000] <wanderview>
hsivonen: ReadableStream() can pass chunks of any type....  its up to the producer of the stream to say what the type is

[08:37:32.0000] <hsivonen>
searching the spec for the obvious words doesn't result in search matches explaining this

[08:38:04.0000] <hsivonen>
wanderview: ok. https://streams.spec.whatwg.org/#chunk could use way more explanatory text

[08:38:56.0000] <wanderview>
hsivonen: if you don't mind, best way to get it fixed is to file an issue: https://github.com/whatwg/streams/issues/new

[08:39:04.0000] <hsivonen>
wanderview: ok

[08:40:06.0000] <hsivonen>
is there a place where text decoding in Streams is being specced for the case where the stream with Uint8Array chunks doesn't guarantee chunks to contain complete byte sequences from the point of view of an encoding?

[08:41:02.0000] <hsivonen>
i.e. does the text decoder transform exist spec-wise yet?

[08:41:54.0000] <wanderview>
hsivonen: I'm not sure if work has begin to integrate streams into other APIs yet, besides fetch()

[08:42:03.0000] <wanderview>
hsivonen: I guess Domenic would know, though

[08:42:42.0000] <hsivonen>
wanderview: OK. thanks.

[08:43:06.0000] <wanderview>
hsivonen: there is some question if things should take streams or Response objects... since Response objects also have headers

[08:47:36.0000] <wanderview>
hsivonen: it seems you could also file a bug against the encoding spec to add streams support: https://github.com/whatwg/encoding/issues

[08:47:49.0000] <hsivonen>
wanderview: OK

[08:54:01.0000] <hsivonen>
it looks like TextDecoder spec already has streaming support but eof handling in the streaming case doesn't work

[08:54:04.0000] <hsivonen>
as in

[08:54:07.0000] <hsivonen>
doesn't work in our impl

[08:54:16.0000] <hsivonen>
and I don't see the spec covering the case properly

[08:56:52.0000] <wanderview>
JakeA: what about if the browser timeouts out activateEvent.waitUntil()... is the SW still active?  the spec suggests it should be... see steps 16 and 17 here: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#activation-algorithm

[09:05:37.0000] <wanderview>
/me files an issue

[09:06:33.0000] <annevk>
rits: I was planning to review the proposals sometime this week, several have applied thus far

[09:06:46.0000] <annevk>
rits: no thoughts at the moment

[09:07:01.0000] <annevk>
wanderview: did you see my request for review?

[09:07:16.0000] <annevk>
wanderview: https://github.com/whatwg/fetch/pull/146

[09:07:33.0000] <wanderview>
annevk: no, I did not

[09:07:46.0000] <wanderview>
I'll look today

[09:08:34.0000] <rits>
annevk: ok sure :)

[09:10:45.0000] <annevk>
wanderview: thank you

[09:11:16.0000] <annevk>
rits: still recovering a bit from the jet lag too, got back last night

[09:12:01.0000] <wanderview>
JakeA: found the answer to my last question... filed a spec issue for a note, though: https://github.com/slightlyoff/ServiceWorker/issues/776

[09:13:44.0000] <rits>
annevk: oh, no problem, you took out the time to review my application in your busy schedule that was enough for me, thanks a lot for that :)

[09:19:38.0000] <annevk>
wanderview: btw, opaque stream is basically a stream for all intents and purposes but only privileged code (read: the user agent) gets to see the bytes

[09:21:16.0000] <annevk>
wanderview: and thank you in advance for the review

[09:24:41.0000] <wanderview>
annevk: this seems to create a whole new vector of opaque tainting to be implemented...

[09:25:04.0000] <wanderview>
annevk: pass an opaque stream to a DOM implemented decoder, and the decoder has to produce an opaque stream, right?

[09:25:10.0000] <wanderview>
etc, etc

[09:30:42.0000] <yhirano_>
wanderview: what do you mean by "a DOM implemented decoder"?

[09:31:23.0000] <wanderview>
yhirano_: like if https://encoding.spec.whatwg.org/ grew support for streams... it would in theory be a transform

[09:31:40.0000] <wanderview>
yhirano_: yet, if it took an opaque stream it would now have to be smart enough to pass on the opaqueness, etc

[09:32:47.0000] <wanderview>
yhirano_: maybe we need this, but it seems to add some non-trivial complexity

[09:33:26.0000] <wanderview>
yhirano_: for example, var r = new Response(url, { body: anOpaqueBody }) gives a non-opaque Response with an opaque body... that has to be propagated through Cache, etc...

[09:33:27.0000] <yhirano_>
wanderview: Body.text() and so on don't recognize opaque streams. I thought it would be similar for other decoders

[09:35:03.0000] <wanderview>
yhirano_: well I guess thats the question... what recognizes these things and what doesn't... its hard to tell from the current spec issue

[09:38:37.0000] <yhirano_>
wanderview: agreed.

[11:49:04.0000] <Krinkle>
I'm trying to figure out what the intended guarantees are with regards to requestIdleCallback. Specifically around what happens if the request context gets closed before the queue is exhausted. Maybe when the second parameter is passed, it is expected to run in case of page unload? I'm implementing a very basic fallback but want to make sure behaviour is the

[11:49:04.0000] <Krinkle>
same.

[11:49:29.0000] <Krinkle>
The semantics rather.

[14:10:48.0000] <jsbell>
odinho: Just for the sake of process, do you want to give the objectStoreNames test approval via https://critic.hoppipolla.co.uk/r/5899 ?

[14:18:16.0000] <odinho>
I prefer critic, -- but for some reason didn't use it on the first of your reviews :)

[14:19:11.0000] <odinho>
jsbell: critic is not required, -- can use the GH review system (though it's quite bad for bigger reviews) :)  But I clicked the button in critic now :9

[14:20:13.0000] <jsbell>
odinho: Okay, just don't want to face the angry wrath of j-graham :)

[14:22:55.0000] <odinho>
^_*

[14:36:53.0000] <jsbell>
odinho: want to do the merge? (I seem to recall instructions saying "do not hit the merge button in the web ui" but not finding them now...)

[14:37:05.0000] <jsbell>
Sorry, feeling rusty. :P

[14:41:14.0000] <odinho>
:P


2015-11-03
[23:37:26.0000] <annevk>
Hmm, still no review

[00:22:49.0000] <annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2283

[00:23:36.0000] <annevk>
jgraham: changes seem correct

[00:52:01.0000] <jgraham>
annevk: You don't have the ability to merge?

[00:52:22.0000] <annevk>
jgraham: no

[00:53:16.0000] <jgraham>
annevk: Fixed that, thanks for the review

[02:24:44.0000] <zcorpan>
annevk: Domenic: do you have an objection to changing the return value for add() in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29061 ?

[02:29:32.0000] <Ms2ger>
/me is not convinced

[02:33:59.0000] <zcorpan>
Ms2ger: why not?

[02:48:01.0000] <annevk>
zcorpan: the known tokens approach seems better

[02:49:09.0000] <yoav>
annevk: pointer to that approach?

[02:49:23.0000] <annevk>
yoav: it's explained in the issue

[02:50:33.0000] <yoav>
So the approach outlined in comment 8?

[02:51:48.0000] <zcorpan>
annevk: it makes legacy browsers go into the "supported" branch

[02:54:08.0000] <zcorpan>
iframe.sandbox.add('foo'); /* ignore */ if (iframe.sandbox.has('foo')) { /* supported, or legacy browser */ }

[02:56:04.0000] <zcorpan>
i don't mind doing what comment 8 says (sans throwing), but it seems nice to have legacy browsers go into the unsupported branch, which is what boolean return value for add() does

[02:56:55.0000] <zcorpan>
i.e. if (iframe.sandbox.add('foo')) { /* supported */ } else { /* unsupported or legacy browser */ }

[02:58:13.0000] <yoav>
+1 to the latter

[03:05:08.0000] <yoav>
zcorpan: the `toggle()` case https://dom.spec.whatwg.org/#dom-domtokenlist-toggle seems more complicated to handle then `add()`, since it already returns false in various cases

[03:05:47.0000] <yoav>
we could also add that it returns false when trying to add an invalid token

[03:07:12.0000] <yoav>
So add to https://dom.spec.whatwg.org/#dom-domtokenlist-toggle before step 4.2 "if token is invalid, return false"

[03:08:09.0000] <zcorpan>
so the semantic right now for toggle is to return false if the token was removed, and return true if it's added, afaict

[03:09:46.0000] <zcorpan>
maybe we should think about what remove() should do, and then toggle() becomes clearer what it should do

[03:11:05.0000] <zcorpan>
i think remove/contains don't need to validate. and toggle should then only validate just before adding, not for removing

[03:12:27.0000] <zcorpan>
but that is mostly arm-chair reasoning on my part. would be nice to walk though a real example that uses toggle

[03:15:35.0000] <yoav>
zcorpan: FWIW, I agree with your arm-chair reasoning

[03:15:55.0000] <yoav>
since if an invalid token would never get in, there's no point in validating on the way out

[03:16:22.0000] <yoav>
and for feature detection purposes, a single method is enough

[03:17:08.0000] <Ms2ger>
I think it would be really weird if add() only worked on some strings

[03:17:25.0000] <Ms2ger>
Btw, how does this scale to classList?

[03:18:40.0000] <yoav>
classList won't implement a validation algorithm, which means everything is valid

[03:21:35.0000] <zcorpan>
yoav: invalid things could get in from the html parser or .rel = 'foo bar'; or setAttribute and so on

[03:22:00.0000] <yoav>
zcorpan: good point

[03:23:07.0000] <yoav>
still, if all we need is feature detection (which is the use case at hand for both iframe and link), add/toggle would be enough

[03:24:04.0000] <yoav>
also, being unable to remove invalid values added elsewhere would be weird

[03:25:03.0000] <Ms2ger>
Note that toggle already returns a boolean

[03:28:16.0000] <zcorpan>
Ms2ger: right

[03:31:12.0000] <zcorpan>
/me only finds test cases using toggle()

[03:33:35.0000] <zcorpan>
so back at the armchair, the boolean return value would be consistent with current toggle: if the token is added, return true, otherwise return false

[03:33:52.0000] <zcorpan>
and we only add the token in add() and toggle() if it's valid

[03:34:17.0000] <Ms2ger>
Why?

[03:35:14.0000] <Ms2ger>
I think that would be very surprising, and I'm not convinced it

[03:35:19.0000] <Ms2ger>
'd be compatible

[03:35:27.0000] <zcorpan>
so that you can check if a keyword is supported, and have current browsers fall into the "unsupported" branch

[03:35:54.0000] <Ms2ger>
That's what the return value is for

[03:36:08.0000] <Ms2ger>
I don't see a use case for dropping the token on the floor too

[03:36:13.0000] <zcorpan>
Ms2ger: oh, do you just find the validation thing surprising?

[03:36:19.0000] <zcorpan>
ok

[03:36:47.0000] <zcorpan>
i can live with that, but anne and dominic argued for that, to be consistent with "limited to only known values"

[03:38:59.0000] <Ms2ger>
Doesn't that still setAttribute()?

[03:39:09.0000] <Ms2ger>
/me pulls up the spec

[03:39:18.0000] <zcorpan>
/me parse error

[03:39:32.0000] <Ms2ger>
"and on setting, the content attribute must be set to the specified new value."

[03:40:00.0000] <Ms2ger>
So what I suggested is more in line with "limited to only known values"

[03:40:17.0000] <zcorpan>
....yes, yes you're right

[03:54:45.0000] <yoav>
Ms2ger: makes sense to me

[03:55:36.0000] <Ms2ger>
Always nice if existing practice agrees with you :)

[04:49:21.0000] <zcorpan>
should DOMTokenList be ascii-case-insensitive for <link rel> and <iframe sandbox>?

[04:58:16.0000] <Ms2ger>
And classList in quirks?

[05:07:47.0000] <annevk>
Ms2ger: not really sure if that is more in line

[05:08:10.0000] <annevk>
Ms2ger: perhaps if you're only comparing the setter and add()

[05:09:39.0000] <Ms2ger>
These seem the relevant things to compare

[05:11:54.0000] <annevk>
Ms2ger: so would then compare the getter with the iterator?

[05:12:29.0000] <annevk>
Ms2ger: it's a rather incomplete model

[05:13:04.0000] <Ms2ger>
Sure

[05:13:50.0000] <Ms2ger>
But there doesn't seem to be much precedent for dropping changes to content attributes

[05:14:06.0000] <annevk>
It just wouldn't propagate to the content attribute

[05:14:33.0000] <annevk>
There isn't much precedent for this kind of API either way

[05:21:59.0000] <yoav>
Took a stab at adding the hooks: https://github.com/whatwg/dom/pull/103

[05:54:53.0000] <annevk>
yoav: I think only doing something with add() is really weird

[05:55:38.0000] <yoav>
annevk: do you think we need to add something similar to toggle()?

[05:55:46.0000] <yoav>
or also remove and contains?

[05:56:28.0000] <yoav>
I can think of a way to easily add a false return for toggle, less so for remove and contains

[05:57:58.0000] <annevk>
yoav: the other problem I see is that this doesn't deal with case-sensitivity

[06:00:21.0000] <yoav>
annevk: yeah, I saw the discussion here after I sent the PR. I'll add case sensitivity to the validation algo

[06:01:24.0000] <annevk>
But in general this design just seems rather weird

[06:02:56.0000] <yoav>
annevk: something in particular that bothers you, outside of the issues you already mentioned?

[06:03:15.0000] <yoav>
/me gotta go now, but will check logs in a short while

[06:03:21.0000] <annevk>
yoav: I can't quite put my finger on it :-/

[06:04:18.0000] <annevk>
Something with having this new internal slot and only add() using it for a return value that indicates support and not wether something got added or not

[06:04:23.0000] <annevk>
It just seems rather confusing

[06:05:21.0000] <annevk>
And by not tying that "supported list" to values that can actually be added there's a fair chance implementations will not keep the two in lockstep

[06:06:05.0000] <annevk>
Which the getter/setter design of "known values" does not have in the slightest

[06:43:04.0000] <annevk>
wanderview: good morning!

[06:43:16.0000] <annevk>
wanderview: and also: https://github.com/whatwg/fetch/pull/146 😊

[06:45:57.0000] <wanderview>
annevk: looking

[06:53:55.0000] <annevk>
wanderview: ta

[06:54:10.0000] <wanderview>
np... kind of nit picky I guess

[06:54:19.0000] <annevk>
wanderview: nooo I think you found a problem

[06:55:30.0000] <wanderview>
annevk: did you guys ever get to discuss foreign fetch at tpac?

[06:57:06.0000] <yoav>
annevk: ms2ger raised concerns that changing the behavior of "add()" is likely to result in web compat issues https://www.w3.org/Bugs/Public/show_bug.cgi?id=29061#c17

[06:57:22.0000] <yoav>
I'm fine with it either way

[06:58:53.0000] <annevk>
wanderview: we did briefly

[06:58:57.0000] <Ms2ger>
Not sure about "likely", just "more likely"

[06:58:57.0000] <annevk>
wanderview: but not in detail

[07:37:19.0000] <annevk>
hsivonen: https://twitter.com/ken_lunde/status/661351862155669506

[07:38:43.0000] <wanderview>
annevk: so basically the f2f was still focused on "v1" things?

[07:38:58.0000] <annevk>
wanderview: yes

[08:03:12.0000] <hsivonen>
annevk: :-(

[09:05:56.0000] <gsnedders>
/me wonders how to sanely UA sniff IE9–11

[09:06:11.0000] <gsnedders>
Purely visual bug, so no way to check it. <_<


2015-11-04
[16:06:39.0000] <rniwa>
MikeSmith: yt?

[16:34:37.0000] <MikeSmith>
botie, inform rniwa here now

[16:34:38.0000] <botie>
will do

[23:59:30.0000] <hsivonen>
github is supposed to be great for specs, yet https://w3c.github.io/webappsec-referrer-policy/ is a month out of date

[00:08:28.0000] <hsivonen>
annevk_: you wanted the DOM attribute to be referrerPolicy but the spec says referrerpolicy. are you OK with that or is there a spec bug?

[00:47:41.0000] <annevk>
hsivonen: that seems like a bug

[00:49:19.0000] <annevk>
hsivonen: does the specification even define IDL?

[00:53:25.0000] <annevk>
hsivonen: I filed https://github.com/w3c/webappsec-referrer-policy/issues/3 to keep track

[01:18:18.0000] <annevk>
Ms2ger: https://github.com/whatwg/html/pull/304

[01:19:09.0000] <Ms2ger>
What's wrong with my commit messages?

[01:19:26.0000] <Ms2ger>
Also, no point in squashing, they're separate changes

[01:38:05.0000] <yoav>
Domenic/annevk: When talking about running a validation step in the value setter on https://github.com/whatwg/dom/pull/103#issuecomment-153641224, where you talking about https://dom.spec.whatwg.org/#dom-attr-value ?

[01:39:10.0000] <annevk>
yoav: no, I think he meant DOMSettableTokenList, if anything

[01:39:20.0000] <annevk>
yoav: though I'm not sure that's needed

[01:39:46.0000] <yoav>
OK, that makes more sense

[01:40:29.0000] <yoav>
annevk: leaving it out for now then

[01:44:30.0000] <Domenic>
I think it's needed...

[01:44:37.0000] <annevk>
Ms2ger: you can just force push to your Ms2ger:hyperlink branch

[01:44:52.0000] <Ms2ger>
Not worth my time

[01:44:54.0000] <annevk>
Domenic: why? that just forwards to setAttribute() today

[01:45:16.0000] <annevk>
Ms2ger: wow

[01:45:19.0000] <Domenic>
annevk: hmm, fair...

[01:45:27.0000] <Domenic>
wait, that was a real ragequit?

[01:45:35.0000] <annevk>
I guess so

[01:45:38.0000] <Domenic>
wow

[01:47:46.0000] <Domenic>
Sigh, Attr. Just when I reimplemented them in jsdom as being simple non-Nodes, too...

[01:47:48.0000] <annevk>
Ms2ger: does that mean you object to any of us merging the changes?

[01:49:50.0000] <jgraham>
FWIW I think being asine about things like the length of commit messages is a net negative

[01:50:33.0000] <jgraham>
It wastes the time of people who have put in the effort to make a change, but the benefits provided are super-marginal

[01:50:37.0000] <yoav>
Domenic: Were you referring to the DOMSettableTokenList's setter?

[01:51:04.0000] <Domenic>
yoav: yeah, but I guess annevk's point that it currently just forwards to setAttribute is convincing enough to leave as-is...

[01:51:06.0000] <annevk>
jgraham: yeah, don't disagree, I was happy to do it for Ms2ger

[01:51:13.0000] <annevk>
jgraham: not sure what to do now though

[01:51:19.0000] <yoav>
Domenic: OK

[01:51:56.0000] <Ms2ger>
The commits are still there, you can make whatever change you like when merging

[01:52:02.0000] <jgraham>
annevk: Pull his branch, create your own PR and merge that

[01:52:11.0000] <Ms2ger>
I just have no interest in spending any more time on it

[01:53:05.0000] <Domenic>
yes, in the future please just say "OK, can you do that for me please" instead of closing the PR...

[01:53:15.0000] <jgraham>
/me wonders what actual word he was trying to use

[01:56:00.0000] <Ms2ger>
That would sound like I think it's a good idea

[02:24:43.0000] <gsnedders>
jgraham: OTOH, I think commit messages like "update webplatform-tests" are a net negative

[02:24:54.0000] <gsnedders>
jgraham: there's some middle ground to be found here

[02:28:59.0000] <annevk>
Somewhat sad that https://github.com/whatwg/html/graphs/contributors is still broken

[02:38:51.0000] <annevk>
Domenic: btw, happy to have you here, but I'd rather you enjoy your vacation a bit more

[02:39:24.0000] <Domenic>
annevk: yeah, just took a couple hours downtime at the new hotel to catch up on things :). Going back out into Tokyo momentarily!

[02:39:26.0000] <jgraham>
gsnedders: I agree that sucky commit messages suck. I disagree that good commit messages that are 60 characters long are unacceptable

[02:40:05.0000] <jgraham>
In the case of wpt the fact that we really want direct contributions from browsers ofc affects the amount of leeway we are prepared to have in the style

[03:44:06.0000] <annevk>
wanderview: https://github.com/whatwg/fetch/pull/146

[03:44:30.0000] <annevk>
mkwst: you might want to have a look too

[03:45:06.0000] <annevk>
mkwst: it's pretty easy to make a refactor that would enable code sharing between service worker responses and network responses

[04:24:21.0000] <hsivonen>
annevk: thanks

[05:01:42.0000] <annevk>
hsivonen: would you be okay with going from "Encoding Standard" to "Text Encoding Standard"?

[05:02:23.0000] <annevk>
I kinda like single-word titles, but I don't feel super strongly about it either

[05:13:04.0000] <hsivonen>
annevk: I think the current title is cooler, but I wouldn't oppose to the longer title. Where is the longer title coming from? Didn't even the W3C go to CR with the current title?

[05:18:05.0000] <philipj>
Domenic: a quick experiment to see if making Attr not a Node in Blink would actually allow any crufty code to be removed would be interesting

[05:18:42.0000] <philipj>
I kind of suspect it won't, it's like these objects inherit a lot of useles stuff that just doesn't matter, and ignoring those extra bits is ~0 lines of code

[05:55:14.0000] <jgraham>
hsivonen: dsinger (I think) was complaining that lots of/all data other than text also has an encoding (e.g. media files)

[07:03:48.0000] <annevk>
hsivonen: https://github.com/whatwg/encoding/issues/11

[07:03:59.0000] <annevk>
hsivonen: I agree about the current title being cooler

[07:04:50.0000] <annevk>
philipj: yeah, I was thinking about the changes required to the DOM Standard and I don't think it amounts to much

[07:05:07.0000] <annevk>
philipj: there's a few extra places that have to consider Attr, but not many

[07:20:47.0000] <annevk>
wanderview: yeah, heard that before about HTML diff :-/

[07:20:58.0000] <annevk>
wanderview: the other problem is spotting markup errors

[07:31:53.0000] <wanderview>
annevk: its really just a way of saying "don't blame me if I missed something" :-)

[09:26:32.0000] <annevk>
MikeSmith: https://www.w3.org/Bugs/Public/show_activity.cgi?id=26734 last change is spam

[09:26:38.0000] <annevk>
MikeSmith: do we have to undo that manually?

[10:44:48.0000] <jsx>
What does a "document environment" mean? A web page?

[11:23:05.0000] <wanderview>
jsx: this suggests it means a window or iframe: https://html.spec.whatwg.org/#document-environment

[11:24:57.0000] <jsx>
Thanks wanderview.


2015-11-05
[18:46:30.0000] <MikeSmith>
annevk: yeah I will undo it manually

[18:51:26.0000] <MikeSmith>
annevk: so I think I undid it, and also disabled that account

[18:51:58.0000] <MikeSmith>
checking bugzilla, it seems that was the only bug he/she changed

[19:11:36.0000] <cluelesscoder>
hi, out of curiosity has there ever been a discussion on adding an insertAfter method similar to the insertBefore method to the native DOM API? so that we don't have to manually add the function described at http://stackoverflow.com/questions/4793604/how-to-do-insert-after-in-javascript-without-using-a-library if not using a library

[19:17:32.0000] <cluelesscoder>
I guess it's not necessary if you figure out the next sibling and insertBefore always

[21:28:58.0000] <miketaylr>
cluelesscoder: isn't that node.append()? https://dom.spec.whatwg.org/#dom-parentnode-append

[23:23:10.0000] <annevk_>
cluelesscoder: miketaylr: or just after()

[23:25:11.0000] <miketaylr>
oh right, nice.

[23:32:23.0000] <Domenic>
annevk: I don't really see a reason to change the title of Encoding...

[23:34:10.0000] <annevk>
Domenic: yeah, it seems somewhat clear that all the other encodings are a bit secondary

[23:35:08.0000] <annevk>
Domenic: I don't see a strong reason to change it, but I also don't really have a strong reason not to (other than consistency with other WHATWG specification names)

[23:49:27.0000] <Domenic>
Yeah I mean sticking with what already works seems like the best position. No need to change references etc. Changing a title is fairly disruptive.

[23:49:59.0000] <Domenic>
There's no actual evidence of confusion either this is just feedback from W3C AC Forum upon the PR transition for the fork.

[23:53:15.0000] <annevk>
Oh I see

[23:53:45.0000] <annevk>
To be fair, they did give feedback to us, not www-international

[00:09:58.0000] <annevk>
Domenic: thank you, closed https://github.com/whatwg/encoding/issues/11

[00:59:02.0000] <zcorpan>
live webvtt viewer in firefox continually uses CPU which makes my laptop hot and noisy :-( don't know what's up with that

[01:38:12.0000] <jgraham>
zcorpan: Link

[01:38:13.0000] <jgraham>
?

[01:44:22.0000] <Ms2ger>
https://zcorpan.github.io/live-webvtt-viewer/

[01:49:18.0000] <zcorpan>
jgraham: ^ (sorry for delay)

[01:50:56.0000] <jgraham>
zcorpan: np

[01:54:06.0000] <jgraham>
zcorpan: Just having it open doesn't seem to use cpu for me. Try the performance inspector in devtools? It's a little hard to figure out what it's on about, but you might see something obvious?

[01:56:44.0000] <zcorpan>
jgraham: hmmm. seems it happens when editing and then clicking "save to address bar", firefox paints a lot after that

[01:59:49.0000] <zcorpan>
putting a breakpoint in onhashchange suggests it only runs that once

[02:03:07.0000] <jgraham>
File a bug?

[02:03:16.0000] <zcorpan>
yep sure

[02:21:38.0000] <zcorpan>
https://bugzilla.mozilla.org/show_bug.cgi?id=1221942

[02:27:40.0000] <annevk>
mkwst: pretty sure bifurcation and rlbmoz are the same

[02:28:07.0000] <annevk>
mkwst: and I thought the idea was to just put it in Fetch directly

[02:42:42.0000] <mkwst>
annevk: I don't want a separate normative document. I do want something I can point agl to, and I don't think he's going to be thrilled with a diff to a spec he's probably never read. :)

[02:43:36.0000] <annevk>
mkwst: okay

[02:43:51.0000] <annevk>
mkwst: convincing agl seems worthwhile

[02:45:27.0000] <mkwst>
annevk: I thought about it a bit on the flight back, and I think I'm convinced. I don't have any time to actually implement an experiment, which is a bit frustrating.

[02:45:48.0000] <mkwst>
but I'll at least help Richard document it, and start some discussion with folks who care.

[02:45:55.0000] <annevk>
/me wonders what https://twitter.com/mad_p/status/662199914420563968 is about

[02:46:14.0000] <annevk>
mkwst: we have someone who can implement in Q1

[02:46:45.0000] <annevk>
mkwst: Richard assured me he has the relevant powers to make things happen

[02:47:40.0000] <mkwst>
annevk: Can Richard find someone to work on Chrome too? I'm buried. :)

[02:47:47.0000] <annevk>
heh

[02:49:09.0000] <annevk>
mkwst: so, https://github.com/whatwg/fetch/issues/39

[02:49:28.0000] <annevk>
mkwst: I want to know whether to kill the entire feature or whether some of it has merit

[02:49:33.0000] <mkwst>
Looking at it right now, but I have lost any and all context I might once have had. :)

[02:50:53.0000] <annevk>
mkwst: a lot of the background is https://github.com/slightlyoff/ServiceWorker/issues/412

[02:51:07.0000] <annevk>
mkwst: starting from https://github.com/slightlyoff/ServiceWorker/issues/412#issuecomment-58646963

[02:53:42.0000] <annevk>
mkwst: in addition to that, we have the possibility of limiting to CORS / same-origin

[02:56:52.0000] <mkwst>
(sifting through email to find the thread that led me to comment on the bug)

[03:00:49.0000] <mkwst>
annevk: So, my main concern is with 'only-if-cached'. I think the others are probably fine.

[03:01:34.0000] <mkwst>
annevk: I don't think CORS helps, as CORS just means that the server gave permission to read the data. It doesn't give the reader permission to know that the data is there to be read.

[03:01:54.0000] <annevk>
mkwst: yeah, I guess only same-origin would help

[03:01:58.0000] <mkwst>
annevk: Same-origin means that the reader has server logs to fall back on to determine that the user read the data already. Cross-origin loses that benifit.

[03:02:09.0000] <mkwst>
Running to a thing. Back in ~30m.

[03:02:36.0000] <annevk>
mkwst: right, but at least if you restrict to same-origin you cannot use it as a supercookie

[03:03:01.0000] <annevk>
mkwst: it seems force-cache has similar issues since force-cache plus a timer is effectively equivalent to only-if-cached

[03:06:05.0000] <annevk>
So yeah, I guess those two should be removed

[03:08:11.0000] <annevk>
And I guess I should also remove them from the model for now, I don't think any specification relies on them and I don't think we'd want any specification to rely on them

[03:15:39.0000] <annevk>
Though if force-cache has that problem... So would first doing a request using mode "default" and then doing one with "reload" and timing the difference...

[03:16:18.0000] <annevk>
Once timing attacks are okay you can probe the cache pretty effectively, and probably more effectively due to these parameters existing

[03:17:11.0000] <annevk>
So perhaps restricting it to same-origin would still be best... As long as user agents clear that at the same rate as cookies we wouldn't expose anything new

[03:17:41.0000] <annevk>
JakeA: ^^

[03:22:03.0000] <JakeA>
annevk: sounds good to me. In terms of what I've heard developers asking for, they're more interested in bypassing the cache than going cache-only

[03:22:51.0000] <annevk>
JakeA: it's somewhat annoying that even offering that makes timing attacks easier

[03:22:51.0000] <JakeA>
Although cache-only would be nice for web fonts, to emulate font-display:optional

[03:24:18.0000] <JakeA>
annevk: isn't this just as easy with ?blahblah on the end of the URL?

[03:24:45.0000] <annevk>
JakeA: in practice it might be

[03:25:02.0000] <annevk>
JakeA: not sure if that's sufficient to convince the security teams

[04:02:20.0000] <johnme>
annevk: blink folks are asking if we've gotten a TAG review for notifications. I couldn't find one, so shall I go ahead and file one at https://github.com/w3ctag/spec-reviews/issues ?

[04:02:30.0000] <annevk>
johnme: sure

[04:09:34.0000] <philipj>
annevk: if you have a strong preference document.URL, now's your chance: https://code.google.com/p/chromium/issues/detail?id=259920

[04:21:26.0000] <annevk>
My preference is Punycode since we use ASCII for the path too

[04:24:05.0000] <mkwst>
annevk: Can I assume that you want https state to move to the document as well? (regarding https://github.com/whatwg/html/pull/273)?

[04:25:47.0000] <annevk>
mkwst: yes

[04:25:59.0000] <mkwst>
Ok. :(

[04:26:10.0000] <annevk>
mkwst: again, I'm sorry

[04:26:23.0000] <mkwst>
Naah. No big deal. It's bz's fault, really.

[04:27:00.0000] <annevk>
heh

[04:27:04.0000] <zcorpan>
philipj: can you explain why region id should be parser-internal only? i've heard feedback that it would be nice to be able to style different regions with css, which makes perfect sense to me

[04:27:16.0000] <annevk>
I suspect this is fallout from Brendan Eich's document.write() debacle

[04:27:42.0000] <annevk>
mkwst: what do you think about my cache analysis above?

[04:27:48.0000] <annevk>
mkwst: and JakeA's remark?

[04:28:12.0000] <mkwst>
I'm less concerned about timing attacks than I am about 100% reliable queries.

[04:28:22.0000] <mkwst>
So, yeah, I think your comments are accurate.

[04:28:40.0000] <mkwst>
But I don't think they're fatal to force-cache.

[04:29:15.0000] <annevk>
Okay, well, I'm happy to just remove the one problematic one and see what happens when someone tries to ship it

[04:29:26.0000] <mkwst>
I think that's a reasonable approach.

[04:36:35.0000] <philipj>
zcorpan: can ::cue-region take an id?

[04:36:56.0000] <zcorpan>
philipj: not currently

[04:37:18.0000] <philipj>
OK, and there wasn't any other way to use the ID than to get the region at the time I was thinking about this.

[04:37:32.0000] <philipj>
In which case just associating them and removing the indirection from the API seemed nice

[04:37:49.0000] <zcorpan>
ok

[04:39:39.0000] <mkwst>
annevk: I'm re-reading bz's comments on the CSP list bug again, and I don't think I understand what he wants. I've given you a patch that just moves the thing from Window to Document, but he's suggesting that we can avoid patching `document.open()` and etc.

[04:39:46.0000] <mkwst>
annevk: I don't see how to do that.

[04:47:12.0000] <annevk>
mkwst: document.open() doesn't change the document, it only changes the global

[04:47:23.0000] <annevk>
mkwst: so you can avoid patching document.open() if you store stuff on the document

[04:48:00.0000] <mkwst>
annevk: Ah, I see. Thanks.

[04:48:29.0000] <annevk>
mkwst: I think bz was just pointing out the various ways we could go about this and where he'd like to avoid adding complexity

[04:48:41.0000] <annevk>
mkwst: which to me read that he wanted this on document

[04:49:06.0000] <mkwst>
Yup, which is fine. I'm happy to do it that way, I just want to give you a patch you'll accept rather than iterating for a few more days. :)

[04:59:31.0000] <mkwst>
annevk: I'll follow it up with a patch to move HTTPS state.

[06:26:56.0000] <annevk>
mkwst: note that I left feedback in https://github.com/whatwg/html/pull/273

[06:27:06.0000] <annevk>
mkwst: not sure if you saw, given the follow up PRs

[06:29:57.0000] <mkwst>
Thanks for the ping. How do you stay on top of PRs? I imagine you have more notifications coming in than I do, but I find it hard to know what I ought to be looking at.

[06:30:21.0000] <mkwst>
annevk: GitHub has randomly chosen to send me some updates to my work email, some to home email, some to chromium.org. I don't get it.

[06:30:59.0000] <annevk>
mkwst: I'm not sure how, but this one I have as an open tab since you've been working on it today and I've been reviewing it today and I just got back from lunch...

[06:31:29.0000] <annevk>
mkwst: I only use the web UI for GitHub

[06:31:34.0000] <annevk>
no email

[06:32:18.0000] <mkwst>
annevk: I try to use the web UI, but I feel like I'm missing things constantly. *shrug*

[06:32:46.0000] <mkwst>
Like, this PR doesn't show up in "notifications". Which makes no sense. I have to cli

[06:33:01.0000] <annevk>
That is sad

[06:33:07.0000] <mkwst>
I have to click through "Pull Requests", which is fine, I suppose, but I want one place to look at things I need to care about.

[06:33:29.0000] <annevk>
To be fair, when you push changes and don't add comments I don't think I get notified either

[06:33:56.0000] <annevk>
But I try to go through outstanding PRs somewhat regularly since it's not nice to keep folks waiting

[06:35:22.0000] <annevk>
mkwst: about rel=noopener http://logs.glob.uno/?c=mozilla%23content&s=5+Nov+2015&e=5+Nov+2015#c338410

[06:37:47.0000] <mkwst>
annevk: Wonderful. I guess I should hop back into #content.

[06:38:16.0000] <mkwst>
annevk: rel=noopener is straightforward. How do you feel about the window.open pieces of Charlie's old proposal?

[06:38:27.0000] <mkwst>
annevk: I guess I should just ask bz. :/

[06:39:40.0000] <annevk>
mkwst: not sure about those

[06:39:55.0000] <annevk>
mkwst: we need to credit Scott Beardsley for rel=noopener https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0046.html

[06:40:34.0000] <annevk>
mkwst: I suspect bz would be fine with such features if he was fine with this one

[06:41:12.0000] <mkwst>
I guess I should pay attention to whatwg@. :/

[06:42:20.0000] <annevk>
mkwst: refresh that earlier URL for more from bz

[06:42:30.0000] <annevk>
mkwst: discussing window.open() at the end

[06:42:38.0000] <annevk>
mkwst: you can also join the channel on Mozilla IRC of course

[06:48:08.0000] <wanderview>
JakeA: do you have some idea when chrome will implement/ship https://github.com/whatwg/fetch/pull/146?

[06:48:24.0000] <wanderview>
JakeA: would be nice to align our changes if we can to minimize compat issues

[07:46:47.0000] <mkwst>
annevk: Would you prefer `window.open` to change in the same PR as `rel=noopener`?

[07:59:48.0000] <annevk>
mkwst: given https://github.com/whatwg/html/issues/313 does it need to change?

[08:00:25.0000] <annevk>
mkwst: if it's a separate feature, separate might be better, but I can't really see the changes in front of me so use your best judgment I guess

[08:00:45.0000] <mkwst>
*shrug* It's pretty related. I'll send you a patch, you can tell me to split it up.

[08:01:28.0000] <annevk>
mkwst: I'm away for a couple hours starting now

[08:01:43.0000] <JakeA>
wanderview: on leave today and can't reach github for some reason, will pick this up tomorrow

[08:01:52.0000] <mkwst>
Yup. My day's pretty much over as well. No rush on the review.

[08:49:29.0000] <bblfish>
@annevk does the fetch api allow one to intercept a 401?

[08:49:58.0000] <bblfish>
I don't seem to be able to do it, though I think the service worker does.

[10:11:12.0000] <annevk>
bblfish: in theory, yes

[10:11:25.0000] <annevk>
bblfish: if you set the window argument to null, iirc

[10:11:41.0000] <annevk>
bblfish: but this was all defined fairly recently so I'm not sure implementations caught up yet

[10:11:46.0000] <bblfish>
ah, ok. will try that.

[10:12:12.0000] <bblfish>
I am noticing that I don't actually seem to get the preflight requests coming to my server.

[10:12:42.0000] <annevk>
bblfish: there's no preflights same-origin

[10:13:03.0000] <annevk>
bblfish: fetch(..., { window:null } ) is it, but again, I doubt that's implemented

[10:13:34.0000] <bblfish>
I have a request from localhost going to joe.example ( both on the same machine, but the domain names are different )

[10:14:45.0000] <bblfish>
ok will try with {

[10:14:46.0000] <bblfish>
      headers = { "Accept" = rdfMimeTypes },

[10:14:46.0000] <bblfish>
      requestCache = RequestCache.reload,

[10:14:47.0000] <bblfish>
      window = null

[10:14:49.0000] <bblfish>
}

[10:14:57.0000] <bblfish>
( that's scalajs )

[10:15:21.0000] <bblfish>
what is mode = cors

[10:15:25.0000] <bblfish>
for ?

[10:15:43.0000] <annevk>
Reading cross-origin responses that implement the CORS protocol

[10:16:04.0000] <annevk>
requestCache is not a thing...

[10:16:20.0000] <annevk>
Not sure if scalajs is really the same as this API if that is a thing...

[10:17:47.0000] <bblfish>
I have just read through the fetch spec and tried to add the typesafety to your api

[10:17:48.0000] <bblfish>
https://github.com/read-write-web/rww-scala-js/blob/2874afd344590aa1d147efe63eec2431ad8789c8/src/main/scala/org/scalajs/dom/experimental/Fetch.scala#L307

[10:18:33.0000] <bblfish>
so that others developers won't have to keep hunting down typos

[10:19:13.0000] <bblfish>
so { mode = cors } would allow me to intercept cors answers?

[10:21:15.0000] <annevk>
bblfish: s/intercept/read/ yes

[10:21:24.0000] <annevk>
bblfish: and also s/answers/responses/

[10:22:02.0000] <bblfish>
ah, nice. So that would allow me to avoid an extra connection for a 401 perhaps by authenticating immediately...

[10:22:56.0000] <bblfish>
but why is window = null important? Or is it just meant to be called like that from the ServiceWorker ?

[10:23:30.0000] <bblfish>
( My ServiceWorker seems to get the 401 )

[10:24:09.0000] <caitp>
"any window; // can only be set to null", is presumably why

[10:24:12.0000] <annevk>
bblfish: if you are invoking things from the service worker and not passing a request through you don't need window = null since it's the default there

[10:24:21.0000] <annevk>
bblfish: a service worker has no window

[10:24:54.0000] <bblfish>
yep. Just wondering why it's important to have window = null if it is a JS in a window doing it.

[10:24:58.0000] <annevk>
bblfish: when you use fetch() in a document environment (or when you pass a request through) it defaults to the window of that document and is the place to show dialogs in

[10:25:20.0000] <annevk>
bblfish: mostly because that's the default behavior

[10:25:24.0000] <caitp>
"If init's window member is present and it is not null, throw a TypeError." hah, i'm sure there's a good reason for this but it seems kind of wacky at the moment

[10:25:34.0000] <bblfish>
ah ok. Thought it might be a security thing

[10:25:59.0000] <annevk>
caitp: IDL doesn't allow accepting null as the sole value

[10:26:14.0000] <annevk>
caitp: note that omitting the argument / passing undefined gives you a different behavior

[10:26:21.0000] <caitp>
yeah, but having it be the sole acceptable value is just kind of weird

[10:26:41.0000] <annevk>
caitp: we may at some point decide to allow users to pass in different Windows, although it doesn't seem likely

[10:27:12.0000] <annevk>
caitp: well, maybe from a service worker it is somewhat likely that you'd be able to pass in an existing ClientWindow or some such

[10:27:20.0000] <annevk>
dunno

[10:34:53.0000] <bblfish>
well using the  48.0.2555.0 canary (64-bit) and it does not send an options

[10:35:16.0000] <bblfish>
even though the host is different from the Referrer

[10:35:39.0000] <bblfish>
Firefox developer edition does not either

[10:36:01.0000] <bblfish>
I wonder if this is an issue because both are running on localhost.

[10:38:02.0000] <bblfish>
neither seem to give the expected result on window=null

[10:38:50.0000] <bblfish>
but that may be me...

[10:40:12.0000] <bblfish>
ok, so ServiceWorkers are a way out until window=null works reliably then I suppose.

[10:41:37.0000] <bblfish>
@annevk should I file a bug about the browsers not sending a preflight on my setup? I'll try running my code on another machine first perhaps just to see if that makes the difference.

[10:42:51.0000] <annevk>
bblfish: it depends, are you actually making a request that warrants a preflight?

[10:42:52.0000] <caitp>
the options request is sent depending on what is in the request, and where the request is going

[10:43:10.0000] <bblfish>
It's a GET

[10:43:32.0000] <annevk>
bblfish: yeah and it seems you only use a safe header, Accept, so you won't trigger a preflight

[10:43:47.0000] <bblfish>
ah good.

[10:43:53.0000] <annevk>
bblfish: try set a random header, e.g., bblfish: good times

[10:44:00.0000] <annevk>
bblfish: you'll get a preflight then

[10:44:28.0000] <bblfish>
ok, well that's better. I was worried that all this may be extreemly costly in requests

[10:45:02.0000] <bblfish>
if my code knew the server accepted a WWW-Authenticate for the GET, could I send that and not trigger a preflight?

[10:45:33.0000] <bblfish>
mhh, the other way aroudn, client sends Authenticate:  (I think, was just about to write that code )

[10:46:38.0000] <bblfish>
"Authorization"

[10:49:38.0000] <annevk>
bblfish: that requires a preflight

[10:50:02.0000] <annevk>
bblfish: https://fetch.spec.whatwg.org/#simple-header is the safelist

[10:50:55.0000] <caitp>
also depends on the origin you're sending from/talking to, and if it's the same request being sent multiple times, the preflight can be cached

[10:51:27.0000] <caitp>
if you're testing on local host, it could be that it's not really a corss origin request?

[10:54:08.0000] <bblfish>
I keep shifting shift-cmd and deleting everything on each reload.

[10:58:34.0000] <bblfish>
ah yes, this time mozilla sent the preflight.

[11:02:05.0000] <bblfish>
Yep I get an error in chrome "Fetch API cannot load https://joe.example:8443/2013/card. Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response."

[11:03:03.0000] <annevk>
there you go

[11:04:01.0000] <bblfish>
ok, so I see why ServiceWorkers can be useful here: they can caputre the 401 and authorize.

[11:04:42.0000] <bblfish>
it's just a pitty that they require the whole application to be reloaded.

[11:05:36.0000] <bblfish>
it would be nice if all the constants such as modes and all those I have collected in https://github.com/read-write-web/rww-scala-js/blob/2874afd344590aa1d147efe63eec2431ad8789c8/src/main/scala/org/scalajs/dom/experimental/Fetch.scala#L307

[11:05:49.0000] <bblfish>
were documented as to their meaning in the fetch spec.

[11:06:43.0000] <bblfish>
otherwise, thanks for the help. I can try implementing Signature authentication with web crypto now.

[11:08:18.0000] <bblfish>
will only be able to run my app in bleeding edge browsers in the end though, but well...

[11:31:37.0000] <axisv>
Hello


2015-11-06
[00:00:52.0000] <raintrap_>
hey guys. I wanted to test my site in a different version of Safari. Is there like a platform or tool which I could use without installing multiple versions of Safari in my machine? Thanks!

[01:46:08.0000] <mkwst>
annevk: I've started spelling out the fetch implications of priming in a bit more detail: https://mikewest.github.io/hsts-priming/#modifications-fetch-main Suggestions welcome.

[01:46:25.0000] <mkwst>
annevk: agl didn't seem to hate it.

[06:08:26.0000] <annevk>
mkwst: great success

[06:11:36.0000] <annevk>
mkwst: that looks pretty good

[06:11:40.0000] <annevk>
mkwst: thank you

[06:12:20.0000] <mkwst>
annevk: I figure we throw this to the wolves, and once there's some agreement, you or Richard or I can turn it into a set of patches against Fetch.

[06:12:43.0000] <mkwst>
annevk: And I guess I'll try to get Jeff interested in updating the RFC to give Fetch some hooks.

[06:25:57.0000] <annevk>
mkwst: that sounds good

[06:26:43.0000] <annevk>
mkwst: might do some bikeshedding at that point, but for a discussion this seems good

[06:27:21.0000] <mkwst>
Yeah, I don't plan on nailing everything down. This is a quick first pass to have something concrete to argue about.

[06:56:51.0000] <zcorpan>
https://github.com/w3c/webvtt/pull/246

[07:07:40.0000] <annevk>
I like how zcorpan employs the IRC equivalent of "drops mic"

[07:43:59.0000] <annevk>
JakeA: any opinions on https://github.com/whatwg/fetch/issues/40?

[07:45:35.0000] <wanderview>
annevk: that means "from http cache", right?  or also Cache API?

[07:45:51.0000] <annevk>
wanderview: just HTTP

[07:46:28.0000] <annevk>
wanderview: perhaps we should rename the RequestOptions cache httpCache?

[07:46:32.0000] <annevk>
wanderview: and this fromHTTPCache?

[07:46:43.0000] <annevk>
hmm

[07:46:46.0000] <annevk>
I guess it's clear enough

[07:46:48.0000] <wanderview>
annevk: not sure... I don't like those

[07:47:27.0000] <wanderview>
annevk: I guess Response is standalone and Cache API is another layer... makes sense they are unrelated... but I could see it confusing people

[07:47:36.0000] <annevk>
yeah me neither, and we don't prefix lots of other HTTP stuff with HTTP either

[07:47:41.0000] <JakeA>
annevk: I'm not sure what I'd use it for

[07:47:45.0000] <wanderview>
annevk: lets rename Cache API to FetchStore again :-)

[07:48:04.0000] <JakeA>
Boooo

[07:48:53.0000] <annevk>
That would have been a lot better name given that it's not actually a cache

[07:51:01.0000] <annevk>
JakeA: https://github.com/slightlyoff/ServiceWorker/issues/412#issuecomment-57635369 is the argument for this addition, but I haven't really hard anyone ask for it so maybe we should not do it

[08:00:01.0000] <annevk>
So confusing how code.google.com redirects to you to the issues overview after adding a comment to an issue

[08:01:11.0000] <wanderview>
annevk: bugzilla does the same, no?

[08:01:27.0000] <caitp>
there's a setting

[08:01:57.0000] <annevk>
wanderview: yeah, Bugzilla often shows the same bug for me, sometimes the next one in a listing

[08:02:03.0000] <annevk>
s/yeah, //

[08:03:01.0000] <caitp>
there used to be a setting, huh

[08:03:44.0000] <caitp>
i guess there still is, it just doesn't get saved to your profile? weird

[08:04:49.0000] <caitp>
https://www.dropbox.com/s/0hata33lawvez1c/Screen%20Shot%202015-11-06%20at%2011.04.04%20AM.png?dl=0 << that thing, unless you don't get that option normally

[08:08:31.0000] <annevk>
interesting

[08:48:17.0000] <mkwst>
annevk: you'll be thrilled to know that code.google.com is dying, and we're building a whole new bug tracker for crbug.com!

[08:48:33.0000] <mkwst>
annevk: I'm sure that will be a wonderful experience for everyone.

[09:06:27.0000] <annevk>
mkwst: hmm so maybe change noopener link attribute to 'noopener' <link rel> keyword?

[09:06:34.0000] <annevk>
mkwst: in the commit message

[09:07:39.0000] <mkwst>
annevk: Sure. Pushed.

[09:08:41.0000] <annevk>
mkwst: also, the link syntax looks wrong per https://daringfireball.net/projects/markdown/syntax#link though maybe GitHub does something else

[09:08:51.0000] <annevk>
oooh cool

[09:08:59.0000] <annevk>
he switched to HTTPS

[09:09:12.0000] <mkwst>
Ha, yeah. I don't actually use the inline syntax. I'll fix it.

[09:09:33.0000] <annevk>
no HSTS yet

[09:10:25.0000] <mkwst>
annevk: I'm not getting redirected. I suspect you're using HTTPS Everywhere?

[09:10:30.0000] <mkwst>
(which is good)

[09:10:58.0000] <annevk>
I don't think so

[09:11:10.0000] <mkwst>
(pushed a fix to the markdown)

[09:11:16.0000] <annevk>
ooh

[09:11:21.0000] <annevk>
I think I found that link on Google

[09:11:49.0000] <annevk>
So Google might do some HTTPS Everywhere of sorts or just index both and rank this one higher

[09:12:02.0000] <annevk>
interesting

[09:12:20.0000] <mkwst>
That crazy Google. Who knows what it'll do next?

[09:12:49.0000] <annevk>
mkwst: you didn't confirm my question btw

[09:13:00.0000] <annevk>
mkwst: but I guess that means it's a yes, we still need to fix #313

[09:15:39.0000] <annevk>
/me is gonna assume he got all that correct

[09:16:11.0000] <mkwst>
annevk: Yes. Sorry, there's probably some work to do there.

[09:16:37.0000] <mkwst>
At least we'll need to make "disowned its owner" actually clear out the owner browsing context.

[09:16:50.0000] <mkwst>
And probably other things that bz knows about that I don't.

[09:16:51.0000] <annevk>
mkwst: yeah, I think that's all there is to it

[09:17:04.0000] <annevk>
mkwst: plus perhaps a note that this turns it from an auxiliary browsing context into a top-level one

[09:18:33.0000] <annevk>
/me goes to file a bug against Gecko

[09:18:44.0000] <mkwst>
I think we may need to do more than that. "familiar with" seems a bit too loose, for example.

[09:19:12.0000] <mkwst>
but I'm kinda hoping that bz will spell out the things he'd like to see changed? :)

[09:20:09.0000] <annevk>
mkwst: my suggestion for the commit message was silly, should've been rel=noopener of course, <link> has nothing to do with it

[09:20:22.0000] <annevk>
/me blames the time

[09:20:49.0000] <annevk>
mkwst: familiar with just builds on it being auxiliary

[09:21:04.0000] <annevk>
mkwst: at least last time I probed bz that seemed to be it, but willing to be surprised

[09:21:05.0000] <mkwst>
Same origin as well.

[09:22:23.0000] <mkwst>
That is, if https://a.com nested in http://b.com opens https://a.com in a new window with 'noopener', I'd like it to be unfamiliar.

[09:22:55.0000] <mkwst>
(pushed another new commit message :) )

[09:23:55.0000] <annevk>
mkwst: too late, already merged

[09:24:10.0000] <annevk>
mkwst: just noticed we need to change the IDL for window.open() too

[09:24:14.0000] <annevk>
mkwst: but I can do that

[09:24:55.0000] <mkwst>
CC me on the patch, just so I know what to do next time?

[09:27:39.0000] <annevk>
mkwst: https://github.com/whatwg/html/commit/1cf14758fda3d7c157c0a89334bd3bc0cad7686e

[09:28:53.0000] <mkwst>
annevk: Got it, thanks.


2015-11-07
[02:33:11.0000] <annevk>
JakeA: kinda annoying how https://twitter.com/mikemaccana keeps changing the goalposts

[02:39:08.0000] <JakeA>
annevk: yeah, it's a bit all over the place :(

[02:52:01.0000] <annevk>
JakeA: tried to help out

[02:55:15.0000] <JakeA>
annevk: whatever happened to .findAll etc?

[02:55:35.0000] <annevk>
JakeA: query/queryAll

[02:55:52.0000] <annevk>
JakeA: DOM has a sketch, still waiting for proper subclassing and IDL hooks for that

[02:56:00.0000] <JakeA>
Gotcha

[02:56:13.0000] <annevk>
JakeA: otherwise we wouldn't be able to return an array subclass and have yet another API nobody really enjoys

[02:58:49.0000] <annevk>
ooh man

[02:59:22.0000] <annevk>
JakeA: apparently this person also sells security snake oil https://certsimple.com/

[02:59:41.0000] <annevk>
oh well

[03:00:03.0000] <JakeA>
"Fetch sucks" "show me" "waaaa you're not listening to me"

[03:00:30.0000] <JakeA>
Ughhh

[03:03:11.0000] <JakeA>
Hah, he blocked me after shouting to his followers. I really can't understand why all toys went out of pram after asking for evidence

[03:03:45.0000] <JakeA>
"I don't like evidence, I find it clouds my judgement"

[07:09:05.0000] <wanderview>
JakeA: I know its saturday, but since you might be around... do you have an opinion on this? https://github.com/slightlyoff/ServiceWorker/issues/778

[07:49:52.0000] <JakeA>
wanderview: well I'm just arguing on Twitter so I clearly have nothing better to do. Will take a look now.

[08:06:48.0000] <JakeA>
wanderview: trying to find another API that does something special if a callback throws an error

[08:07:03.0000] <JakeA>
where that error would call window.onerror (so not promises)

[08:07:06.0000] <JakeA>
I think IDB does

[08:08:11.0000] <wanderview>
JakeA: sorry, I won't really be able to check back on this for a few hours.. kid duty

[08:08:17.0000] <wanderview>
thanks for looking though

[08:08:29.0000] <wanderview>
I'd like to maybe fix our impl to do the right thing over the weekend

[08:08:43.0000] <JakeA>
no worries, will do some tests and update the thread

[08:08:55.0000] <JakeA>
this is definately edge-case stuff, but I'm glad we're looking at it

[09:09:36.0000] <wanderview>
JakeA: thanks!

[09:44:33.0000] <botie1>
rniwa, at 2015-11-04 00:34 UTC, MikeSmith said: here now

[13:31:49.0000] <Areks_>
Hi all, does anyone work with webrtc? I'm creating small video chat with p2p connection, but i don't see remove video and can't find what's problem, is there any tools for debugging\testing the problem?

[14:36:56.0000] <caitp>
might be a good question for #chromium-support or whatever browser-related support channel?


2015-11-08
[07:44:02.0000] <deltab>
Is there an API to access the browser's copy of the public suffix list, to save having to download (and keep updated) a separate copy?

[08:26:39.0000] <jgraham>
deltab: I'm pretty sure there isn't

[08:33:00.0000] <deltab>
thanks

[10:43:14.0000] <annevk>
deltab: fetch("https://publicsuffix.org/list/public_suffix_list.dat") ;-)

[10:43:41.0000] <annevk>
oh, no downloads allowed

[10:48:30.0000] <deltab>
it's easy enough to do that (there's javascript libraries to parse the file) but it seems like an unnecessary duplication of effort

[10:49:08.0000] <deltab>
thanks anyway


2015-11-09
[23:44:48.0000] <annevk>
deltab: FWIW, we are considering an API at some point

[23:45:10.0000] <annevk>
deltab: if you have anything in particular you'd like to see, please let me or mkwst know

[00:57:53.0000] <mkwst>
annevk: Do you have a minute to talk about Fetch and credentials and FormData and URLSearchParams?

[01:06:06.0000] <annevk>
mkwst: sure

[01:06:59.0000] <mkwst>
annevk: We discussed briefly in person: folks want to be able to submit urlencoded data. The current model (`fetch(..., credential.toFormData())`) results in a multipart submission. That's unfortunate.

[01:07:24.0000] <mkwst>
annevk: One suggestion was to add a `toURLSearchParam` analog to `toFormData`. I've started spelling that out.

[01:07:46.0000] <annevk>
Params*

[01:07:54.0000] <mkwst>
annevk: But it's hideous and almost pure duplication. Without reading both the Fetch and URL specs, no one will know why they should use one or the other.

[01:08:03.0000] <mkwst>
annevk: I'm looking for better ideas.

[01:08:48.0000] <annevk>
mkwst: how do people know whether to pick enctype=application/x-www-form-urlencoded vs multipart/form-data today?

[01:09:01.0000] <mkwst>
annevk: I doubt most people do.

[01:09:36.0000] <annevk>
If they didn't files wouldn't end up on the server

[01:09:54.0000] <mkwst>
I meant that I expect modern frameworks to handle both.

[01:10:13.0000] <annevk>
That is true, but you still have to pick the non-default one to make things work

[01:10:47.0000] <mkwst>
Sure. And I guess the default for forms is urlencoded.

[01:10:53.0000] <annevk>
But yeah, I guess it's fair to say that most folks don't really understand the difference really well, since the server software tends to abstract from the submission format quite a bit

[01:13:04.0000] <annevk>
So your suggestion would be to either overload FormData or have some higher level of abstraction in Credentials?

[01:13:05.0000] <mkwst>
So, I can certainly spell out the contours of an opaque URLSearchParams object, and teach PasswordCredential to produce one. And add some helpful text in the spec that says "Hey, use this one if you need this kind of form submission, and this one if you don't." It's just very ugly and I feel bad typing it. :)

[01:14:21.0000] <mkwst>
I don't have much of a suggestion. We need the ability to determine the names of the username/password parameters, and we need the ability to tack on additional data to the submission.

[01:14:40.0000] <mkwst>
For both of those cases, something like FormData or URLSearchParams is a good fit.

[01:15:36.0000] <mkwst>
It would be nice if they weren't two things, honestly.

[01:17:17.0000] <mkwst>
One option might be to have some nicely named `toSubmittableObjectThatHasTheDataYouNeed()` method that returns either a FormData or URLSearchParams object based on an `enctype` paramater?

[01:17:36.0000] <mkwst>
then at least the credential-side interface would be clear.

[01:19:07.0000] <annevk>
That might be okay

[01:19:19.0000] <annevk>
I don't really see a good way of merging these

[01:19:35.0000] <annevk>
Just becomes ugly in some other way

[01:38:36.0000] <mkwst>
(Sorry, folks here demolishing my bathroom. Need to make sure they don't demolish the parts I like. :) )

[01:39:47.0000] <mkwst>
*shrug* Idunno. From my perspective, they're doing much the same thing. I haven't followed them all the way through, so I'm sure they're distinct in interesting ways.

[01:40:39.0000] <jgraham>
/me has visions of mkwst typing in the bath as the room collapses around him

[01:40:48.0000] <mkwst>
It just seems strange that I'm ending up with two objects that, from the perspective of the credentials work, are indistinguishable.

[01:41:26.0000] <mkwst>
jgraham: Happily, the bathroom is way upstairs. I think it'd be tough to type in there; it's pretty loud at the moment.

[01:42:55.0000] <mkwst>
I'll go the "hide the complexity" route and switch on `enctype` for the moment, let's see how it ends up looking.

[01:47:21.0000] <annevk>
mkwst: I mean the only reason we're even dealing with this is because there's some legacy stuff going on

[01:47:29.0000] <annevk>
mkwst: that you want to account for

[01:47:56.0000] <annevk>
mkwst: FormData is superior for non-URL stuff

[01:48:14.0000] <mkwst>
annevk: Right. The goal is for this to be something that developers can layer on top of an existing system. For better or worse, that means we need annoying amounts of flexibility.

[01:48:17.0000] <annevk>
mkwst: URLSearchParams is useful because it does not pretend it can handle Blob, and because it can be associated with a URL object

[01:50:08.0000] <annevk>
mkwst: I don't really have strong opinions here but I do think that since they have different serializations, not trying to shoehorn them together is useful

[01:51:06.0000] <mkwst>
annevk: Sure. I don't think we should rewrite Fetch because of this API. I'm just trying to find a reasonably elegant way of building the thing I want to build. :)

[01:51:46.0000] <annevk>
mkwst: I think toFormData() and toURLSearchParams() would still be clearest

[01:52:01.0000] <annevk>
mkwst: just like <form enctype> it allows folks to make an informed choice

[01:52:12.0000] <mkwst>
annevk: You also wrote both specs, and deeply know what each means. :)

[01:52:54.0000] <mkwst>
Well, `enctype` is the choice developers make for `<form>`, right?

[01:53:09.0000] <annevk>
mkwst: yes

[01:53:19.0000] <annevk>
mkwst: this is the analogous API choice

[01:53:20.0000] <mkwst>
They don't have `<formdata-form>` and `<urlsearchparams-form>`.

[01:54:05.0000] <mkwst>
Maybe if they were spelled `MultipartFormData` and `URLEncodedFormData`... :)

[01:54:06.0000] <annevk>
mkwst: I don't think you can really compare it that way, given that we also have <input type=color> and such

[01:54:31.0000] <mkwst>
Because that's the choice folks would be making for this use case. I doubt they'd care about the remaining properties for a sign-in system.

[01:55:15.0000] <annevk>
mkwst: sure, it just so happens that urlencoded is used outside of forms too

[01:56:30.0000] <annevk>
I tried to think of something like a single method, but toFetchBody(...) and such all seem equally awful

[01:57:15.0000] <mkwst>
Yeah. `toFetchable` is my placeholder. It's not great.

[01:57:17.0000] <annevk>
Also since the best default there would be the inverse of <form enctype=> which would not be great

[01:57:52.0000] <annevk>
And if you require the argument you've just made the API worse

[01:58:42.0000] <annevk>
mkwst: perhaps FormData should have a method to convert it to URLSearchParams

[01:58:51.0000] <annevk>
mkwst: so you only have toFormData()

[01:59:03.0000] <annevk>
mkwst: and if folks really need URLSearchParams for legacy reasons, they convert it

[01:59:23.0000] <annevk>
mkwst: could also be URLSearchParams.from(formDataInstance)

[02:00:08.0000] <annevk>
mkwst: of course, you still need all the hiding slots and stuff, but don't really see a way around that

[02:00:50.0000] <mkwst>
Well, one way around that would be to teach Fetch how to deal with a credential object. But that has its own problems.

[02:01:29.0000] <annevk>
That doesn't allow for appending additional data

[02:01:38.0000] <annevk>
I thought that was a requirement?

[02:01:56.0000] <mkwst>
Right. That's one of the problems. We'd have to teach the credential object how to hold data. :)

[02:02:22.0000] <annevk>
Ah yes, the old we have two objects to hold data, let's add a third one

[02:02:26.0000] <mkwst>
And then define serialization and extraction and etc.

[02:02:40.0000] <mkwst>
Well, it would be _my_ data-holding object. So, obviously better.

[02:03:09.0000] <annevk>
I'm sure that folks who want to do exactly what you want to do would appreciate it

[02:03:22.0000] <mkwst>
We could also skip this whole `fetch()` dance and go back to `credential.send()`. :)

[02:04:15.0000] <annevk>
Yeah, and then they want referrer control, custom header control, cache bypassing, ...

[02:04:43.0000] <mkwst>
Well, sure. We'll build all that in.

[02:05:53.0000] <annevk>
Of course :-)

[02:06:05.0000] <mkwst>
I mean, we'll spell it all differently, of course.

[02:06:21.0000] <annevk>
I'm sorry the best we come up with is https://xkcd.com/927/

[02:06:42.0000] <annevk>
that*

[02:08:12.0000] <annevk>
Also, that minute took an hour

[02:08:36.0000] <annevk>
/me will be more careful allocating minutes to mkwst in the future :-P

[02:08:40.0000] <mkwst>
Your fault for not letting me just write my own Fetch in the first place.

[02:08:53.0000] <mkwst>
Ok. I think `toURLSearchParams` is hideous. But I'll just type it for the moment and stop bothering you.

[03:53:35.0000] <annevk>
mkwst: https://github.com/whatwg/html/pull/323

[05:51:49.0000] <annevk>
MikeSmith: interested in reviewing https://github.com/whatwg/html-build/pull/39?

[06:32:44.0000] <zcorpan_>
Domenic: friendly ping https://github.com/whatwg/html/pull/246

[06:46:52.0000] <annevk>
zcorpan_: he's prolly still on vacation

[06:47:05.0000] <zcorpan_>
oh ok

[06:59:21.0000] <wanderview>
I thought he was getting back today

[07:06:53.0000] <zcorpan_>
MikeSmith: last change in https://www.w3.org/Bugs/Public/show_activity.cgi?id=24055 looks bogus (attachment is some .dll file)

[08:22:25.0000] <bblfish>
annevk: did you work on webcrypto?

[08:22:44.0000] <annevk>
bblfish: nope

[08:23:02.0000] <bblfish>
ah, where/who are the folks who did?

[08:23:42.0000] <annevk>
bblfish: doesn't the spec say?

[08:24:03.0000] <bblfish>
ah true

[08:24:53.0000] <bblfish>
rslevi I wonder what channel he hangs out on

[08:25:01.0000] <annevk>
Hmm, either Twitter refuses to email me some email change confirmation email while claiming they did send it or Gmail refuses to show it

[08:25:07.0000] <annevk>
bblfish: Twitter

[08:27:12.0000] <bblfish>
ah thanks.

[08:31:16.0000] <bblfish>
( been working on improving the web-crypto interface for scala-js https://github.com/bblfish/scala-js-dom/blob/fix-generate-key-api/src/main/scala/org/scalajs/dom/crypto/Crypto.scala )

[09:28:31.0000] <rniwa>
Ms2ger: yt?

[09:28:45.0000] <rniwa>
annevk: yt?

[09:28:55.0000] <Ms2ger>
Just for a few more minutes

[09:29:58.0000] <Ms2ger>
/me should make it back into the kitchen by the time his water boils

[09:48:19.0000] <bblfish>
annevk: I opened an issue the other day for Fetch https://github.com/whatwg/fetch/issues/156

[09:48:46.0000] <bblfish>
I'll also be submitting my Fetch to scala-js-dom lib, sometime this week.

[09:56:24.0000] <annevk>
bblfish: yeah I looked at that and that doesn't seem like something we'll address anytime soon

[09:56:48.0000] <annevk>
bblfish: the headers to be transmitted are in the network stack which is mostly post-Fetch

[09:57:14.0000] <annevk>
bblfish: although it's all a bit gobbled up admittedly since the standards are a bit post-implementation

[10:00:23.0000] <bblfish>
yes, i suppose Http Signature needs a lot more support and implementations before it makes sense to do that engineering. In the meantime we need to work out what to sign.

[10:01:10.0000] <bblfish>
otherwise there's another catch22. There are a lot of catch-22s when dealing with authentication. That's why however bad it is TLS-crypto at least works.

[10:08:03.0000] <annevk>
For some reason https://tools.ietf.org/html/draft-cavage-http-signatures is not loading, the -00 draft seemed very light on detail

[10:08:33.0000] <bblfish>
it's version -05 annevk

[10:08:53.0000] <bblfish>
this one https://tools.ietf.org/html/draft-cavage-http-signatures-05

[10:11:35.0000] <annevk>
tools.ietf.org seems very slow for some reason

[10:12:57.0000] <annevk>
That draft seems to sorta skip over justification for why it's a good idea to begin with

[10:13:38.0000] <bblfish>
There are quite a few services that currently do stuff like that, such as Amazon cloud, and others.

[10:17:42.0000] <bblfish>
Amazon has a signature based auth mechanism http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html

[10:18:11.0000] <bblfish>
OCLC HMAC Auth https://www.oclc.org/developer/develop/authentication/hmac-signature.en.html

[10:18:32.0000] <bblfish>
Akamai  https://developer.akamai.com/introduction/Client_Auth.html

[10:19:01.0000] <bblfish>
Lindsay http://progrium.com/blog/2012/12/17/http-signatures-with-content-hmac/

[10:19:34.0000] <bblfish>
But yes, it may be that better justification would help

[10:43:03.0000] <JakeA>
annevk: is there such a thing as a guide to writing web standards? As in, something that explains the ideal structure of a standards doc, when you'd queue a task, how to reference things in other specs etc

[10:46:01.0000] <annevk>
JakeA: no

[10:46:14.0000] <annevk>
JakeA: there's bits and pieces

[10:47:50.0000] <JakeA>
annevk: if we're wanting to increase diversity here, feels like there should be. I'll keep it in mind as a possible 2016 thing.

[10:48:08.0000] <annevk>
JakeA: I agree that we need it

[10:49:03.0000] <annevk>
JakeA: I'd like to improve the foundations a bit as well as both HTML and IDL are somewhat shoddy to build on

[10:49:22.0000] <annevk>
JakeA: and I have some kind of vision as to how things should be, but getting there takes tim

[10:49:28.0000] <annevk>
time*

[10:50:41.0000] <wanderview>
it would be great even to have someplace to capture common mistakes... so every time someone experiences mutters "this is a terrible spec", they can add why to the "don't do this" list

[10:50:52.0000] <wanderview>
^experiences^experienced

[10:51:17.0000] <JakeA>
annevk: well, we've got a couple of people in dev rel wanting to get into spec stuff, so that might be a good opportunity to figure out all the stumbling blocks

[10:51:58.0000] <JakeA>
annevk: anyway, I'll pick it up with you in 2016. Just thinking out loud now.

[10:52:42.0000] <wanderview>
JakeA: did you ever have a chance to look and see when propagating the intercepted URL will be implemented in chrome?

[10:53:10.0000] <annevk>
Domenic: have you perhaps not synced https://github.com/whatwg/html-build with the build server?

[10:53:27.0000] <annevk>
Domenic: and is that why https://github.com/whatwg/html/issues/324 is a problem?

[10:53:36.0000] <Domenic>
annevk: it should be automatic

[10:53:42.0000] <annevk>
JakeA: sounds great

[10:53:54.0000] <Domenic>
The cache is not cleared though

[10:54:03.0000] <JakeA>
wanderview: *scratches head* I'm not sure what that means, give me a clue :D

[10:54:15.0000] <Domenic>
So if clearing the cache is necessary that means we shouldn't be caching something that we're currently caching

[10:54:15.0000] <JakeA>
Is this the CSS base url thing?

[10:54:37.0000] <wanderview>
JakeA: https://github.com/whatwg/fetch/pull/146

[10:54:41.0000] <JakeA>
(brb catching a train)

[10:54:49.0000] <wanderview>
np

[10:56:15.0000] <annevk>
Domenic: hmm, there's no commit hook for html-build

[10:56:23.0000] <Domenic>
annevk: zcorpan: on a plane at the moment, will get to reviews and build stuff when I land and get to the hotel hopefully (BlinkOn)

[10:56:26.0000] <Domenic>
Hmm

[10:56:45.0000] <Domenic>
Oh I think it's updated with HTML

[10:56:50.0000] <annevk>
Domenic: ah yes, have fun

[10:56:59.0000] <annevk>
Domenic: this can wait another week, I'm sure

[10:57:00.0000] <Domenic>
Every HTML push pulls from HTML-build

[10:57:32.0000] <Domenic>
Meh I figure BlinkOn week is work week so I'll get at least some stuff done

[10:59:09.0000] <annevk>
I removed the entity stuff from the cache manually

[11:00:58.0000] <annevk>
"Updating entities database (this always takes a while)..." oh yes you do

[12:55:59.0000] <bblfish>
annevk: I explored how we can work without the capabilities proposed in Fetch issue 156 in https://github.com/solid/solid-spec/issues/52

[12:56:25.0000] <bblfish>
we essentially need just a JS-Date header

[12:57:32.0000] <bblfish>
( this does not exclude other groups having use cases needing the capabilities of issue 56 )


2015-11-10
[17:04:17.0000] <MikeSmith>
annevk: will look at https://github.com/whatwg/html-build/pull/39

[17:04:34.0000] <MikeSmith>
annevk: oh, merged already

[19:46:33.0000] <cvrebert>
MikeSmith: What's the policy on merging things in the test suite repos? Their CONTRIBUTING files are just licensing legalese.

[20:37:12.0000] <roc>
/me reads http://homepages.cwi.nl/~steven/Talks/2015/11-06-xml-amsterdam/

[20:37:21.0000] <roc>
sigh

[20:42:33.0000] <caitp>
i guess they aren't fans of js?

[20:46:54.0000] <roc>
I suspect he isn't a fan of anything that happened on the Web this century

[21:02:43.0000] <Hixie>
this talk is great

[21:02:51.0000] <Hixie>
"You can tell by reading the HTML5 spec that it was written by programmers"

[21:03:14.0000] <Hixie>
meanwhile programmers whine that html is unimplementable and obviously written by theorists

[21:04:38.0000] <cvrebert>
"CSS is another example of a successful declarative approach" LOL

[21:05:12.0000] <Hixie>
this talk is so naive it's hilarious

[21:05:45.0000] <Hixie>
for example, where are the "Advantages of the Procedural Approach"? or the "Disadvantages of the Declarative Approach"?

[21:06:06.0000] <Hixie>
it's been 10 years now. you'd think they'd understand what went wrong with xforms.

[21:06:56.0000] <roc>
plus his "declarative" and "procedural" examples aren't even nearly specifying equivalent behavior

[21:07:34.0000] <roc>
plus his procedural example is padded by specifying non-negative integers, which aren't covered by the declarative example at all

[21:10:40.0000] <Hixie>
i think the best part of this talk is that it fails to address any of HTML's actual failings or any of the actual risks to the Web platform.

[21:10:56.0000] <Hixie>
it literally could have been given almost verbatim 10 years ago

[21:11:38.0000] <Hixie>
the "100 year web" slide in particular

[21:12:01.0000] <Hixie>
maybe steven doesn't know that i wrote the HTML spec specifically to address that problem (though i was thinking more on the 1000-year timeframe)

[21:12:24.0000] <Hixie>
and that that is why the text looks like his "Procedural numbers: HTML5" slide

[21:13:28.0000] <Hixie>
(i don't understand the internal inconsistencies he's referring to in the "Inflation" slide. Is it the bolded text on the previous slide?)

[21:14:05.0000] <Hixie>
(maybe he subscribes to the "everything should be conforming" camp or the "anything not conforming must be left undefined" camp, but in that case, his "100 year web" slide misses the point even more)

[23:05:43.0000] <annevk>
That set of slides captures the nuance of Fox News

[23:41:26.0000] <annevk>
JakeA: finally got around to filing https://github.com/w3c/beacon/issues/14

[23:51:15.0000] <JakeA>
annevk: would you expect backgroundSync to have the same restrictions? It doesn't right now

[23:51:24.0000] <annevk>
JakeA: of course

[23:51:37.0000] <annevk>
JakeA: that's what we talked about, how that would be broken

[23:52:10.0000] <annevk>
JakeA: your argument was sendBeacon() throw the first stone, but I don't think that's true in contemporary implementations and we better prevent it from happening

[23:54:40.0000] <JakeA>
annevk: this makes backgroundSync kinda useless. Eg, I send an email in the elevator when leaving work, put phone in pocket, phone switches from wifi to cell, my message isn't sent

[23:55:01.0000] <annevk>
JakeA: yeah, needs to be optin

[23:55:32.0000] <annevk>
I gave this feedback when we started out too, I'm pretty sure

[23:55:54.0000] <annevk>
But then you decided amongst yourself on a different UX model without taking that into account

[23:57:02.0000] <JakeA>
annevk: also don't browsers prefetch pages as they're typed into the address bar? Typing into the address bar can make requests to sites you weren't intending to visit. Isn't this the kind of thing we invented private browsing modes for?

[23:57:13.0000] <JakeA>
It was taken into account

[23:57:33.0000] <annevk>
I don't think all browsers do that

[00:00:43.0000] <JakeA>
annevk: the only way I can see of making background sync opt-in is to prompt on browser/tab close

[00:01:12.0000] <JakeA>
Which gets complicated on mobile in terms of when a tab is closed

[00:14:29.0000] <annevk>
JakeA: yeah I was thinking something like that too

[00:14:34.0000] <annevk>
JakeA: it's not ideal to be sure

[00:14:54.0000] <annevk>
JakeA: we should have a somewhat larger debate about this

[00:15:16.0000] <annevk>
JakeA: whether it's okay for closed tabs to continue to have some insight into user behavior

[00:15:27.0000] <JakeA>
annevk: where's good? Background sync github?

[00:15:39.0000] <annevk>
JakeA: maybe public-webappsec?

[00:15:56.0000] <annevk>
JakeA: that's the only list I know with security minded folks already subscribed

[00:19:00.0000] <JakeA>
annevk: makes sense. I'm filming this morning, but can draft something up this afternoon

[01:12:48.0000] <zcorpan>
how does assignments on github work? i can't assign jungkees in https://github.com/whatwg/html/issues/321#issuecomment-155357371

[01:14:26.0000] <Ms2ger>
It only works for people who have push access

[01:14:36.0000] <Ms2ger>
Other people can't fix issues, obviously

[01:14:46.0000] <Ms2ger>
Servo uses an "assigned" label

[01:23:20.0000] <jgraham>
fwiw I was considering using a bot to create one label per reviewer for wpt. You could do something similar with assignments

[01:23:54.0000] <cvrebert>
https://github.com/isaacs/github/issues/100

[01:24:17.0000] <jgraham>
(i.e. r?jgraham would set a label reviewer:jgraham a=jgraham would set a label assigned:jgraham)

[01:24:25.0000] <jgraham>
(or something)

[01:24:47.0000] <jgraham>
(the point being that then people could see their review queue/assignment queue)

[01:34:12.0000] <annevk>
We should add jungkees to the non-push access group

[01:34:16.0000] <annevk>
I'll do that

[01:37:10.0000] <abreton>
hello

[01:37:10.0000] <botie1>
salut, abreton

[01:37:35.0000] <abreton>
I am wondering if there is a way to make a worker inherit the CSP from the calling document?

[01:41:54.0000] <annevk>
abreton: not currently, as far as I know

[01:42:54.0000] <abreton>
annevk: ok thanks

[01:55:51.0000] <MikeSmith>
cvrebert: whose CONTRIBUTING files?

[01:56:21.0000] <cvrebert>
MikeSmith: web-platform-tests , csswg-tesy

[01:56:42.0000] <cvrebert>
*csswg-test

[01:56:49.0000] <MikeSmith>
the policy is basically that we don't merge things in that are unnecessary or redundant, so if there's anything in that class, we shouldn't merge it

[01:57:03.0000] <MikeSmith>
or should revert it if it's already been merged

[01:57:38.0000] <cvrebert>
MikeSmith: What about review requirements?

[01:58:18.0000] <MikeSmith>
Hixie: I guess it is pretty much the same talk he's been giving for 10 years now

[02:02:13.0000] <MikeSmith>
cvrebert: the review requirements are, it's a the discretion of the owners / core reviewers in the end

[02:02:24.0000] <MikeSmith>
cvrebert: which for wpt amounts to Ms2ger and jgraham

[02:02:48.0000] <MikeSmith>
for csswg-test I don't really know what the review requirements are

[02:03:09.0000] <MikeSmith>
but for wpt a good rule is that if you have any doubt, ask Ms2ger or jgraham

[02:07:30.0000] <cvrebert>
MikeSmith: Noted.

[02:13:54.0000] <Ms2ger>
sup?

[02:18:04.0000] <cvrebert>
Nothing specific.

[03:37:36.0000] <JakeA>
annevk: you mentioned a web components meetup that we might want to combine with a serviceworker f2f, any details on the components meetup?

[03:52:43.0000] <annevk>
JakeA: I don't think anything's been decided yet

[03:52:57.0000] <annevk>
JakeA: there was a poll of sorts started on public-webapps

[03:55:53.0000] <JakeA>
annevk: ahh ok. I'll see if it's coming together in a month or so, if not I'll take MS up on their offer of hosting

[04:44:10.0000] <zcorpan>
i wonder if https://github.com/whatwg/html-build should say to fork html, clone the fork, and then clone html-build. i know build.sh will clone html itself, but if you want to submit a PR for html you have to fork it

[04:45:40.0000] <zcorpan>
MikeSmith: ^

[04:47:09.0000] <gsnedders>
is there any reason why it isn't a submodule of html?

[04:51:48.0000] <zcorpan>
i dunno

[05:00:32.0000] <MikeSmith>
the html-build script will clone the html repo if it doesn't find an existing clone in the local environment or you don't point it at one

[05:01:55.0000] <MikeSmith>
at least that is the intent, though there's an open html-build PR that I need to finish work on

[05:02:03.0000] <zcorpan>
yeah i see https://github.com/whatwg/html-build/pull/29 now

[05:04:31.0000] <zcorpan>
but i still think our READMEs should instruct to fork html. iirc there was some contributor that got confused about this and we needed to start over with forking html

[05:06:15.0000] <zcorpan>
i suppose this is https://github.com/whatwg/html-build/issues/26

[05:06:25.0000] <MikeSmith>
/me looks

[05:06:53.0000] <MikeSmith>
yeah

[05:07:59.0000] <MikeSmith>
sorry, I was working on this stuff pretty actively til roughly one month ago

[05:09:05.0000] <MikeSmith>
getting back to working again on making it right as soon as possible is a high(est) priority for me personally

[05:13:01.0000] <MikeSmith>
as far as why we've not set it up at as submodule already, I guess that's because none of us who worked on it initially are big fans of submodules

[05:25:32.0000] <zcorpan>
i can PR the html-build readme to add a first step saying to fork html if the goal is to PR html

[05:46:30.0000] <wanderview>
JakeA: annevk: so are we intending to allow service workers to be registered for file:// documents (or event wss:// somehow?)

[05:47:47.0000] <JakeA>
wanderview: registered? No. Intercepting file:// is more interesting though. I can see us intercepting wss in future too, but it'd be a different event

[05:48:04.0000] <wanderview>
JakeA: I don't see where we block file:// in the spec any more

[05:48:50.0000] <wanderview>
JakeA: it seems to just use the "Is origin potentially trustworthy" check, which allows file://, wss://

[05:49:33.0000] <JakeA>
wanderview: ohhh, we should specifically prevent file I think. Having a SW running in someone's file system sounds really unsafe

[05:50:00.0000] <wanderview>
JakeA: ok, I will file a separate issue for that... I had commented in the big "secure context" issue, but I think we should fix this sooner

[05:50:11.0000] <JakeA>
agreed

[05:51:13.0000] <wanderview>
JakeA: if we want to allow file:// and wss:// to be intercepted, we also need to relax the restrictions in cache API

[05:53:09.0000] <JakeA>
wanderview: file:// maybe, but not sure what it means to put a wss:// in a cache. Will those be represented by request/response or something else?

[05:53:42.0000] <wanderview>
JakeA: not sure... I was just thinking the usual cache patterns in SW should work with FetchEvent.request even if its a wss: scheme...

[05:54:35.0000] <wanderview>
or at least not explode

[05:54:57.0000] <wanderview>
I guess we already have some things that conditionally fail... like cache.add() with a POST

[05:56:53.0000] <JakeA>
wanderview: I don't know enough about the wss protocol to know if request/response makes sense or if it'd need its own event

[05:57:02.0000] <wanderview>
ok

[05:57:15.0000] <wanderview>
neither do I... lets burn that bridge later :-)

[06:08:20.0000] <wanderview>
JakeA: what about an https://foo.com window, that has an iframe with a data:// URI.. I believe the iframe inherits the parents origin there... should the iframe be allowed to register a SW for https://foo.com?

[06:11:00.0000] <wanderview>
JakeA: or for a javascript:// window that inherits the origin of its opener... shoudl that be allowed to register using its opener's origin?

[06:23:12.0000] <wanderview>
I guess the origins should just be compared and if the origins are set properly, then it shoudl work

[06:25:19.0000] <annevk>
wanderview: JakeA: intercepting anything but http/https URLs doesn't work per Fetch

[06:26:32.0000] <annevk>
wanderview: JakeA: nothing for those URLs gets even close to checking a service worker for a response

[06:27:27.0000] <wanderview>
annevk: sure... but I don't see anything in .register() currently that would prevent the service worker from registering and controlling such a page

[06:31:14.0000] <JakeA>
wanderview: yes to both your questions - I think this is how it works already

[06:31:20.0000] <wanderview>
ok, thanks

[06:48:23.0000] <annevk>
zcorpan: a constructor cannot return a promise

[06:48:50.0000] <zcorpan>
annevk: ok. why not?

[06:49:53.0000] <zcorpan>
though since we need some opt-in mechanism, we can make it be a static method on Worker or so instead

[06:49:53.0000] <jgraham>
Presumably because a construtor is supposed to construct an instance?

[06:50:17.0000] <annevk>
zcorpan: well, I guess technically it probably can, but a constructor is expected to return an instance

[06:50:51.0000] <zcorpan>
yeah

[07:13:36.0000] <wanderview>
the Promise() constructor can return a promise :-)

[07:16:27.0000] <wanderview>
JakeA: sorry for more dumb questions... do we intentionally let https://foo.com window to execute .register('javascript://...')?  where the service worker script inherits the origin from the window?

[07:19:22.0000] <JakeA>
wanderview: the SW cannot be a blob/data url, so I guess javascript should be out too

[07:19:37.0000] <JakeA>
Otherwise you're not proving you can put script on that origin

[07:19:58.0000] <JakeA>
Wouldn't javascript:// fail the same origin check?

[07:20:24.0000] <wanderview>
JakeA: no... because I thought javascript:// URIs were supposed to inherit the origin

[07:20:46.0000] <wanderview>
JakeA: what blocks blob: and data: URLs for the script?  I didn't see that last time I looked

[07:22:27.0000] <wanderview>
JakeA: oh, hmm... I guess the URL spec does not do the origin inherit for data: or javascript:... but it seems it might give you a real origin for a blob:

[07:23:05.0000] <JakeA>
wanderview: maybe we need to explicitly fail for non http or https schemes

[07:23:19.0000] <wanderview>
JakeA: yea, I'll add it to the issue I wrote

[07:23:42.0000] <JakeA>
I'm sure we used to explicitly restrict those

[07:23:53.0000] <wanderview>
JakeA: yea, it got lost at some point

[07:26:43.0000] <JakeA>
Thanks for spotting those!

[07:27:15.0000] <JakeA>
Being able to use a non-network resource as a service worker is a big security issue and footgun

[07:27:37.0000] <wanderview>
JakeA: np!  we are trying to implement the secure context thing which made me start to wonder... we are only blocking file:// right now because we store the SW script in Cache API which rejects it

[10:03:56.0000] <annevk>
wanderview: are you suggesting Worker should be a promise subclass? :-P

[10:04:34.0000] <wanderview>
I didn't know we were talking about Worker, but if you say so

[10:04:53.0000] <wanderview>
I mean, if you think it should be a subclass, ok

[10:04:55.0000] <wanderview>
:-)

[10:05:01.0000] <annevk>
Well, I'm joking

[10:06:51.0000] <annevk>
I wonder if conceptually it makes sense for a worker to be an asynchronous iterable

[10:07:05.0000] <annevk>
Since it's really just a sequence of message events

[10:15:11.0000] <caitp>
clearly it should be a subclass of Observable<T>

[10:21:42.0000] <Ms2ger>
TabAtkins, sounds like you fly too much

[10:22:55.0000] <TabAtkins>
That was my problem, actually. I *always* fly American out of SFO, so I didn't even check the airport this time.

[10:23:37.0000] <Ms2ger>
And thank you for https://pbs.twimg.com/media/CTc9sbTUYAAYhar.png

[10:23:57.0000] <TabAtkins>
Rolled into SFO this morning and checked my terminal, went "lol SFO doesn't have an A terminOH FUCK"

[10:24:31.0000] <TabAtkins>
Can confirm that list is accurate, have received live scorpions.


2015-11-11
[00:04:19.0000] <annevk>
MikeSmith: perhaps close WebAppsWG / DOM as a thing on Bugzilla?

[00:26:35.0000] <annevk>
"A confirmation email has been sent to you." - lies from Twitter

[02:20:23.0000] <MikeSmith>
annevk: does it not have any open bugs?

[02:21:23.0000] <mkwst>
annevk: When you have a minute*, I've reworked most of the bits in https://w3c.github.io/webappsec-credential-management/#opaque-data. I'd appreciate feedback about the things I've certainly missed.

[02:22:01.0000] <mkwst>
And now I need to figure out how much work this is going to be to implement in Chrome. :/ Do you happen to know if anyone other than Firefox implements URLSearchParams? Edge, for instance?

[02:43:58.0000] <annevk>
MikeSmith: I meant close to new bugs

[02:44:15.0000] <MikeSmith>
ah OK

[02:44:16.0000] <annevk>
mkwst: just Firefox

[02:44:33.0000] <MikeSmith>
annevk: yeah can do that now

[02:45:10.0000] <annevk>
mkwst: I wonder now, what you created seems a lot like COWL

[02:46:32.0000] <mkwst>
kinda, I guess?

[02:47:46.0000] <annevk>
mkwst: yeah, not entirely

[02:47:54.0000] <mkwst>
I'd rather just not expose the data. Exposing it with an associated label would be pretty restrictive.

[02:49:02.0000] <annevk>
I guess the thing is that you only get the restrictions if you try to get to the data

[02:49:20.0000] <mkwst>
Right. So let's just not give you the data. :)

[02:49:46.0000] <mkwst>
The use case, I suppose, is a site that wants to munge the password data before sending it up to the server.

[02:49:52.0000] <annevk>
mkwst: 3.3 should mention the data gets given to service workers

[02:50:31.0000] <annevk>
mkwst: you also need to patch the Response interface somehow so this doesn't get leaked through .body

[02:50:54.0000] <mkwst>
Doesn't Response just copy the body from the request? I assumed the flag would carry over.

[02:53:12.0000] <mkwst>
Hrm. Regarding service workers, I was thinking about setting the skip flag. There are probably edge cases that would break (apps doing some sort of local authentication...?), but it seems generally safe.

[02:54:54.0000] <mkwst>
(Why is "skip-service-worker flag" referenced by `skip-service-worker` and not something like `concept-request-skip-service-worker-flag`?)

[02:55:13.0000] <annevk>
mkwst: Response has some custom logic at the moment since only Response handles streams

[02:56:00.0000] <annevk>
mkwst: (flag was a unique enough suffix to not have to bother)

[02:56:18.0000] <mkwst>
but, but... consistency! :)

[02:56:25.0000] <annevk>
mkwst: wait if you pass in an opaque FormData that flag gets set?

[02:56:39.0000] <annevk>
mkwst: how much magic are we introducing?

[02:57:01.0000] <annevk>
mkwst: I'll accept PRs that consistify

[02:57:18.0000] <mkwst>
Lots of magic!

[02:57:23.0000] <mkwst>
Like, 3 magics.

[02:57:28.0000] <annevk>
mkwst: though I'll note that the flags are consistent

[02:57:34.0000] <annevk>
mkwst: hmm

[02:57:44.0000] <mkwst>
https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-2 <-- magic!

[02:58:15.0000] <mkwst>
same-origin request, no redirects, and skip SW.

[03:00:40.0000] <mkwst>
re: Response. Where does it expose the body of the request? It doesn't look like it does?

[03:01:33.0000] <annevk>
mkwst: I'm not sure why request has anything to do with it

[03:01:53.0000] <annevk>
mkwst: (new Response(opaqueData)).body

[03:02:17.0000] <mkwst>
Ah, I see. Synthetic response from a FormData object. Got it, thanks.

[03:02:53.0000] <annevk>
mkwst: you'll need to patch sendBeacon() too I think

[03:03:14.0000] <annevk>
mkwst: and XMLHttpRequest's send()

[03:03:31.0000] <annevk>
mkwst: otherwise you can just leak this cross-origin there or via the service worker...

[03:03:50.0000] <annevk>
mkwst: it seems like a rather fragile setup where you have to patch each place that might take these things

[03:04:03.0000] <mkwst>
annevk: This is why I had my own everything.

[03:05:41.0000] <annevk>
mkwst: perhaps a better way is to have CredentialData and let that have a pointer to a FormData and/or URLSearchParams object

[03:05:50.0000] <annevk>
mkwst: for the additional public fields

[03:06:15.0000] <annevk>
mkwst: and then make Fetch's Body deal with this new CredentialData thingie

[03:06:22.0000] <mkwst>
`sendBeacon()` returns a boolean; where is the data exposed?

[03:06:36.0000] <annevk>
mkwst: the cross-origin server?

[03:06:56.0000] <annevk>
mkwst: or the service worker?

[03:07:11.0000] <mkwst>
I see, sorry. I thought we were still talking about JavaScript access. Thanks.

[03:07:29.0000] <annevk>
Service worker is JavaScript :-P

[03:08:09.0000] <mkwst>
Regarding the "better way": I don't understand the suggestion. You're saying `[credential].toCredentialData()` is this new thing? And we pass that to `fetch()`?

[03:08:46.0000] <annevk>
Maybe just [credential]?

[03:09:10.0000] <annevk>
And give [credential] an additionalData member that can be either a FormData or URLSearchParams object

[03:09:54.0000] <mkwst>
How does that make any of this simpler? :)

[03:10:20.0000] <annevk>
1) We don't have to make FormData or URLSearchParams special

[03:10:50.0000] <annevk>
2) The special casing in Fetch with respect to same-origin and such is clearly derived from credentials rather than opaque data

[03:11:24.0000] <annevk>
3) Any new API that accepts FormData and/or URLSearchParams does not have to worry

[03:11:39.0000] <annevk>
4) Any existing API that accepts FormData and/or URLSearchParams does not require branching

[03:11:49.0000] <annevk>
(or updating)

[03:12:41.0000] <mkwst>
So, the developer would do something like `fetch([url], { body: [credential], ... })`?

[03:12:47.0000] <annevk>
Yes

[03:14:01.0000] <mkwst>
And they'd configure the credential somehow to produce the right body for the fetch operation?

[03:14:30.0000] <annevk>
mkwst: probably by assigning .additionalData to either a FormData or URLSearchParams object (which can be empty)

[03:14:45.0000] <annevk>
mkwst: and we'd just default to that being FormData if it's undefined

[03:15:23.0000] <annevk>
mkwst: and if there's clashes between the FormData/URLSearchParams and credential keys we'd probably drop those of the former

[03:16:24.0000] <mkwst>
Ok. I have a feeling that that's just as invasive/weird, but I'll see what spelling it out looks like. I'm certainly happy to have the functionality tied to the credential object and not the opaqueness flag.

[03:17:08.0000] <annevk>
mkwst: you don't think that not having to touch FormData and URLSearchParams and any of the APIs they interact with alone is worth it?

[03:18:08.0000] <mkwst>
I do think that's worth it. I'm just not sure I understand how it actually prevents the data from leaking, since it all boils down to a FormData/URLSearchParams under the hood.

[03:18:32.0000] <mkwst>
Let me walk through the steps before I argue about it, as I think I'm just misunderstanding the proposal. :)

[03:19:17.0000] <annevk>
mkwst: yeah, there's no FormData or URLSearchParams under the hood, they're just there for the additional fields and determining serialization

[03:21:54.0000] <annevk>
I feel somewhat silly for not having thought of this solution to the additional fields problem earlier

[03:23:05.0000] <mkwst>
Ok. I'll spell it out after lunch to see if I can make it make sense to myself. :) Thanks!

[05:16:27.0000] <mkwst>
annevk: Ok. I think I've wrapped my head around your suggestion. Assuming I've understood it, I like it!

[05:16:53.0000] <mkwst>
annevk: I'm confused a bit about how to differentiate between the places where we want the body to be available and those where we don't, however.

[05:17:00.0000] <mkwst>
When you have a minute*, let me know. :)

[05:19:51.0000] <frewsxcv>
is there any reason why the spec here doesn't just specify CharacterData instead of those three structures specifically? https://dom.spec.whatwg.org/#dom-node-nodevalue

[05:21:40.0000] <jungkees>
annevk:

[05:22:10.0000] <jungkees>
annevk: JakeA I have a question about FetchEvent.clientId

[05:23:13.0000] <jungkees>
annevk: JakeA for a navigation request event.clientId should be the id for the client of the source browsing context, right?

[05:25:29.0000] <JakeA>
jungkees: I'm happy with that, if it matches fetch's definition of client (I think it does)

[05:27:22.0000] <jungkees>
annevk: JakeA: I think request's client in fetch is also the environment where the request is initiated

[05:28:41.0000] <jungkees>
annevk: JakeA: One thing I was confused is.. when the browsing context is navigated, a new client is created which is different from the one the request was initiated..

[05:29:10.0000] <JakeA>
jungkees: in fetch, or in service worker?

[05:30:12.0000] <jungkees>
JakeA: new client here is in Navigate algorithm.. when a new Window object is created

[05:30:20.0000] <annevk>
mkwst: I was assuming we'd expose the body to "fetch" only and since passing a Credential sets the skip service worker flag and same-origin flag we don't really have to consider anything else

[05:30:41.0000] <jungkees>
JakeA: so clients.get(e.clientId) for a navigation request will not return any result

[05:30:53.0000] <mkwst>
annevk: Well, we expose it to fetch by adding it to `BodyInit`, right? Which means we still need to poke at Beacon.

[05:31:19.0000] <annevk>
frewsxcv: I would probably accept a PR that simplifies that

[05:31:36.0000] <JakeA>
jungkees: is new window object always created in navigate? Even with content-disposition responses?

[05:31:38.0000] <jungkees>
JakeA: as the client for that id should be gone by that time.. Is it an expected behavior?

[05:31:54.0000] <annevk>
mkwst: we could also do (BodyInit or Credential) in Fetch

[05:32:00.0000] <jungkees>
I don't think with content-disposition case

[05:32:00.0000] <annevk>
mkwst: to avoid adding it elsewhere

[05:32:08.0000] <mkwst>
annevk: Yeah. I was thinking that too.

[05:32:19.0000] <annevk>
mkwst: I like that better since it avoids XMLHttpRequest too

[05:32:29.0000] <mkwst>
annevk: But put that to the side for the moment.

[05:33:02.0000] <jungkees>
JakeA: but in general in Navigate (https://html.spec.whatwg.org/multipage/browsers.html#navigate) step 24, it create a new Window object

[05:33:26.0000] <mkwst>
It's not clear to me what pieces I need to define in order to ensure that `Body`'s various methods won't leak data, while at the same time allowing the Fetch mechanisms to actually submit something.

[05:33:47.0000] <mkwst>
That is, if I override `extract` or `consume body`, I break various things.

[05:35:17.0000] <JakeA>
jungkees: since the window isn't always created, I guess a client isn't always created. The clientId should reference the initiating client, or be undefined

[05:35:21.0000] <annevk>
mkwst: yeah, I see what you mean

[05:37:37.0000] <jungkees>
JakeA: yeah, I agree event.clientId should reference the *initiating client*.

[05:37:52.0000] <annevk>
mkwst: it seems like adding an opaque flag to request and setting/checking that would be the way to go

[05:38:20.0000] <jungkees>
JakeA: then in which occasion would it be undefined? when the document/window was discarded before the UA fires fetch event?

[05:38:40.0000] <mkwst>
annevk: Doing that in "consume body", you mean?

[05:38:52.0000] <mkwst>
(That is, throwing in "consume body" iff the flag is set)

[05:39:08.0000] <JakeA>
jungkees: if the initiator was another origin

[05:39:28.0000] <annevk>
mkwst: yeah, similar to the disturbed flag

[05:39:39.0000] <mkwst>
ok. i'll try that out.

[05:39:51.0000] <jungkees>
JakeA: yeah that shouldn't be exposed

[05:40:57.0000] <jungkees>
JakeA: so by saying "a client for a navigation request could be null" in our previous discussion meant that case basically?

[05:41:13.0000] <JakeA>
jungkees: yep!

[05:41:18.0000] <jungkees>
JakeA: alright!

[05:41:35.0000] <annevk>
I think for navigation the client would be pretty much always null

[05:41:40.0000] <annevk>
Since the client is what's being requested

[05:42:29.0000] <jungkees>
annevk: I don't think it is the case for FetchEvent.clientId?

[05:43:04.0000] <jungkees>
annevk: Shouldn't it be *initiating* client's id?

[05:43:16.0000] <annevk>
Define initiating?

[05:43:39.0000] <jungkees>
annevk: I mean request's client

[05:44:17.0000] <jungkees>
annevk: a fetch event abstracts a request basically

[05:45:12.0000] <annevk>
Hmm, I wonder if the specification is correct for all this

[05:45:22.0000] <annevk>
Navigation is really poorly defined

[05:45:55.0000] <jungkees>
annevk: the client for a fetch event being a client for a destination of the requested resource seems odd though

[05:46:40.0000] <jungkees>
annevk: in the current Navigate algorithm, request's client is set to the source browsing context's Window object's environment settings object always

[05:47:18.0000] <annevk>
Sure

[05:48:20.0000] <annevk>
jungkees: you want to store clientID on document btw

[05:49:12.0000] <annevk>
Anyway, I think it's unlikely we'll find good answers here until navigation is more flushed out

[05:49:55.0000] <jungkees>
annevk: I didn't look that bit yet

[05:51:22.0000] <jungkees>
annevk: but I see places in Handle Fetch that I should update.. basically need to move some steps that update the service worker client's state to HTML I guess

[05:53:01.0000] <mkwst>
annevk: When my next minute* comes around, I'd appreciate it if you could skim https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch.

[05:59:03.0000] <annevk>
mkwst: you also need to propagate the flag when you create a new Request object from an existing Request object

[06:00:25.0000] <annevk>
mkwst: and some of the stuff needs to use internal algorithms rather than set() directly, and we probably want to structured clone or equivalent FormData/URLSearchParams first as otherwise the password would still be exposed to those holding a reference

[06:03:51.0000] <mkwst>
annevk: Good points, all. Thanks.

[06:07:22.0000] <annevk>
mkwst: ah, no structured clone defined yet, so you want to do something equivalent to that

[06:07:58.0000] <mkwst>
Yeah. I wrote "a copy of" and will actually define things if we decide to go this route.

[06:10:50.0000] <mkwst>
can I write something like "Execute the initial value of `set(name, value)` on x and y"? Or do I really need to copy/paste the algorithm out of XHR>?

[06:15:30.0000] <annevk>
mkwst: I think it would be easier to update https://fetch.spec.whatwg.org/#concept-bodyinit-extract with something specific for credentials

[06:16:11.0000] <mkwst>
That's what I'm doing?

[06:16:13.0000] <annevk>
mkwst: "copy" the form data or object's list, mangle that with the password stuff, serialize

[06:16:18.0000] <mkwst>
Or you mean, don't recurse into extract again?

[06:16:48.0000] <annevk>
mkwst: yeah, perhaps do abstract out some bits from extract so you can reuse them

[06:17:50.0000] <mkwst>
It seems like that would be harder than just adjusting the FormData or URLSearchParams object.

[06:19:41.0000] <mkwst>
Well, maybe not. You're suggesting that I take out the internal list, operate on it, and then feed it into the appropriate encoding algorithm?

[06:19:59.0000] <mkwst>
 I guess that would let me avoid defining structured clone on those objects.

[06:20:02.0000] <annevk>
mkwst: yeah

[06:32:18.0000] <frewsxcv>
what does this mean? https://github.com/whatwg/dom/blob/master/dom.bs#L3227

[06:41:23.0000] <wanderview>
JakeA: jungkees: you guys are saying if I follow a link from searchengine.com that is not controlled, and navigate to a controlled page, the clientid will point at the cross-origin, non-controlled searchengine.com?

[06:42:00.0000] <wanderview>
or maybe you guys moved past that

[06:42:31.0000] <wanderview>
I think I agree with annevk the clientId should be null for navigate

[06:43:04.0000] <JakeA>
wanderview: we said it'd be undefined if the client was cross origin. Although I'm happy for always null, no strong feelings

[06:43:12.0000] <wanderview>
I've just been dealing with a lot of this stuff for getting console reports back to the right window for a navigation... its a major pain

[06:43:30.0000] <wanderview>
JakeA: undefined is fine... but it feels weird to me to point to the initiating client for a navigation

[06:43:46.0000] <annevk>
frewsxcv: {{Text}}?

[06:44:02.0000] <frewsxcv>
annevk: sorry, line above that https://github.com/whatwg/dom/blob/master/dom.bs#L3226

[06:44:02.0000] <annevk>
frewsxcv: it's a bikeshed shortcut for referencing an object

[06:44:13.0000] <JakeA>
wanderview: why does it feel weird? (I don't disagree, just curious)

[06:44:28.0000] <annevk>
frewsxcv: ah, AttrExodus is basically https://github.com/whatwg/dom/issues/102

[06:44:53.0000] <wanderview>
JakeA: I mean, what if the SW wants to postMessage() the client its controlling... I think it would be natural to assume that is FetchEvent.clientId

[06:45:04.0000] <wanderview>
but in this case it would not be... it would some other random page

[06:45:43.0000] <JakeA>
wanderview: that would work fine in the content-disposition case

[06:45:56.0000] <JakeA>
Since the previous client remains

[06:46:16.0000] <wanderview>
JakeA: I'm really thinking about non-controlled navigates to controlled case

[06:46:37.0000] <wanderview>
doesn't have to be cross-origin... ctrl-shift-reload and you have a non-controlled window

[06:46:41.0000] <JakeA>
But I agree it's not useful in a navigate case. Might be useful in a "open in new tab" case as the client stays around

[06:46:53.0000] <JakeA>
Ohh I see

[06:47:26.0000] <JakeA>
Yeah, this would be the one case where the request's client isn't controlled

[06:47:55.0000] <wanderview>
JakeA: well, it could also be across scope boundaries on same origin... from ~alice home dir to ~bob home dir

[06:49:13.0000] <wanderview>
JakeA: I guess it would be nice if we had some definition of FetchEvent.clientId that was consistent... "always the client that initiated even if its not-controlled"... or "the client being controlled by this service worker related to this network event"

[06:49:21.0000] <wanderview>
I think that latter is more likely to be what people expect

[06:49:32.0000] <wanderview>
but I'm a terrible judge of these things

[06:53:47.0000] <JakeA>
wanderview: well, I think the definition we were going for is "the client that initiated the request, unless it's cross-origin"

[06:53:56.0000] <JakeA>
wanderview: but I'm happy to make an exception for navigations

[06:54:59.0000] <wanderview>
JakeA: hmm, ok... my confusion then... I don't think we should make an exception for navigation

[06:55:29.0000] <JakeA>
wanderview: I'm not too bothered because I don't think client is useful for navigations

[06:55:45.0000] <JakeA>
wanderview: in future, we might want something like fetchEvent.getDestinationClient() that returns a promise for the client that processes the response

[06:56:01.0000] <JakeA>
which, in a navigation's case, would be the new client

[06:56:04.0000] <wanderview>
JakeA: I'm more worried about a service worker that tries to use it and doesn't distinguish between navigations and non-navigations... and gets unexpected behavior

[06:56:20.0000] <JakeA>
not sure what would happen in the content-disposition case though… I guess that's still a new client

[06:57:08.0000] <JakeA>
wanderview: I can see people expecting clientId to be referencing the *new* client for navigations

[06:57:35.0000] <JakeA>
but it seems too early to have that, maybe I'm wrong

[06:58:00.0000] <wanderview>
yea, it would be very different from a client is today I think... the window/worker/etc always exists before the Client object today AFAICT

[06:58:09.0000] <JakeA>
I guess we know there will be a new client, it's only <object> where it isn't deterministic

[06:58:20.0000] <JakeA>
wanderview: agreed

[06:58:52.0000] <wanderview>
JakeA: is there a client if the SW ends up rejecting the respondWith()?  is the error page considered a client?

[06:59:17.0000] <JakeA>
wanderview: I suppose it's other-origin so no

[06:59:42.0000] <wanderview>
JakeA: not sure chrome considers it other-origin based on some wpt tests we saw

[07:00:02.0000] <wanderview>
JakeA: another condition that would be tricky... provide the Client object, but then the SW returns an opaqueredirect that goes... somewhere

[07:00:12.0000] <wanderview>
you could end up same-origin or cross-origin

[07:00:26.0000] <JakeA>
wanderview: ohhh, so if I window.open a page, get a network failure, I can get at the DOM of the error page? That seems weird

[07:00:51.0000] <JakeA>
wanderview: ah yes, that's a perfect reason not to expose eventual client

[07:00:58.0000] <wanderview>
JakeA: some of the blink wpt tests assumed the frame.contentwindow was available to top level window, yes... we don't expose frame.contentwindow if the frame is an error page in gecko

[07:01:36.0000] <wanderview>
maybe blink hides the contents of frame.contentwindow... I think error pages are basically unspec'd...

[07:01:42.0000] <wanderview>
or loosely spec'd

[07:02:01.0000] <JakeA>
interesting

[07:05:11.0000] <wanderview>
JakeA: might be interesting if we pass the initiating client in FetchEvent.clientId for a navigation... and then the SW uses it to call Client.navigate()

[07:06:17.0000] <JakeA>
wanderview: heh, I wonder when pages stop listening to further navigation attempts. I guess they don't until they're gone?

[07:07:03.0000] <wanderview>
JakeA: I suppose navigate() could throw InvalidState or something... but its a bit wonky

[07:08:52.0000] <wanderview>
annevk: does the spec say when a window is destroyed?

[07:09:10.0000] <wanderview>
I seem to recall bz telling me window destruction was basically not defined and everything leaks as far as the spec is concerned

[07:14:50.0000] <wanderview>
JakeA: I guess the ability to navigate something thats already navigating suggests to me maybe we shoudl just set clientId undefined for navigations

[07:15:11.0000] <wanderview>
to start anyway

[07:31:21.0000] <annevk>
wanderview: some of it is defined afaik

[07:32:05.0000] <annevk>
wanderview: see stuff around "discard a Document"

[07:36:37.0000] <wanderview>
annevk: doesn't seem to define clearly when thats invoked "User agents may discard top-level browsing contexts at any time (typically, in response to user requests, e.g. when a user force-closes a window containing one or more top-level browsing contexts). "

[07:37:32.0000] <wanderview>
JakeA: another problematic issue might be... with a navigation the initiating document might end up in the bfcache... if client means document, then allowing SW to postMessage a document in the bfcache seems weird to me... I guess thats impl issue, but its complexity

[07:38:30.0000] <JakeA>
wanderview: yeah, it seems like undefined is a good answer until we work it out

[07:39:19.0000] <wanderview>
thanks

[07:39:22.0000] <wanderview>
jungkees: ^^^

[08:48:38.0000] <wanderview>
annevk: JakeA: what was the outcome for this issue at the f2f?  its hard to tell from the issue text https://github.com/slightlyoff/ServiceWorker/issues/719

[08:56:36.0000] <JakeA>
wanderview: it's for annevk and sicking to fight it out still

[08:57:53.0000] <sicking>
JakeA: no opinion from the Google sec team?

[08:58:39.0000] <JakeA>
sicking: I'll try and drag one of them into it

[08:58:53.0000] <sicking>
cool, thanks

[08:59:14.0000] <wanderview>
JakeA: sicking: does this pending cage match also include the same issue for Performance API?

[08:59:30.0000] <wanderview>
I assume so

[08:59:31.0000] <JakeA>
yep

[08:59:36.0000] <wanderview>
ok, thanks

[08:59:43.0000] <sicking>
i don't know what the issue is for Performance API

[09:00:08.0000] <wanderview>
sicking: it has the same problem where it provides information about subresources via timing markers and whatnot

[09:00:13.0000] <sicking>
but I think my opinion about 719 is pretty specific to stylesheets

[09:00:31.0000] <wanderview>
sicking: right... its performance API + stylesheets issue

[09:00:32.0000] <sicking>
wanderview: does it affect only stylesheets? Or other things as well?

[09:01:07.0000] <JakeA>
sicking: just stylesheets. The resource timing API will tell you about imports and bg images, as serviceworker does/did

[09:01:17.0000] <sicking>
ok, then yeah, it'll probably be the same outcome

[09:01:26.0000] <wanderview>
sicking: see the private message I sent you

[09:04:49.0000] <annevk>
JakeA: I thought that was resolved to not introduce more SOP holes

[09:05:56.0000] <JakeA>
annevk: that's certainly what we're doing for v1, but it's backwards compatible to change to the other thing should sicking defeat you in the battle of the century

[09:06:58.0000] <JakeA>
If your CSS is on a static host it can make things tougher, but I get the SOP thing so I'm not fighting it

[09:07:22.0000] <sicking>
JakeA: this is a crazy idea, but do you think it would be web compatible to load cross-site stylesheets without cookies?

[09:08:01.0000] <wanderview>
wait, we want to implement this in v1 and then maybe remove it in v2?  its not really trivial to implement correctly

[09:08:54.0000] <annevk>
wanderview: so far nobody from the security team has actually agreed with sicking so I doubt we'd remove it in v2

[09:09:34.0000] <wanderview>
annevk: sicking: I'm thoroughly confused about what I should be implementing or not

[09:09:59.0000] <sicking>
JakeA: unless you do something like <link rel=stylesheet crossorigin="use-credentials">

[09:10:10.0000] <annevk>
wanderview: the version without the new SOP hole

[09:10:38.0000] <sicking>
wanderview: my opinion is certainly that you shouldn't spend time on it. But clearly Anne disagrees

[09:10:38.0000] <annevk>
sicking: I'm not sure why we'd want to try that, let alone couple it with this

[09:10:52.0000] <wanderview>
annevk: I feel this is 180 degrees from the first response I got from JakeA

[09:11:06.0000] <sicking>
annevk: *shrug*. we don't have to couple it

[09:11:28.0000] <annevk>
wanderview: see above, I recalled something different from him

[09:11:34.0000] <JakeA>
sicking: if that was a good answer we'd allow access to the response of any non-credentialed request

[09:11:42.0000] <JakeA>
but then there's the intranet & local server issue

[09:12:13.0000] <sicking>
JakeA: i'm not saying that it makes it 100% safe. But it makes it *a lot* less likely that the response contains sensitive data

[09:12:21.0000] <wanderview>
JakeA: is chrome putting in this block?  and how is it implementing the corner cases I ask about here? https://github.com/slightlyoff/ServiceWorker/issues/719#issuecomment-149908726

[09:13:02.0000] <sicking>
JakeA: keep in mind that we're already leaking a lot of data from text/css resources on intranet/local servers

[09:13:25.0000] <JakeA>
sicking: I agree, but it seems weird to do a special thing for CSS here. Personally I'm happy with exposing background img requests & @import, but I can't deny it's exposing more info than we do now

[09:14:26.0000] <sicking>
JakeA: i'm not saying it's a perfect solution. There definitely aren't any here.

[09:16:31.0000] <JakeA>
sicking: it's annevk you have to convince. I think it's safe to say that request triggered by resolved styles are already exposed through getComputedStyle, but font urls and @import are not. It's whether we care

[09:16:49.0000] <JakeA>
I don't particularly care… buuuuut I don't have a good argument aside from "c'moooooon"

[09:17:33.0000] <sicking>
JakeA: my question is just if you think it's web-compatible

[09:17:59.0000] <JakeA>
wanderview: those are good edge cases. I think the rule annevk wants is "if the CSSOM doesn't expose it, the SW shouldn't hear about the requests it triggers"

[09:18:29.0000] <JakeA>
sicking: to drop cookies from CSS requests? That sounds like a big change. I worry about font providers

[09:18:43.0000] <wanderview>
JakeA: does CSSOM have the same issue?  can it bypass an intermediate cross-origin stylesheet and see stuff in a same-origin @import further down the tree?

[09:18:48.0000] <JakeA>
But I don't have any failure cases to show off-hand

[09:18:56.0000] <JakeA>
wanderview: I don't know :(

[09:19:08.0000] <annevk>
wanderview: nope

[09:19:25.0000] <sicking>
it can see background-image further down the tree

[09:19:27.0000] <JakeA>
Actually, I think you'd need to go through the cross origin CSSOM to get to the import

[09:19:52.0000] <sicking>
and other uris that are part of style

[09:19:56.0000] <JakeA>
so even if b.com's css @imports back to a.com, you won't be able to get the CSSOM for it

[09:21:10.0000] <sicking>
a rule like ".error { background-image: url(...)" exposes the url no matter how deep in the import chain the rule lives

[09:21:53.0000] <annevk>
right, that's not the interesting case

[09:22:30.0000] <annevk>
although even there exposing the URL directly is very different from having to recreate all possible selectors

[09:22:40.0000] <JakeA>
sicking: font urls and @import aren't exposed through computed styles

[09:22:50.0000] <sicking>
JakeA: right

[09:23:09.0000] <sicking>
annevk: i don't agree that it's very different

[09:23:09.0000] <annevk>
having to create all possible trees, really

[09:23:31.0000] <sicking>
try to explain to anyone what is and is not safe

[09:24:00.0000] <sicking>
I think the only reasonable thing you would say is "that url is exposed"

[09:24:33.0000] <sicking>
you don't have to enumerate all possible trees or all possible selectors

[09:24:38.0000] <annevk>
we still made :visited attacks harder

[09:24:46.0000] <sicking>
that is very different

[09:25:00.0000] <annevk>
Why don't you have to enumerate trees and classes, etc.?

[09:25:01.0000] <sicking>
that wasn't about exposing information in stylesheets

[09:25:16.0000] <sicking>
you don't have to enumerate *all* trees/classes

[09:25:26.0000] <sicking>
you just have to enumerate enough of them

[09:25:37.0000] <sicking>
good luck explaining which ones can or can't be enumerated

[09:26:11.0000] <sicking>
if i saw a rule like the above, i would definitely tell the developer that that rule could be read

[09:27:21.0000] <annevk>
For that example, sure

[09:29:49.0000] <sicking>
JakeA: so what is google implementing in this area?

[09:30:18.0000] <annevk>
But I think there is a difference between handing the attacker all URLs and making them work for a subset of URLs

[09:31:11.0000] <JakeA>
sicking: I haven't heard any objections to "fixing" this, but I haven't talked directly to the team about it

[09:31:21.0000] <sicking>
JakeA: ok

[09:31:46.0000] <sicking>
annevk: the difference is fairly small, and comes at a high cost

[09:32:20.0000] <wanderview>
I'm inclined not to block our release of SW on this issue

[09:32:32.0000] <annevk>
*shrug*

[09:32:50.0000] <JakeA>
wanderview: we've shipped with it, resource timing has the same issue

[09:32:50.0000] <sicking>
annevk: as an author, i would effectively have to assume that any rules can be guessed and not put sensitive information in URLs other than @import ones and fonts

[09:33:30.0000] <wanderview>
JakeA: yea, and I think we should try to define some of the details before implementing... because there is enough nuance here we could end up with incompatible implementations

[09:33:31.0000] <JakeA>
I'm less worried about breaking the security of the web with this, more concerned about breaking sites that come to rely on current Chrome (and soon Firefox) behaviour

[09:34:05.0000] <sicking>
same here

[09:37:18.0000] <wanderview>
JakeA: also, the spec has been changed for resource timing, but in a way which does not really address @import at all as far as I can tell

[09:37:31.0000] <wanderview>
doesn't address the corner cases from @import, I mean

[09:40:54.0000] <wanderview>
annevk: JakeA: did you guys talk about the storage API v2 stuff at all at the f2f?

[09:41:09.0000] <wanderview>
storage pressure events vs boxes, etc

[09:41:16.0000] <JakeA>
wanderview: nah, we only dealt with v1 stuff

[09:41:40.0000] <wanderview>
ok

[09:41:41.0000] <JakeA>
we'll have more fun at the next f2f with v2 stuff, which will be in the US

[09:41:49.0000] <wanderview>
JakeA: is there a date for it?

[09:42:35.0000] <JakeA>
wanderview: there's rumblings of a web components f2f… if that comes together in early December we'll try and sync with that. Otherwise it'll be mid-late Feb

[09:42:56.0000] <JakeA>
Then April in SF for the extensible web summit

[09:44:07.0000] <wanderview>
ok, thanks

[10:53:57.0000] <wanderview>
does anyone here have a link to that research that showed interstitials prompting to install apps reduced engagement?

[10:54:06.0000] <wanderview>
JakeA: I seem to recall you mentioning it before...

[10:56:28.0000] <wanderview>
nevermind, I finally found it: http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html

[11:39:35.0000] <wanderview>
Domenic: has ReadableStream constructor shipped in chrome yet?

[11:44:19.0000] <wanderview>
I guess not... I get "Illegal constructor" in canary devtools

[11:45:14.0000] <wanderview>
and it still thinks ReadableByteStream is a thing

[11:55:05.0000] <Domenic>
Yeah still trying to land the patch but vacation plus BlinkOn plus TC39...

[11:59:46.0000] <annevk>
JakeA: FWIW, early December won't have any Mozillians attending most likely

[15:28:18.0000] <JakeA>
annevk: sorry, I meant if the plan comes together *by* December I'll sync with that, rather than organise something independent for February


2015-11-12
[19:35:49.0000] <caitp>
q2 2015, all your problems will be solved, and you'll have a freshly minted set of new problems

[19:36:03.0000] <caitp>
er, 2016 =]

[00:18:09.0000] <annevk>
gsnedders: could you have a look at https://github.com/whatwg/html/pull/329?

[02:42:11.0000] <bblfish>
hi annevk , all, I am having trouble with ServiceWorkers

[02:42:20.0000] <bblfish>
I have tried a few things

[02:42:50.0000] <bblfish>
If I start a ServiceWorker locally at http://localhost:63342/rww-scala-js/root/html/foaf.html

[02:43:01.0000] <bblfish>
I can see it intercept local calls

[02:43:35.0000] <bblfish>
But the serviceworker does not seem to catch a call to  https://joe.example:8443/2013/card#me

[02:43:50.0000] <bblfish>
( without the hash )

[02:44:16.0000] <bblfish>
$ curl -ik  https://joe.example:8443/2013/card | head

[02:44:25.0000] <bblfish>
HTTP/1.1 401 Unauthorized

[02:44:25.0000] <bblfish>
Access-Control-Allow-Origin: *

[02:44:25.0000] <bblfish>
Content-Type: text/html; charset=utf-8

[02:44:27.0000] <bblfish>
WWW-Authenticate: Signature realm="/"

[02:44:29.0000] <bblfish>
Content-Length: 2374

[02:45:39.0000] <bblfish>
If I run Chrome with `chromium --unsafely-treat-insecure-origin-as-secure=https://joe.example:8443 --user-data-dir=/tmp/hjs/ ` and start with a page  http:s//joe.example:8443/rww-scala-js/root/html/foaf.html

[02:46:11.0000] <bblfish>
then the serviceworker won't load due to a TLS exception ( probably due to self signed cert )

[02:48:35.0000] <annevk>
What does call mean?

[02:48:53.0000] <annevk>
Self-signed certificates are a bad idea, just don't

[02:49:09.0000] <bblfish>
call = GET

[02:49:25.0000] <annevk>
That is not sufficient context

[02:49:28.0000] <bblfish>
well I am using self signed cert to run the server on my local machine

[02:51:34.0000] <bblfish>
this is the call annevk https://github.com/read-write-web/rww-scala-js/blob/fcec7c88c78f626ec04d60e64999deda15633958/src/main/scala/rww/store/WebResourceActor.scala#L106

[02:52:46.0000] <bblfish>
and this is the fetch event listener https://github.com/read-write-web/rww-scala-js/blob/fcec7c88c78f626ec04d60e64999deda15633958/src/main/scala/rww/auth/ServiceWorkerAuth.scala#L137

[02:54:53.0000] <annevk>
I don't really understand this code

[02:55:45.0000] <annevk>
Are you saying that foaf.html has some JavaScript that uses fetch() to get to the joe.example resource and somehow that does not get intercepted?

[02:57:36.0000] <bblfish>
yes. fhttp://localhost:63342/rww-scala-js/root/html/foaf.html is a Single Page App written in Scala-JS compiled to JS that uses fetch ( first link above ) to get the joe.example card URL that I curled above. That fetch does not get intercepted.

[02:58:09.0000] <bblfish>
does not get intercepted by the ServiceWorker.

[02:59:14.0000] <bblfish>
Not sure if that is an issue with ServiceWorkers only intercepting HTTPS calls, or what it could be due to.

[02:59:36.0000] <bblfish>
this is a cross origin call.

[03:00:23.0000] <bblfish>
Also I am not even sure if I am meant to be able to do this.

[03:00:49.0000] <annevk>
That sounds like a bug. Are you sure the service worker is properly registered and used for the page?

[03:02:24.0000] <bblfish>
Well it does register and intercepts. Perhaps it needs to be tuned

[03:02:59.0000] <bblfish>
I have the following in my console

[03:02:59.0000] <bblfish>
 ServiceWorker registered Thu Nov 12 2015 10:40:33 GMT+0000 (GMT) successfully : {"installing":null,"waiting":null,"active":{}}

[03:04:51.0000] <bblfish>
btw. the initial non service worker Fetch code does receive a response and it knows it received a 401

[03:05:13.0000] <bblfish>
but it only seems to get 1 header -> content-type:text/html; charset=utf-8

[03:06:31.0000] <bblfish>
That is Chromium 48.0.2561.0 canary

[03:06:38.0000] <bblfish>
perhaps I'll try Firefox to see

[03:10:04.0000] <bblfish>
Same in Firefox Developer edition 44.0a2 (2015-11-05)

[03:11:58.0000] <bblfish>
If I fetch localhost content I get full headers in the fetch response, but with remote fetch I only get the content-type header

[03:13:44.0000] <annevk>
Ms2ger: when you introduced /target override/, is it correct that everything else in the algorithm is then relative to target override?

[03:13:59.0000] <annevk>
Ms2ger: that seems wrong, because if that is the case, why would you not just set target to something else

[03:15:08.0000] <annevk>
bblfish: it's unclear whether that means the service worker is the active one for the document

[03:17:14.0000] <Ms2ger>
annevk, uh, not sure

[03:17:30.0000] <Ms2ger>
annevk, the thing is that you need to set event.target to something else?

[03:18:12.0000] <annevk>
Ms2ger: yeah, but the rest of the algorithm uses event.target for various things

[03:18:22.0000] <Ms2ger>
Hmm

[03:18:25.0000] <annevk>
Ms2ger: I'm thinking the rest of the algorithm should probably use /target/ for that

[03:18:28.0000] <annevk>
Ms2ger: reviewing this

[03:18:38.0000] <Ms2ger>
I think that may be the case, yes

[03:18:51.0000] <annevk>
Ms2ger: I'm in the process of making this all a bit more clear with more explicit arguments

[03:19:10.0000] <annevk>
Ms2ger: I guess I'll fix that in a distinct commit

[03:19:16.0000] <annevk>
Ms2ger: somewhat surprised nobody catched it thus far

[03:19:32.0000] <bblfish>
mhh, trying to test the ServiceWorker.

[03:19:35.0000] <annevk>
Ms2ger: confirms that this is almost never read

[03:22:47.0000] <bblfish>
if I remove all the code from the fetchListener except the log then I do see the service worker intercepting the call.

[03:22:55.0000] <bblfish>
What it does not like is the  e.respondWith { ... }

[03:22:58.0000] <bblfish>
it seems

[03:23:54.0000] <annevk>
bblfish: what does it do?

[03:26:07.0000] <bblfish>
well without e.respondWith  it tells me I made a call in the console. with it not even that happens.  https://github.com/read-write-web/rww-scala-js/blob/fcec7c88c78f626ec04d60e64999deda15633958/src/main/scala/rww/auth/ServiceWorkerAuth.scala#L137

[03:27:26.0000] <Ms2ger>
annevk, do you have a test too? :)

[03:27:48.0000] <annevk>
Ms2ger: I haven't checked yet

[03:27:54.0000] <annevk>
Ms2ger: still refactoring

[03:28:04.0000] <annevk>
Ms2ger: did you create a test for the target override stuff?

[03:28:24.0000] <Ms2ger>
Good question

[03:30:22.0000] <bblfish>
which is pretty weird...

[03:31:06.0000] <annevk>
Ms2ger: cannot really find anything

[03:31:33.0000] <Ms2ger>
annevk, html/syntax/parsing/the-end.html has a check

[03:31:41.0000] <Ms2ger>
  window.addEventListener("load", this.step_func_done(function(e) {

[03:31:41.0000] <Ms2ger>
    assert_equals(e.target, document, "target should be document");

[03:32:48.0000] <annevk>
Ms2ger: so per the language in the spec right now, ignoring the obvious problems with talking about members directly rather than internal slots, that event would also dispatch on document

[03:33:51.0000] <annevk>
Ms2ger: and not only that, its phase on window would be BUBBLING and/or CAPTURE

[03:34:38.0000] <annevk>
Ms2ger: it seems you chickened out of testing eventPhase though

[03:36:46.0000] <Ms2ger>
annevk, patches welcome, or file an issue :)

[03:39:17.0000] <annevk>
Ms2ger: <script>document.onload=onload=x=>w(x.eventPhase)</script> is my minimal testcase

[03:39:23.0000] <annevk>
Ms2ger: returns 2 and only once

[03:39:53.0000] <annevk>
Ms2ger: so yeah, /override target/ should only override event's target and nothing else

[03:47:56.0000] <annevk>
Ms2ger: haha

[03:48:08.0000] <annevk>
Ms2ger: I just noticed I fixed this exactly two years after you broke it with https://github.com/whatwg/dom/commit/d0f2c0bbc940061ac2a4623553de5c26409cce96

[03:50:06.0000] <annevk>
Ms2ger: https://github.com/w3c/web-platform-tests/issues/2321

[03:52:43.0000] <bblfish>
annevk: this actually works https://github.com/read-write-web/rww-scala-js/blob/fcb110260cf8fe39fa5260bae14d7a73181bdf9d/src/main/scala/rww/auth/ServiceWorkerAuth.scala#L137

[03:53:11.0000] <annevk>
bblfish: you can keep sending me scala links, but my ability to comprehend them is not increasing

[03:53:53.0000] <bblfish>
yep. It's probably to do with my trying to cast the scala promise in the andThen { } which returns a Promise[Any] to a Promise[Response] is the problem

[03:54:41.0000] <bblfish>
I'll ask the scala-js folks

[03:56:44.0000] <bblfish>
yep.

[03:58:50.0000] <bblfish>
there is a problem with scala-js that I need to work out with them, but I have found a workaround https://github.com/read-write-web/rww-scala-js/blob/b342c8f9c54825eab300ac264a4f26774ea31b52/src/main/scala/rww/auth/ServiceWorkerAuth.scala#L137

[03:59:16.0000] <bblfish>
annevk: that actually works. The problem is here that I only get the Content-Type header, not the WWW-Authenticate one

[03:59:29.0000] <annevk>
Ms2ger: is filing issues for tests that need to be created acceptable?

[03:59:35.0000] <annevk>
Ms2ger: I guess I could do that more often

[03:59:52.0000] <Ms2ger>
annevk, yes, please do

[03:59:58.0000] <annevk>
bblfish: so you're using CORS?

[04:00:15.0000] <bblfish>
perhaps I have to add another header to cors.

[04:00:24.0000] <annevk>
bblfish: are you using Access-Control-Expose-Headers?

[04:00:51.0000] <bblfish>
nope. TimBl's card has also this one Access-Control-Allow-Credentials: true

[04:01:30.0000] <bblfish>
curl  -i https://www.w3.org/People/Berners-Lee/card | less

[04:03:00.0000] <bblfish>
I'll try adding those. Perhaps then I won't actually need serviceworkers...

[04:03:38.0000] <annevk>
If you just want to inspect a networked resource, you don't need service workers

[04:55:48.0000] <bblfish>
annevk: I added `Access-Control-Expose-Headers: WWW-Authenticate` and I can see it then from the normal fetch

[04:57:42.0000] <bblfish>
thanks for the help.  Sitting on too many bleeding edges : Fetch, WebCrytpo, Scala-JS, ServiceWorkers, soon IndexDb ( to store the key at least. )

[04:58:30.0000] <bblfish>
...cors,

[04:59:30.0000] <bblfish>
... TLS

[05:13:45.0000] <annevk>
CORS is pretty old now

[05:18:29.0000] <espadrine>
on the other hand, TLS…

[05:34:23.0000] <annevk>
Well, yes

[05:49:11.0000] <zcorpan>
is it possible to escape @mention and emoji with github flavored markdown? backslash doesn't work. `@`mention works but looks funny

[05:51:40.0000] <zcorpan>
html entity doesn't work either

[05:58:10.0000] <annevk>
yoav: interested in providing another PR?

[05:58:37.0000] <yoav>
annevk: yeah, I'm taking a stab at adding that text.

[05:59:48.0000] <annevk>
cool

[05:59:57.0000] <annevk>
zcorpan: non-visible space?

[06:01:59.0000] <zcorpan>
annevk: yep, thanks

[06:08:54.0000] <zcorpan>
/me filed https://github.com/jch/html-pipeline/issues/232

[06:35:37.0000] <zcorpan>
https://github.com/whatwg/resources.whatwg.org/pull/10 https://github.com/whatwg/resources.whatwg.org/pull/11

[06:42:16.0000] <annevk>
zcorpan: should prolly get Domenic to review? Looks fine to me though

[06:43:41.0000] <zcorpan>
ok

[07:15:22.0000] <Domenic>
zcorpan: assuming you have smoke tested these LGTM

[07:15:37.0000] <zcorpan>
i have yeah

[07:15:37.0000] <Domenic>
Seems like there should be a better way to do the first...

[07:16:04.0000] <Domenic>
But all I can think of is code-ifying everything

[07:16:17.0000] <zcorpan>
first what?

[07:16:18.0000] <Domenic>
Maybe there is a Markdown escaper algorithm somewhere

[07:16:23.0000] <Domenic>
The first PR

[07:17:18.0000] <zcorpan>
oh, yeah i suppose you could have a state machine instead, but this is only 1000 characters

[07:19:22.0000] <zcorpan>
i considered having a single replace(regexp, func) but i thought it looked too bloated

[07:19:36.0000] <zcorpan>
this seems like simplest to maintain

[07:21:02.0000] <Domenic>
Yeah seems good

[07:23:32.0000] <smaug____>
annevk: sanity check, please :)  "Let target be the MessagePort in whose port message queue the event e now finds itself." sounds odd to me in https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage  e is a DOM event which has just been created, not put to any queue

[07:23:50.0000] <smaug____>
and "port message queue " is a task source, not some DOM event queue

[07:24:22.0000] <smaug____>
am I missing something?

[07:24:26.0000] <zcorpan>
https://github.com/w3c/webvtt/pull/253 would like review from html folks on this. (i think the lack of "parse error" is technically wrong for a lone ampersand, but then webvtt parser doesn't discuss parse errors in the first place, yet...)

[07:31:10.0000] <smaug____>
https://github.com/whatwg/html/issues/333

[09:00:37.0000] <bblfish>
annevk: true, they are not all bleeding edge. :-) Still quite a lot of new tools to get a grip with.

[09:50:39.0000] <annevk>
smaug____: yeah that reads weird

[09:50:56.0000] <annevk>
smaug____: furthermore, it seems weird that the MessageEvent is created way before being dispatched

[09:51:06.0000] <annevk>
smaug____: since that means it might be created with the wrong prototype chain and such

[09:51:16.0000] <annevk>
smaug____: which doesn't seem like something we'd want

[09:51:43.0000] <smaug____>
yeah, I was wondering that too, but then wasn't sure whether the spec actually defines which prototype should be used

[09:56:18.0000] <annevk>
I don't think we really do at the moment, but we should down the line

[09:56:25.0000] <annevk>
It might fall out of IDL

[09:56:52.0000] <annevk>
But we should at least be creating objects in the correct place, not in something that could be a different thread

[09:58:13.0000] <annevk>
I love how DreamHost is now contacting me again about TLS issues since it appears my blogpost has been doing the rounds

[10:06:18.0000] <annevk>
smaug____: ah, thanks for filing an issue

[11:42:45.0000] <wanderview>
JakeA: is there any reason there is no .registration on the window-side ServiceWorker object?

[11:44:17.0000] <zcorpan>
sigh i broke the quoting anyway

[11:48:36.0000] <zcorpan>
fixed

[11:49:06.0000] <wanderview>
JakeA: so window could do navigator.serviceWorker.controller.registration.update()

[12:34:46.0000] <wanderview>
maybe because it would cause a cycle through the registration.installing attribute and friends?

[13:12:55.0000] <wanderview>
fg

[13:12:58.0000] <wanderview>
oops


2015-11-13
[18:06:58.0000] <jacobolus>
does anyone know if there's an IRC channel for web assembly?

[18:23:58.0000] <MikeSmith>
jacobolus: yeah, on irc.w3.org, #webassembly

[18:24:09.0000] <jacobolus>
just found that :)

[18:24:11.0000] <jacobolus>
thanks

[18:24:14.0000] <MikeSmith>
k

[18:24:50.0000] <MikeSmith>
it's fairly activeーcore committers hang out there

[18:24:51.0000] <jacobolus>
MikeSmith: know if it has a bot saving history somewhere?

[18:25:00.0000] <MikeSmith>
dunno

[18:25:18.0000] <MikeSmith>
sunfish there might know

[22:44:54.0000] <annevk>
http://www.sadtrombone.com/ excellent

[22:45:53.0000] <annevk>
jgraham: not sure if you saw my ping, but could you take a look at https://github.com/whatwg/html/pull/323 please?

[22:53:17.0000] <annevk>
The GitHub x/y links only work within the same organization? That is kind of lame

[23:18:41.0000] <annevk>
https://docs.google.com/presentation/d/1pOZ8ppcxEsJ6N8KfnfrI0EXwPEvHwg3BHyxzXXw8lRE/edit is really quite great

[23:19:23.0000] <annevk>
Waiting for foolip to tweet it

[23:19:31.0000] <annevk>
Or rbyers

[23:26:45.0000] <annevk>
Seems rbyers did

[00:34:57.0000] <zcorpan_>
i don't like that webvtt has the id above the timings. would be much nicer to have the id as a setting

[00:35:17.0000] <zcorpan_>
wonder if that can still be changed

[00:43:43.0000] <jgraham>
annevk: Oh sorry. I seem to be subscribed to that repo so I can't tell when someone specifically pings me

[00:45:01.0000] <zcorpan_>
annevk: i think foolip tweeted it also

[00:51:09.0000] <annevk>
zcorpan_: hmm, Twitter search sucks or does Docs URLs are not stable

[00:51:26.0000] <annevk>
or are stable but duplicates exist

[00:52:06.0000] <zcorpan_>
https://twitter.com/foolip/status/664548364978008064

[00:52:55.0000] <zcorpan_>
seems his url ends with ?usp=sharing

[01:31:24.0000] <JakeA>
wanderview: it yeah seen as a performance issue due to updating .installing etc, and updating the registration value itself. But if you don't think it is… it'd be convenient

[01:47:20.0000] <annevk>
yoav: are you planning btw on updating <link rel>, <iframe sandbox>, etc. in HTML to make use of the supported tokens construct?

[01:47:53.0000] <yoav>
annevk: I plan to update <link rel>

[01:49:03.0000] <annevk>
ok

[01:49:14.0000] <annevk>
mkwst: you might want to update <iframe sandbox> I suppose

[01:49:34.0000] <annevk>
bz seems pretty keen on implementing in Gecko once the standard is in place

[01:49:50.0000] <yoav>
if it's a simple change I might update both, haven't looked at <iframe> just yet

[01:55:23.0000] <annevk>
Those seem like the only two for which this is applicable

[01:55:56.0000] <annevk>
Perhaps <a rel>/<area rel>, but user agents don't really do anything with those

[01:58:49.0000] <annevk>
jgraham: so the problem is mostly that opening new browsing contexts requires user interaction

[01:59:03.0000] <annevk>
jgraham: so any test would be a terrible manual test

[02:00:15.0000] <Ms2ger>
window.open()?

[02:00:32.0000] <annevk>
Ms2ger: yes

[02:00:34.0000] <Ms2ger>
Alternatively, webdriver in the future

[02:00:40.0000] <annevk>
sure

[02:01:04.0000] <Ms2ger>
But wpt tests can assume that window.open() works without user interaction

[02:01:44.0000] <annevk>
Ms2ger: oh they can, how?

[02:01:45.0000] <mkwst>
annevk: What is this?

[02:02:20.0000] <annevk>
mkwst: yoav landed a thing in DOM that allows DOMTokenList/DOMSettableTokenList to be used for feature testing, but it requires HTML to hook into the thing

[02:02:50.0000] <mkwst>
annevk: Oh.Ok, this is for feature detecting sandbox flag support?

[02:03:06.0000] <yoav>
mkwst: yeah. I plan to look into adding the corresponding parts into <link rel>

[02:03:07.0000] <annevk>
mkwst: yeah, and <link rel> values

[02:03:09.0000] <mkwst>
yoav: If you point me to whatever you added, I'm happy to add it to HTML. Or you can do it. Whatever. :)

[02:03:33.0000] <Ms2ger>
annevk, I think wptrunner should set a pref in Firefox, not sure how it's handled for other browsers

[02:04:43.0000] <yoav>
mkwst: I'll add it to <link rel> and see if it's not too much hassle to add to iframe as well. I'll ping you if I give up :)

[02:06:24.0000] <mkwst>
yoav: Excellent! /me delegates

[02:09:34.0000] <JakeA>
annevk: wikileaks.org and search.wikileaks.org are the same IP, would a MITM be able to tell the difference?

[02:10:34.0000] <jgraham>
annevk: window.open?

[02:10:49.0000] <jgraham>
Oh Ms2ger said all this

[02:11:06.0000] <jgraham>
wpt requires that you disable the popup blocker for the domain

[02:11:15.0000] <jgraham>
Otherwise you will get spurious results

[02:16:21.0000] <mkwst>
jgraham: Just wait until we specify the popup blocker's behavior.

[02:16:28.0000] <mkwst>
Test _that_. Muwahaha.

[02:22:35.0000] <jgraham>
Pretty sure after hearing what the web bluetooth people want you can't scare me anymore

[03:16:38.0000] <annevk>
JakeA: DNS lookups?

[03:16:38.0000] <botie>
I can't find that machine name

[03:16:57.0000] <annevk>
JakeA: but yeah, the hostname is transmitted in clear text

[03:17:50.0000] <annevk>
JakeA: that might go away at some point, maybe, but that would still leave DNS lookups I think

[03:24:14.0000] <JakeA>
annevk: ohh, I didn't realise that dns was clear text hmm.

[03:25:46.0000] <annevk>
JakeA: in TLS the host is also transmitted as clear text afaik

[03:26:55.0000] <annevk>
JakeA: the idea here is that the server can dispatch the request to the right process more easily that way, e.g., you don't need to have all the certificates available at the root or some such

[03:27:11.0000] <annevk>
JakeA: but still, I think that was poor judgment and it may or may not get fixed in TLSv13

[03:27:50.0000] <JakeA>
yeah, seems pretty leaky

[03:38:16.0000] <annevk>
JakeA: DNS is the worst, but fortunately there's HTTPS to save the day

[03:38:57.0000] <annevk>
And sometimes someone might utter DNSSEC, but they haven't read http://sockpuppet.org/blog/2015/01/15/against-dnssec/

[03:39:18.0000] <annevk>
Also, I don't think DNSSEC gives confidentiality

[03:58:51.0000] <gsnedders>
annevk: it doesn't. it merely gives a basis to trust the response.

[04:40:05.0000] <mkwst>
annevk: Very important question: what should `URLSearchParams('=').toString()` produce? What about `URLSearchParams('%e2').toString()`?

[04:43:44.0000] <mkwst>
Mozilla has an answer, but it seems strange.

[04:44:17.0000] <Ms2ger>
I think URLSearchParams('=').toString() === '=' per spec and Gecko

[04:45:23.0000] <mkwst>
Basically, I don't follow the logic of https://bugzilla.mozilla.org/show_bug.cgi?id=1032511 for '%e2', 'a%e2', 'a%e2b'.

[04:48:03.0000] <Ms2ger>
I think `URLSearchParams('%e2')` would give an internal list of [('%e2', '')]

[04:48:20.0000] <Ms2ger>
Oh wait

[04:49:05.0000] <Ms2ger>
[('=', '')]

[04:49:45.0000] <Ms2ger>
So I think it should serialize to '=='

[04:49:52.0000] <Ms2ger>
Which is not what Gecko does

[04:54:16.0000] <mkwst>
Chrome doesn't like `decodeURIComponent('%e2')`. Neither does Gecko, for that matter.

[05:13:49.0000] <annevk>
Parsing = leads to an empty pair, which when serialized becomes = afaik

[05:16:24.0000] <annevk>
%2e becomes "." afaict since the parser percent decodes

[05:16:35.0000] <annevk>
mkwst: Ms2ger: ^

[05:17:03.0000] <Ms2ger>
2e is =, no?

[05:17:17.0000] <Ms2ger>
The parser percent decodes after splitting on =

[05:17:19.0000] <mkwst>
e2. Not 2e.

[05:18:19.0000] <annevk>
Oh

[05:18:40.0000] <annevk>
Yeah, for that case == sounds reasonable

[05:20:02.0000] <annevk>
Sorry, %e2 is non-ASCII of course, not =

[05:20:32.0000] <annevk>
So the reason that fails is that E2 by itself is not valid UTF-8, so trying to decode it will get you a replacement code point

[05:20:58.0000] <annevk>
Which is why you get the '\ufffd=' serialization

[05:21:09.0000] <annevk>
mkwst: Ms2ger: ^

[05:22:23.0000] <mkwst>
Ok. It looks like Chrome is decoding it as ASCII, which seems potentially incorrect. :)

[05:38:48.0000] <zcorpan>
anyone know if http://stackoverflow.com/questions/30548399/filter-issues-on-github-that-will-be-closed-by-a-pull-request is possible?

[05:41:50.0000] <zcorpan>
maybe i can use assignee as workaround

[05:42:23.0000] <zcorpan>
though that means more spam plus a manual step

[06:00:10.0000] <mkwst>
annevk: I guess `URLUtils` is obsolete?

[06:00:20.0000] <annevk>
mkwst: yes

[06:00:41.0000] <mkwst>
Wunderbar. Do you intend to add `searchParams` to `HTTPAnchorElement`?

[06:01:01.0000] <mkwst>
Or, HTMLHyperlinkElementUtils rather.

[06:10:26.0000] <annevk>
mkwst: Firefox implements that at the moment, but I think it's cleaner if we keep it to URL

[06:10:35.0000] <annevk>
mkwst: because we cannot offer it for Location

[06:11:02.0000] <annevk>
mkwst: so instead of Location/WorkerLocation being the weird ones, seemed saner to make URL special

[06:12:06.0000] <mkwst>
I'm fine either way, I just need to know what I actually need to implement. :)

[06:14:35.0000] <annevk>
mkwst: just on URL

[06:15:06.0000] <mkwst>
ok. beautiful.

[06:19:27.0000] <Ms2ger>
annevk, do you know if anyone has written tests for https://github.com/whatwg/dom/commit/2920fc15b9e894c45ff84c5d3bb77f7513ff50e5 ?

[06:20:14.0000] <annevk>
Ms2ger: I suspect there are tests already given that bz found it, but haven't checked

[06:20:48.0000] <Ms2ger>
Ok

[06:40:49.0000] <smaug____>
annevk: CanvasRenderingContext2D.canvas is HTMLCanvasElement even in workers

[06:40:56.0000] <smaug____>
in the spec

[06:41:13.0000] <smaug____>
CanvasRenderingContext2D is exposed in workers, but HTMLCanvasElement isn't

[06:41:54.0000] <annevk>
smaug____: yeah so is any of that implemented and specified as folks want?

[06:42:06.0000] <annevk>
smaug____: I had the impression that we're still changing how to do canvas in workers

[06:42:21.0000] <smaug____>
I'm just reviewing a patch which implements this stuff

[06:42:42.0000] <smaug____>
in the patch it is readonly attribute CanvasObj? canvas;

[06:42:50.0000] <smaug____>
typedef (HTMLCanvasElement or OffscreenCanvas) CanvasObj;

[06:43:04.0000] <annevk>
smaug____: https://wiki.whatwg.org/wiki/OffscreenCanvas

[06:43:19.0000] <annevk>
smaug____: oh great

[06:43:29.0000] <annevk>
smaug____: I didn't realize folks were implementing that wiki page already

[06:43:37.0000] <annevk>
smaug____: or that it was done somehow

[06:43:50.0000] <annevk>
smaug____: none of this is integrated into HTML proper

[06:44:01.0000] <smaug____>
taiwan folks do all this great canvas and video worker stuff atm :)

[06:44:50.0000] <smaug____>
this will be behind a pref initial ofc

[06:45:03.0000] <annevk>
smaug____: that is pretty cool, but do we know whether this draft is stable? It's certainly not been hold to any kind of spec-writing scrutiny

[06:45:16.0000] <annevk>
"This proposal has been vetted by developers of Apple's Safari, Google's Chrome, Microsoft's Internet Explorer, and Mozilla's Firefox browsers. All vendors agreed upon the basic form of the API, so it is likely it will be implemented widely and compatibly."

[06:45:24.0000] <annevk>
I guess the wiki page is pretty confident it's all good

[06:45:47.0000] <smaug____>
roc has been involved with this stuff

[06:45:56.0000] <smaug____>
I'm just reviewing the .webidl bits

[06:46:21.0000] <smaug____>
looks like also  Justin Novosad commented in the bug recently

[06:50:10.0000] <annevk>
Yeah, certainly seems like it's much further along than I thought

[06:50:19.0000] <annevk>
I figured they'd turn it into some PR at some point

[06:50:25.0000] <annevk>
Perhaps I should start asking about that now

[08:24:39.0000] <yoav>
zcorpan: around?

[08:30:12.0000] <zcorpan>
yoav: for a bit'

[08:30:39.0000] <yoav>
zcorpan: looks at adding the html bits for <link> relList

[08:31:01.0000] <zcorpan>
yoav: ok cool

[08:31:32.0000] <yoav>
I got:

[08:31:36.0000] <yoav>
<p>The IDL attribute <dfn><code data-x="dom-link-rellist">relList</code></dfn> <span

[08:31:36.0000] <yoav>
  w-nodev>must</span> <span data-x="reflect">reflect</span> the <code

[08:31:36.0000] <yoav>
  data-x="attr-link-rel">rel</code> content attribute. The <code data-x="supported tokens">supported tokens</code> for <code

[08:31:38.0000] <yoav>
  data-x="dom-link-rellist">relList</code> include the rel values defined in <a>linkTypes</a>. Other specifications may add other supported

[08:31:40.0000] <yoav>
  tokens</p>

[08:32:01.0000] <yoav>
which is total pseudo-code in many places where I don't know how to link :)

[08:32:47.0000] <yoav>
Could you take a look and tell me how to do what I'm trying to do?

[08:33:05.0000] <yoav>
e.g. how to link to things in the DOM spec?

[08:33:20.0000] <yoav>
how to link to linkTypes

[08:33:45.0000] <yoav>
and to dom-link-rellist

[08:36:12.0000] <zcorpan>
yoav: html has a Dependencies section where cross-spec terms are <dfn>ed

[08:36:39.0000] <Ms2ger>
And that's a crappy approach

[08:36:49.0000] <Ms2ger>
Doesn't html have real cross-spec links yet?

[08:36:58.0000] <yoav>
zcorpan: OK, thanks, I'll look into that

[08:37:01.0000] <zcorpan>
Ms2ger: nope

[08:39:11.0000] <zcorpan>
yoav: <span> for non-code xrefs

[08:40:27.0000] <yoav>
so, "<span>linkTypes</span>" ?

[08:43:24.0000] <zcorpan>
yes, or <span data-x="the-actual-xref-term-w00t">linkTypes</span>

[08:44:08.0000] <yoav>
ok, cool

[09:34:01.0000] <annevk>
I think link types is the only which requires <a>

[09:34:08.0000] <annevk>
We should probably clean that up at some point

[10:57:17.0000] <yoav>
annevk: https://github.com/whatwg/html/pull/340 is a first stab at adding the feature detection parts to html


2015-11-14
[20:58:03.0000] <JonathanNeal>
Was there ever a shorthand data attribute proposal?


2015-11-15
[06:42:42.0000] <frewsxcv>
which part of https://html.spec.whatwg.org/multipage/rendering.html mentions that <h1 align=right> should add a presentational hint for text-align: right?

[06:43:29.0000] <frewsxcv>
nevermind. i see it's part of the css


2015-11-16
[00:58:38.0000] <annevk>
jgraham_: why does the port for web-platform.test keep changing?

[01:04:07.0000] <jgraham>
annevk: By default it should start one server on port 8000 and one on a random free port

[01:04:49.0000] <jgraham>
In general you aren't supposed to rely on the specific port in tests (but obviously for actually running them having a known port helps, hence 8000)

[01:05:32.0000] <annevk>
jgraham: the random port makes it hard with popup preferences

[01:05:44.0000] <annevk>
jgraham: but 8000 helps

[01:06:38.0000] <jgraham>
Do popup preferences also consider port?

[01:06:50.0000] <annevk>
jgraham: they do in Gecko these days

[01:06:54.0000] <jgraham>
Oh

[01:07:06.0000] <annevk>
jgraham: we changed from hostname to origin checks for everything a while back

[01:07:33.0000] <annevk>
jgraham: and * does not work

[01:07:45.0000] <annevk>
jgraham: web-platform.test:* that is

[01:07:55.0000] <jgraham>
For something like popup blocking that seems unfortunate from a UI point of view

[01:11:57.0000] <annevk>
jgraham: I also keep having this change to tools "Subproject commit d93ad88336e5933b158129596c196d568ae15f82-dirty"

[01:12:04.0000] <annevk>
jgraham: even when I do git reset --hard

[01:12:14.0000] <jgraham>
Yeah, submodules :(

[01:12:25.0000] <jgraham>
I think something in the .gitignore needs to be updated

[01:12:38.0000] <jgraham>
I'll have a look in a moment

[01:14:00.0000] <annevk>
I wonder if I should file a bug on the popup preferences thing... It seems kind of lame to file this bug for a test framework

[01:19:15.0000] <jgraham>
Well I can't imagine anyone is going to think it's a P1

[01:19:50.0000] <jgraham>
FWIW I think I might have the popup blocker disabled. Herd immunity and all that

[01:36:58.0000] <jgraham>
annevk: What does git status show if you run it from tools/

[01:39:41.0000] <annevk>
HEAD detached at d93ad88

[01:39:41.0000] <annevk>
nothing to commit, working directory clean

[01:39:44.0000] <annevk>
jgraham: ^

[01:42:58.0000] <Ms2ger>
Where's the chromium dashboard for features they measure?

[01:44:33.0000] <jgraham>
annevk: Hmm. To be clear, what happens if you run git submodule update --recursive in the main wpt checkout?

[01:44:36.0000] <annevk>
Ms2ger: https://www.chromestatus.com/metrics/feature/timeline/popularity

[01:45:07.0000] <annevk>
jgraham: that seems to return pretty quickly

[01:45:17.0000] <Ms2ger>
Thanks

[01:46:43.0000] <Ms2ger>
Doesn't look like MouseEvent#toElement is going anywhere: https://www.chromestatus.com/metrics/feature/timeline/popularity/507

[01:48:20.0000] <jgraham>
annevk: And git status doesn't change?

[01:48:40.0000] <annevk>
jgraham: correct

[02:02:19.0000] <jgraham>
r? https://github.com/w3c/wpt-tools/pull/38 https://github.com/w3c/web-platform-tests/pull/2328

[02:03:47.0000] <Ms2ger>
Looking

[02:04:12.0000] <Ms2ger>
jgraham, conflicts on wpt

[02:05:56.0000] <jgraham>
Oh, dammit

[02:06:08.0000] <jgraham>
I didn't notice I was on a strange branch

[02:09:18.0000] <jgraham>
Ms2ger: Try again

[02:39:50.0000] <annevk>
Why does html/ have all these empty directories with .gitkeep files in them?

[02:40:16.0000] <jochen__>
annevk: do you know what's up with referrerPolicy attribute over at mozilla?

[02:40:28.0000] <annevk>
Is there an easy way to find out if there are any noreferrer tests?

[02:41:13.0000] <annevk>
jochen__: I think hsivonen was looking for confirmation from you that the name is set and agreed upon?

[02:41:36.0000] <annevk>
jochen__: see https://github.com/w3c/webappsec-referrer-policy/issues/3#issuecomment-156685673

[02:42:18.0000] <annevk>
jochen__: I haven't really followed any corresponding issues in Mozilla's Bugzilla though

[02:42:23.0000] <annevk>
/me looks

[02:42:57.0000] <Ms2ger>
html/browsers/windows/browsing-context-names/001.html:<title>Link with target=_blank, rel=noreferrer</title>

[02:43:05.0000] <jochen__>
I don't understand why he even asks

[02:43:16.0000] <Ms2ger>
html/semantics/links/linktypes/contains.json:        "original_id": "link-type-noreferrer"

[02:43:34.0000] <jochen__>
the only reason this doesn't make much progress is because somebody else from mozilla wants to spec it, but only sends a pull request every few weeks :-/

[02:44:57.0000] <annevk>
jochen__: that person is not from Mozilla

[02:45:11.0000] <annevk>
jochen__: pretty sure that person is employed by Yahoo!

[02:45:37.0000] <annevk>
jochen__: why is it an unreasonable question?

[02:46:14.0000] <annevk>
jochen__: I think hsivonen just wants to be certain about the name change, since he was asked to review https://bugzilla.mozilla.org/show_bug.cgi?id=1187357 (which appears to be the corresponding bug)

[02:47:02.0000] <jochen__>
annevk: no, the question is not unreasonable

[02:47:59.0000] <jochen__>
guess I should just update the spec myself

[02:48:52.0000] <annevk>
jochen__: seems reasonable if Scott is not active/away

[02:48:54.0000] <philipj>
annevk, mkwst, where is https://url.spec.whatwg.org/#concept-urlencoded-string-parser actually defined?

[02:49:24.0000] <annevk>
philipj: that is a definition?

[02:49:54.0000] <annevk>
philipj: it's a tad confusing that "parsing" is not part of the link though

[02:50:09.0000] <philipj>
the URLSearchParams constructor refers to it, so I'm looking for something that actually splits of '&' and so on

[02:50:30.0000] <annevk>
philipj: right, click on "application/x-www-form-urlencoded"

[02:51:04.0000] <philipj>
oh, well that wasn't obvious :)

[02:51:25.0000] <philipj>
since it was under "Hooks" I assumed I should be looking for it in some other spec

[02:51:30.0000] <Ms2ger>
That link should probably include "parsing" too

[02:51:56.0000] <annevk>
Ms2ger: yeah, just said that

[02:52:00.0000] <annevk>
Ms2ger: PRs welcome

[02:52:32.0000] <Ms2ger>
Do

[02:52:33.0000] <Ms2ger>
h

[02:54:24.0000] <philipj>
/me does it

[02:55:35.0000] <annevk>
jgraham: so apart from finding it hard to find tests, I'm also having a hard time to figure out where to put tests

[02:56:13.0000] <Ms2ger>
I guess your test spans a number of spec sections

[03:02:48.0000] <philipj>
annevk: https://github.com/whatwg/url/pull/73

[03:05:02.0000] <annevk>
Ms2ger: yeah, also, I've no idea how to do this properly

[03:05:35.0000] <annevk>
So I spawn a new window; I need to test something in that window, then the only way I can communicate back is through document.cookie or localStorage

[03:05:48.0000] <annevk>
Can I use document.cookie and localStorage without fear of breaking stuff?

[03:06:14.0000] <annevk>
Or do I need to use some kind of framework that prevents misuse?

[03:08:10.0000] <philipj>
annevk: if you have arranged things so that there is only ever one things that writes to a specific localStorage key, and the others just read, then I can't see what implementation strategy would break that

[03:08:18.0000] <philipj>
but perhaps I need more imagination :)

[03:08:51.0000] <annevk>
philipj: my problem is mostly other tests

[03:09:13.0000] <annevk>
philipj: but I guess if I make the name unique enough and remove it afterwards there's not much that can go wrong

[03:09:25.0000] <annevk>
philipj: of course, testing anything cross-origin still seems hard

[03:09:46.0000] <philipj>
well then localStorage isn't part of the equation anyway :)

[03:14:00.0000] <jgraham>
annevk: There's no generic way of cleaning up all possible state that a test could leave, although there are affordances in testharness.js for writing custom cleanup

[03:14:18.0000] <jgraham>
test.add_cleanup(callback)

[03:15:09.0000] <jgraham>
annevk: It being hard to find tests and hard to know where to put tests are two sides of the same coin, really. I'm not sure what the solution is, especially for cross-cutting tests

[03:18:31.0000] <annevk>
philipj: yeah, I basically don't see how that could be tested

[03:18:36.0000] <annevk>
philipj: manually I suppose

[03:50:51.0000] <annevk>
jgraham: so web-platform-tests now has three review systems?

[03:52:23.0000] <jgraham>
annevk: I have no idea why reviewable is on

[03:52:26.0000] <jgraham>
Ms2ger: ^?

[03:53:15.0000] <jgraham>
I mean if people prefer that to critic we can use it instead when I have my bot for automatically cc-ing potential reviewers done

[03:53:39.0000] <Ms2ger>
I wanted to use it somewhere, but I don't remember why, feel free to turn it off again for now

[03:55:00.0000] <jgraham>
OK

[05:36:33.0000] <JonathanNeal>
Has there been a proposal to shorthand data attribute selectors? something like http://jonathantneal.github.io/postcss-short-data/ ?

[06:25:07.0000] <annevk>
JonathanNeal: seems like something for #css on W3C IRC?

[06:27:19.0000] <annevk>
JakeA: if for some reason a document terminates a fetch, should the service worker one keep trucking? Should there be some way to forward the signal?

[06:28:39.0000] <JonathanNeal>
annevk: thanks, i wasn’t sure where the discussion belonged

[06:44:04.0000] <JakeA>
annevk: I'm hoping it could cancel the promise passed to respondWith

[06:45:10.0000] <JakeA>
But the fetch event's respondWith and waitUntil are no longer valid for keeping the SW open if the fetch is aborted

[06:47:10.0000] <annevk>
Hmm

[06:47:30.0000] <annevk>
I don't think any of that is specified

[06:57:36.0000] <wanderview>
annevk: JakeA: we're only talking if the service worker does fetch(evt.request), right?

[06:58:40.0000] <wanderview>
oh, I see... cancelling the promise to respondWith() would work for any fetch()

[06:59:09.0000] <wanderview>
although I wonder if it would play havoc with people trying to do read-through-caching strategies... they may still want to update cache in those cacses

[06:59:11.0000] <wanderview>
cases

[06:59:31.0000] <wanderview>
/me should not be typing here without at least one cup of coffee.

[07:08:11.0000] <Ms2ger>
> By all means, I'm no expert on collapsing margins since I just learned about them today, but does the spec really make sense...

[07:08:12.0000] <Ms2ger>
Oh poor soul

[07:30:33.0000] <annevk>
wanderview: how does cancelling respondWith() affect an ongoing fetch() from the service worker?

[07:31:16.0000] <wanderview>
annevk: I was assuming the cancellable promises and aborting fetch would be spec'd at this point

[07:32:00.0000] <annevk>
wanderview: hmm, I guess we can wait for that until we clarify this further

[07:32:29.0000] <annevk>
wanderview: it does kind of make sense that if you do a passthrough the cancellation affects both

[07:36:10.0000] <wanderview>
annevk: its unclear to me if all things the SW might do will be cancellable, though... like I haven't heard anyone suggest cache.put() should cancellable

[07:37:00.0000] <annevk>
wanderview: cancelable by the developer or cancelable by the user?

[07:37:19.0000] <annevk>
wanderview: or cancelable due to some system fault?

[07:44:02.0000] <wanderview>
annevk: I mean something like cache.put(req, resp).cancel();

[07:44:52.0000] <wanderview>
annevk: something like cache.add(req) might need to be cancellable since it does a fetch() internally... but I guess I wonder if we should allow cancelling the disk transaction

[07:45:05.0000] <wanderview>
/me foresees headaches.

[08:04:30.0000] <annevk>
jgraham: Ms2ger: that change you landed to ignore tools doesn't actually ignore it

[08:04:54.0000] <annevk>
jgraham: Ms2ger: my local checkout claims I have changed the commit value to d93ad88336e5933b158129596c196d568ae15f82 (no longer has dirty at the end)

[08:05:18.0000] <annevk>
jgraham: Ms2ger: running "git submodule update --recursive" did not help

[08:05:19.0000] <Ms2ger>
annevk, try git submodule update --recursive

[08:05:22.0000] <Ms2ger>
Bah

[08:15:24.0000] <annevk>
jgraham: apart from that, question, where do manual tests go?

[08:16:53.0000] <Ms2ger>
Same place as automated tests, but called foo-manual.html

[08:17:36.0000] <annevk>
Okay

[08:17:52.0000] <annevk>
ta

[08:19:35.0000] <Ms2ger>
Np

[09:51:45.0000] <annevk>
Ms2ger: jgraham: so I did the "git submodule update --recursive" thing in the wrong branch

[09:51:52.0000] <annevk>
Ms2ger: jgraham: seems all is good now

[09:52:39.0000] <Ms2ger>
\o/

[09:53:46.0000] <annevk>
yeah that is actually pretty much \o/

[09:53:52.0000] <annevk>
this was quite annoying

[09:59:20.0000] <jgraham>
Submodules have rough edges

[09:59:31.0000] <jgraham>
I would happily not use them here, except css

[10:03:02.0000] <annevk>
Oops, I broke Critic

[10:03:07.0000] <annevk>
Did not appreciate force push

[10:03:56.0000] <jgraham>
Which PR?

[10:04:41.0000] <annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2329

[10:12:05.0000] <jgraham>
annevk: Well working again now fwiw

[11:00:16.0000] <smaug____>
is there some way in chrome to make it open about:blank by default

[11:00:18.0000] <smaug____>
in new tabs

[12:13:09.0000] <hsivonen>
annevk: Is our encoding handling for MIME header parsing spec-compliant? See https://mxr.mozilla.org/mozilla-central/ident?i=nsIUTF8ConverterService . That code seems to treat bytes as UTF-8 if they look like UTF-8 and treat them as another encoding otherwise

[15:50:33.0000] <smaug____>
jgraham: I probably asked this before, but we don't have too many tests for MessagePorts, right? Do you happen to know if anyone is writing such?


2015-11-17
[23:34:14.0000] <annevk>
hsivonen: it is not

[00:43:32.0000] <zcorpan>
hmmmm. i just realized that ::cue(c::before) { content: url(image) } is possible...

[01:11:25.0000] <annevk>
jgraham: is the localStorage issue in https://github.com/w3c/web-platform-tests/pull/2329 that mkwst points out really an issue?

[01:12:39.0000] <mkwst>
annevk: It will be if Chrome imports the tests. We run X workers with basically random subsets of our layout tests at the same time on the same machine. I imagine Firefox shards things similarly.

[01:13:08.0000] <jgraham>
We don't shard things like that

[01:13:15.0000] <jgraham>
/me reads the issue

[01:13:19.0000] <annevk>
mkwst: wouldn't that just break http://w3c-test.org/webstorage/?

[01:14:12.0000] <mkwst>
annevk: Probably. Those tests look like they assume they're the only thing running.

[01:14:19.0000] <jgraham>
mkwst: For the record, Gecko typically runs a single test process per machine, but if it didn't it would certainly use a single profile per test instance

[01:14:23.0000] <mkwst>
(based on random spot-checking)

[01:14:26.0000] <annevk>
mkwst: I suspect most tests do

[01:14:55.0000] <jgraham>
Servo runs multiple processes, but doesn't support storage afaik

[01:15:41.0000] <mkwst>
*shrug* One way around it is to use unique names, and check for those when reading storage events.

[01:15:46.0000] <jgraham>
Running multiple tests in parallel accessing the same underlying browser state seems like it's asking for problems

[01:15:59.0000] <mkwst>
jgraham: That basically "the internet", though, isn't it?

[01:16:15.0000] <jgraham>
… not really

[01:16:23.0000] <mkwst>
If you know that's a constraint, you write tests to deal with it.

[01:17:09.0000] <jgraham>
It sounds a bit like "programming in C is easy, just don't access invalid memory" or something :)

[01:17:50.0000] <jgraham>
In any case I would be interested to know what jsbell thinks because he changed the localStorage tests to clear the storage before each test

[01:17:58.0000] <jgraham>
*before and after

[01:17:58.0000] <mkwst>
jgraham: Which is why we have tools like asan. :) Basically, when they started sharding tests, it was a huge pain in the ass to get everything running because tests assumed they owned the world.

[01:18:25.0000] <jgraham>
s/asan/Rust/ :p

[01:18:55.0000] <mkwst>
Now that I'm typing all this, I guess I'm not _sure_ that we're actually sharding layout tests. Maybe we're only sharding unit tests.

[01:19:01.0000] <jgraham>
Anyway, ignoring the analogy, I think that running multiple tests in parallel with shared global state is asking for trouble

[01:19:32.0000] <mkwst>
Well, yes. I'm suggesting that "shared global state" is the problem, not "running multiple tests in parallel"

[01:20:10.0000] <jgraham>
Well the shared global state exists; we can't change the platform. Or make each test run in its own origin.

[01:20:39.0000] <jgraham>
And in some cases it is the shared global state that you are testing

[01:20:45.0000] <jgraham>
So you can't just never use it

[01:20:49.0000] <mkwst>
You can design tests not to rely on it. As I noted above: using a unique name for the storage key would help,

[01:21:20.0000] <jgraham>
Yes, so I agree that this test could be better

[01:22:01.0000] <jgraham>
But I think that running unit tests in parallel and layouttests in serial would fit more of the datapoints I have about your testing. And about what seems plausible to actually work.

[01:25:41.0000] <annevk>
jgraham: none of the webstorage tests appear to use unique names either

[01:25:49.0000] <annevk>
jgraham: e.g., view-source:http://web-platform.test:8000/webstorage/resources/local_set_item_clear_iframe.html

[01:27:41.0000] <mkwst>
*shrug* Ask jsbell. I might very well be wrong.

[01:29:02.0000] <jgraham>
annevk: Well yeah, I didn't say the existing tests were perfect :)

[01:30:21.0000] <mkwst>
unrelatedly: is there a web-facing API that implements https://url.spec.whatwg.org/#urlencoded-serializing?

[01:30:46.0000] <mkwst>
I thought `encodeURIComponent` would get me there, but it doesn't match for 0x27 (`'`).

[01:31:15.0000] <annevk>
mkwst: <form>

[01:31:29.0000] <annevk>
mkwst: ECMAScript has its own algorithms

[01:31:36.0000] <mkwst>
...

[01:31:54.0000] <jgraham>
Welcome to the web!

[01:32:27.0000] <philipj>
mkwst: so it didn't quite match the spec? :)

[01:33:15.0000] <mkwst>
philipj: I think it does match the spec, but I want to write a test that doesn't involve me hard-coding values for 0x00 -> 0xFF.

[01:37:04.0000] <philipj>
mkwst: wouldn't a simply encodeByte() that tests for 0x20 and the pass-through bytes between 0x2A and 0x7A be about 5 lines of code?

[01:37:14.0000] <philipj>
Don't need a big explicit table, I mean

[01:44:08.0000] <mkwst>
philipj: I might just be an idiot. *shrug* :)

[01:44:33.0000] <philipj>
mkwst: I really doubt it :)

[01:44:42.0000] <mkwst>
jgraham: Is there a mechanism to run a full test even if an assertion fails? Like, I want a list of _all_ the assertions in a test that fail, not just the first one. :)

[01:45:01.0000] <mkwst>
like, `expect` vs `assert` in gtest.

[01:45:23.0000] <jgraham>
mkwst: No

[01:45:35.0000] <jgraham>
Although you are not the first to ask for it

[01:45:37.0000] <mkwst>
:(

[01:46:29.0000] <Ms2ger>
/me curses the eventTestHarness.js

[01:50:00.0000] <annevk>
mkwst: just create a bunch of tests?

[01:50:20.0000] <mkwst>
I have a for loop to avoid creating a bunch of tests.

[01:50:21.0000] <annevk>
mkwst: multiple test/async_test in a single file that is

[01:50:44.0000] <zcorpan>
can encodeURIComponent be changed or will that break the web?

[01:51:07.0000] <mkwst>
I want to run 0x00 -> 0xFF through URLSearchParams to see what happens, and where Firefox and Chrome disagree. I don't want 255 tests.

[01:51:56.0000] <jgraham>
Why not?

[01:52:09.0000] <Ms2ger>
I think you do

[01:52:44.0000] <mkwst>
I think I do in testharness.js, because that's the only way to get sane error messages.

[01:53:01.0000] <Ms2ger>
That's what http://w3c-test.org/XMLHttpRequest/send-usp.html does too

[01:53:05.0000] <mkwst>
I think I don't in other testing frameworks I'm familiar with, because they don't die on the first error.

[01:53:22.0000] <Ms2ger>
You want it because they're independent tests

[01:53:36.0000] <mkwst>
Oh, ha. I hadn't thought about putting the for loop outside the `test()`. Clever!

[01:53:53.0000] <mkwst>
(See, philipj? Idiot. :) )

[01:55:54.0000] <philipj>
mkwst: Hah, still not convinced. Generating a bunch of tests is really quite nice with testharness.js, though, I like that.

[01:56:17.0000] <annevk>
zcorpan: battle with es-discuss?

[01:56:31.0000] <Ms2ger>
jgraham, oh, btw

[01:56:39.0000] <Ms2ger>
What's the story of content-security-policy/blink-contrib/?

[01:56:48.0000] <annevk>
jgraham: so do I need to change the test?

[01:57:06.0000] <annevk>
whoa whoa

[01:57:13.0000] <annevk>
web-platform-tests has 112 open PRs?

[01:58:25.0000] <Ms2ger>
That's all?

[01:58:50.0000] <Ms2ger>
I think I briefly managed to push it under a hundred early this year

[02:00:09.0000] <annevk>
Okay, I guess I'll just keep submitting PRs

[02:01:07.0000] <zcorpan>
while (zcorpan.hasChocolate() && PRs.length >= 100) { review(PRs.pop()) }

[02:01:17.0000] <Ms2ger>
If you can convince jst_ to hire someone to do DOM QA, we could maybe improve the situation

[02:02:40.0000] <jgraham>
Wait, what? If we get the queue under 100, you will stop working?

[02:02:48.0000] <jgraham>
That doesn't sound like an ideal incentive

[02:03:03.0000] <mkwst>
Ms2ger: Brad asked me to contribute all the blink CSP tests to WPT so that he'd be licensed to work on them under whatever license WPT has.

[02:03:05.0000] <mkwst>
So I did.

[02:03:18.0000] <mkwst>
And we've been converting them to testharness and WPT over time.

[02:04:03.0000] <annevk>
Ms2ger: that doesn't sound impossible, do you have anyone in mind?

[02:04:35.0000] <Ms2ger>
mkwst, so if I wanted to rewrite some of those tests to look more like native th.js tests, that wouldn't step on anyone's toes?

[02:04:44.0000] <Ms2ger>
annevk, not really

[02:04:48.0000] <mkwst>
Ok, philipj. Since you apparently know things about encodings, what is URLSearchParams supposed to produce for `0x80`? Both Firefox and Chrome produce `%C2%80`, which I guess means it's correct, but I have no idea why.

[02:05:26.0000] <gsnedders>
annevk: a lot of the open PRs are pretty old

[02:05:45.0000] <annevk>
gsnedders: yeah I noticed

[02:06:01.0000] <philipj>
mkwst: if you do u'\u0080'.encode('utf8') in Python it will make sense :)

[02:06:02.0000] <annevk>
gsnedders: I might keep noticing this every six months or so when I look into adding some tests

[02:06:03.0000] <gsnedders>
annevk: stuff either gets merged quickly or lasts forever, more or less :P

[02:06:05.0000] <mkwst>
Ms2ger: please do! If you want to be super-safe, you could ping @hillbrad to make sure he's not working on something in parallel, but I think you'll be safe.

[02:06:07.0000] <zcorpan>
jgraham: i know, but historically it seems we haven't managed to get the number much lower than 100. i don't know if that's because there are lots of old PRs that are really annoying to review for some reason, or we feel good about getting below 100, or both

[02:06:12.0000] <philipj>
U+0080 is simply those two bytes in UTF-8

[02:06:43.0000] <mkwst>
philipj: So, how do I write a test that produces that output? In JavaScript and not Python. :)P

[02:06:54.0000] <philipj>
Oh, wait, that's a very good question!

[02:06:54.0000] <Ms2ger>
mkwst, I'll file an issue

[02:06:56.0000] <jgraham>
zcorpan: I agree with gsnedders' 2-population theory. I think we probaly have a significant fraction of 100 PRs stuck for some reason

[02:07:17.0000] <jgraham>
e.g. too hard to review, reviewed with comments and noone addressing them, etc.

[02:07:37.0000] <gsnedders>
the former is something we should try and work harder on, the latter someone should pick them up

[02:07:44.0000] <annevk>
mkwst: (new TextEncoder()).encode("\u80") though then you still have to go from bytes to %{byte} etc.

[02:07:53.0000] <annevk>
philipj: ^

[02:08:22.0000] <mkwst>
philipj: So, it looks like Firefox and JavaScript agree on everything except "!", "(", ")", "/", and "~". I assume Firefox is correct to encode these, and Chrome is incorrect not to.

[02:08:29.0000] <annevk>
mkwst: you can also do it through URL parsing

[02:08:52.0000] <annevk>
mkwst: which uses a utf-8 encoder under the hood

[02:09:09.0000] <mkwst>
annevk: Well, not when URL parsing is what I'm trying to test. :)

[02:10:03.0000] <annevk>
mkwst: fair

[02:10:06.0000] <annevk>
mkwst: note https://github.com/whatwg/url/issues/18 btw

[02:10:11.0000] <mkwst>
TextEncoder seems to work, thanks.

[02:10:13.0000] <philipj>
mkwst: I actually "forgot" that there are bytes >0x7F, if you want to test all bytes you'll have to find a set of code points that contain all bytes when represented as UTF-8, but I wouldn't assume without testing that that's possible, maybe some bytes are unused in UTF-8?

[02:10:17.0000] <philipj>
annevk must know

[02:10:29.0000] <gsnedders>
philipj: FE and FF

[02:10:52.0000] <Ms2ger>
I don't guess anyone here has strong views on blink's webstorage layout tests that ended up in wpt?

[02:11:10.0000] <philipj>
gsnedders: I suspected as much

[02:11:56.0000] <philipj>
mkwst: but it looks like there's plenty of disagreement in the range 0x00-0x7F too :)

[02:12:11.0000] <mkwst>
Well, 5 characters.

[02:12:36.0000] <mkwst>
6 characters, sorry. Firefox gets 0x00 wrong.

[02:12:54.0000] <annevk>
I think bz has a patch for 0x00

[02:13:08.0000] <Ms2ger>
Yeah, that landed

[02:13:18.0000] <philipj>
I love null in strings, it's the best

[02:13:44.0000] <Ms2ger>
I'm glad Servo doesn't have to worry about that

[02:16:08.0000] <philipj>
Ms2ger: It's actually mostly a non-issue in WebKit/Blink as well, but it was a nuisance in Presto

[02:16:40.0000] <Ms2ger>
It's mostly a non-issue in Gecko too, but we still end up with bugs like this

[02:17:36.0000] <mkwst>
Ok, great. In that case, Gecko is 100% awesome, and Chrome (will be) ~98.04% awesome for the range 0x00-0xFF.

[02:17:45.0000] <annevk>
Ms2ger: jgraham: I think https://github.com/w3c/web-platform-tests/pull/1278 should land given that we are landing tests that check URLSearchParams() without new throws

[02:18:20.0000] <Ms2ger>
Ugh, I thought the spec was fixed already

[02:18:23.0000] <annevk>
philipj: do you remember the big Presto rewrite?

[02:18:38.0000] <annevk>
Ms2ger: IDL doesn't have an active editor

[02:18:40.0000] <philipj>
annevk: related to strings?

[02:18:52.0000] <Ms2ger>
> I might consider doing that if I wasn't within about a week of having to freeze the final ES6 draft.

[02:18:54.0000] <Ms2ger>
Yay versioning

[02:19:12.0000] <Ms2ger>
annevk, yeah, whatever, rebase and land it

[02:19:28.0000] <Ms2ger>
That ship has sailed, unfortunately

[02:20:11.0000] <annevk>
Ms2ger: then I get "error: The following untracked working tree files would be overwritten by checkout:"

[02:20:20.0000] <Ms2ger>
tools/?

[02:20:25.0000] <annevk>
Ms2ger: yes

[02:21:31.0000] <Ms2ger>
I think the easiest solution is `git checkout non-new-Blob; git branch -m non-new-Blob-old; git checkout master; git checkout -b non-new-Blob; git cherry-pick d8d1e56; git push -f origin non-new-Blob`

[02:22:15.0000] <annevk>
git checkout fails though

[02:23:02.0000] <annevk>
I hate this repo

[02:23:29.0000] <Ms2ger>
I'll do it

[02:23:51.0000] <mkwst>
philipj: Would you mind taking a look at https://codereview.chromium.org/1442643008 (the serialization in particular)?

[02:24:01.0000] <mkwst>
I think I've addressed all your comments.

[02:24:13.0000] <philipj>
gsnedders, mkwst: in some ad-hoc testing with Python it looks like only 238 unique bytes show up in UTF-8

[02:24:18.0000] <philipj>
mkwst: will take a look

[02:26:31.0000] <gsnedders>
philipj: there should be all but those two

[02:26:43.0000] <annevk>
gsnedders: per https://en.wikipedia.org/wiki/UTF-8#Codepage_layout there's 13

[02:27:11.0000] <gsnedders>
oh, right, the old four-seven byte length sequences

[02:27:20.0000] <gsnedders>
plus the overlong 2-byte reprs

[02:27:29.0000] <philipj>
I didn't go all the way up to astral, so I may have missed some

[02:27:34.0000] <philipj>
anyway...

[02:27:49.0000] <annevk>
gsnedders: four-infinite, even

[02:28:00.0000] <annevk>
gsnedders: I only knew about five and six

[02:28:18.0000] <zcorpan>
Ms2ger: can you merge  https://github.com/w3c/web-platform-tests/pull/2334 ? it appeared i had too little space left to clone the repo :-(

[02:28:29.0000] <gsnedders>
annevk: seven/infinity were never part of UTF-8

[02:28:37.0000] <philipj>
I thought at some point they decided that unicode was going to be at most 24-bit to avoid the infinity problem?

[02:29:13.0000] <gsnedders>
annevk: they're purely theoretical extensions, that were disallowed for other reasons anyway (confusion with BOMs, most obviously)

[02:29:21.0000] <annevk>
philipj: well, they also decided on a 16-bit limit initially

[02:29:30.0000] <gsnedders>
annevk: well, depends which WG…

[02:29:32.0000] <annevk>
philipj: that didn't go well

[02:29:36.0000] <Ms2ger>
/me clicks the big green button

[02:30:07.0000] <philipj>
annevk: well, yeah :) the 24-bit limit seems to have done better, though

[02:30:08.0000] <gsnedders>
annevk: the Unicode Consortium did 16-bit, the ISO did an infinity scheme, AFAIK

[02:30:11.0000] <zcorpan>
Ms2ger: :-) wasn't sure about the current green-button policy for wpt

[02:30:35.0000] <gsnedders>
annevk: reconsiling them with Unicode 2.0 added the 21-bit restriction (for the sake of surrodates)

[02:30:47.0000] <philipj>
oh, was it 21 bits?

[02:31:06.0000] <annevk>
philipj: yeah, it's 21 at the moment

[02:31:21.0000] <gsnedders>
philipj: it's still 21-bit, hence 10FFFF being the max codepoint

[02:31:31.0000] <philipj>
ok, I just guessed a little :)

[02:32:11.0000] <gsnedders>
six byte UTF-8 allows 31-bit, which was the original limit of the ISO spec, apparently. My memory that it was infinite was totally wrong.

[02:35:26.0000] <Ms2ger>
jgraham, I wonder how you'd feel about adding something to th.js that takes an array of functions that return async_tests and runs them in sequence?

[02:47:39.0000] <gsnedders>
Anyone know if anyone is running the CSSWG\s tests for transitions?

[02:59:22.0000] <Ms2ger>
Not Servo

[03:00:16.0000] <gsnedders>
Despite you guys supporting some of it! :P

[03:01:49.0000] <Ms2ger>
Feel free to enable them :)

[03:02:56.0000] <gsnedders>
This, uh, may be what I'm doing.

[03:03:04.0000] <gsnedders>
Andseeing random noice in results in Servo.

[03:03:42.0000] <Ms2ger>
Lovel

[03:03:43.0000] <Ms2ger>
y

[03:04:18.0000] <gsnedders>
*noise

[03:04:24.0000] <gsnedders>
wondering if the tests are buggy…

[03:21:02.0000] <gsnedders>
they seem a bit abandoned? I have no idea how good they are

[03:21:07.0000] <gsnedders>
they have all kinds of JS magic involved…

[03:21:43.0000] <Ms2ger>
No idea

[03:21:56.0000] <gsnedders>
some of it is just working around the lack of async sequences

[03:23:15.0000] <gsnedders>
/me wopnders if the new failures in transforms are Servo breaking or your recent update

[03:23:21.0000] <gsnedders>
/me really can't type today…

[04:52:51.0000] <Ms2ger>
Hrm

[04:53:25.0000] <Ms2ger>
Is the storage event not fired at the window where you're making the changes?

[05:04:08.0000] <annevk>
Ms2ger: correct

[05:04:48.0000] <Ms2ger>
annevk, can you point that out in the spec?

[05:06:42.0000] <annevk>
Ms2ger: reverse lookup "send a storage notification"

[05:07:32.0000] <Ms2ger>
Gotcha, thanks

[05:39:49.0000] <annevk>
zcorpan: https://github.com/whatwg/html/pull/339 r?

[05:46:27.0000] <zcorpan>
annevk: do you have a reference at hand for people no longer wanting to support data: for workers?

[05:47:01.0000] <Ms2ger>
Wait, we don't? Why not?

[06:11:01.0000] <annevk>
zcorpan: sorry, I thought that was in the referenced issue

[06:11:30.0000] <annevk>
zcorpan: instead, the information on that is in the issue referenced from that issue: https://github.com/whatwg/fetch/issues/161#issuecomment-156414633

[06:16:02.0000] <mkwst>
annevk: FWIW, I've had adding `data:` support for Workers on my list of "things to do when I have free time" for a while now.

[06:16:25.0000] <annevk>
mkwst: for non-shared workers workers?

[06:16:47.0000] <mkwst>
like `data:` in the rest of Chrome, it wouldn't inherit an origin, so it would be a bit of a strangely sandboxed Worker.

[06:16:51.0000] <mkwst>
right. dedicated worker.

[06:16:55.0000] <annevk>
mkwst: oooh

[06:16:59.0000] <mkwst>
i won't be terribly sad if you kill it.

[06:17:03.0000] <annevk>
mkwst: so yeah, that'd be completely different from the specification

[06:17:08.0000] <mkwst>
yup!

[06:17:20.0000] <annevk>
mkwst: and so yeah, that's not what is being removed

[06:17:20.0000] <mkwst>
but we're already willfully violating that bit of the spec, so why not violate some more, right?

[06:17:29.0000] <mkwst>
ok, maybe I'm misunderstanding?

[06:17:31.0000] <annevk>
(in fact, data URL support was already removed, this is just removing some remnants)

[06:17:51.0000] <annevk>
mkwst: per the specification data URLs would be same-origin

[06:17:56.0000] <annevk>
(the old specification)

[06:17:58.0000] <mkwst>
annevk: I know.

[06:18:11.0000] <mkwst>
I know it's a bit annoying that Chrome's a special flower

[06:18:19.0000] <mkwst>
but I don't think we're planning on changing our `data:` handling.

[06:18:34.0000] <annevk>
Euhm, I don't care and I think we're trying to change Gecko

[06:18:42.0000] <mkwst>
ah.

[06:18:44.0000] <mkwst>
/me shuts up.

[06:18:46.0000] <annevk>
And most specifications reflect Chrome's policy

[06:20:27.0000] <zcorpan>
annevk: added a comment

[06:20:40.0000] <annevk>
zcorpan: where do you think the note should go?

[06:22:17.0000] <zcorpan>
annevk: how about after <li><p>Let <var>worker URL</var> be the resulting <span>absolute URL</span>.</p></li>

[06:22:32.0000] <annevk>
zcorpan: so you want two identical notes?

[06:23:09.0000] <zcorpan>
annevk: i don't follow

[06:23:23.0000] <annevk>
zcorpan: Worker and SharedWorker

[06:24:02.0000] <zcorpan>
oh. hmm

[06:25:14.0000] <annevk>
And this will go out of sync once we have those filesystem URLs (if ever) and such

[06:27:29.0000] <zcorpan>
yeah, two notes. the kinds of URLs we have doesn't change very often so i think it's worth it

[06:31:37.0000] <caitp>
it's almost that time of year when you fly to the keys and enjoy warmer-than-canada-in-january weather for a week or two. but there is no rest for the architects of the web

[08:40:30.0000] <MikeSmith>
nice https://code.google.com/p/chromium/issues/detail?id=303152#c22

[10:54:15.0000] <smaug____>
jgraham: most of the wpt tests are written by browser devs, right?

[10:58:21.0000] <smaug____>
(random wondering, why would anyone be sad about removing table sorting )

[11:02:48.0000] <wanderview>
jgraham: is there a way to attach the wpt --debugger arg to the child process in e10s mode?

[11:03:04.0000] <wanderview>
woops, wrong channel

[11:11:28.0000] <jgraham>
smaug____: I think most is very likely accurate, for a broad enough definition of "devs" (e.g. including QA)

[11:45:17.0000] <smaug____>
jgraham: yeah, I meant with the broader definition. I was just thinking how we could get help from also web devs

[11:46:11.0000] <smaug____>
right now I'd like to see tests for MessagePort

[14:27:27.0000] <bblfish>
annevk: I have succeeded in using Fetch now to authenticate cross originshttps://github.com/solid/solid-spec/issues/52#issuecomment-157519949

[14:27:33.0000] <bblfish>
oops. https://github.com/solid/solid-spec/issues/52#issuecomment-157519949


2015-11-18
[22:44:58.0000] <annevk>
smaug: because table sorting is cool!

[23:33:41.0000] <annevk>
Where in http://testthewebforward.org/docs/ is information on how to work with cross-origin tests?

[23:35:05.0000] <annevk>
/me finds http://testthewebforward.org/docs/test-format-guidelines.html#tests-involving-multiple-origins

[23:35:30.0000] <odinho>
There's someone who always mentions table sorting.  Maybe brucel?

[23:38:15.0000] <annevk>
odinho: also https://twitter.com/sil

[23:57:01.0000] <MikeSmith>
IMHO it's a failure of the priority of constituencies that we're not prioritizing table sorting higher

[23:57:28.0000] <MikeSmith>
it's something that normal end users would get a lot of benefit from

[23:59:45.0000] <annevk>
Hmm, http://天気の良い日.web-platform.test does not work locally? Lame

[00:01:17.0000] <annevk>
Never mind, port issue

[00:01:21.0000] <MikeSmith>
annevk: port?

[00:01:23.0000] <MikeSmith>
yeah

[00:01:24.0000] <MikeSmith>
http://xn--n8j6ds53lwwkrqhv28a.web-platform.test:8000/

[00:01:34.0000] <MikeSmith>
8000

[00:06:40.0000] <annevk>
protip, use window.close() and not close() from an attribute event handler

[00:06:52.0000] <annevk>
the latter will invoke document.close() and leave you puzzled

[00:07:46.0000] <annevk>
MikeSmith: also needed to add <meta charset=utf-8> btw, but that was more obvious

[00:08:37.0000] <MikeSmith>
annevk: why did you need to add it?

[00:08:42.0000] <MikeSmith>
ah, for a particular test

[00:18:51.0000] <annevk>
MikeSmith: yeah, to make those non-ASCII code points appear properly

[00:32:09.0000] <odinho>
annevk: Ah, yes. True, I've seen that.

[01:25:11.0000] <mkwst>
annevk: Given the validation that Yoav added to DOMTokenList in https://github.com/whatwg/dom/commit/63a030265fc3dac400a99f729fd5874490ae335c, what's the expected feature detection code we'd want developers to use?

[01:25:42.0000] <mkwst>
Something like `var x = document.createElement('iframe'); if (x.sandbox.add('x')) { ... }`?

[01:26:58.0000] <annevk>
mkwst: yeah, that's what yoav suggested

[01:27:25.0000] <annevk>
mkwst: he submitted a patch to HTML too, but hasn't addressed my feedback yet

[01:30:38.0000] <mkwst>
Got it.

[01:30:39.0000] <mkwst>
Thanks!@

[01:32:27.0000] <annevk>
yw#$

[01:35:39.0000] <zcorpan>
annevk: yeah in general avoiding barewords in event handler attributes is a good idea :-)

[01:36:41.0000] <annevk>
zcorpan: yeah, I guess I shouldn't even try it, but I kinda appreciate the minimalism

[01:36:55.0000] <annevk>
zcorpan: though of course, the more often you do that, the less extensible everything becomes

[01:38:13.0000] <zcorpan>
JS/DOM in general is pretty hostile to extensibility

[01:46:12.0000] <annevk>
In a certain way, yes, but in a lot of ways, also no

[02:25:27.0000] <tobie>
What's the long term idea with HTML event loop vs EcmaScript job queues?

[02:27:42.0000] <tobie>
context: ideally the generic sensor api could be implementable both in nodejs and within a browser, trying to understand and list why it's not possible in practice.

[02:38:53.0000] <annevk>
tobie: I think ideally ECMAScript defers logic to the host, but different folks have different ideas :/

[02:39:49.0000] <tobie>
reading JakeA's post on the event loop right now which points to https://esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-16

[02:41:58.0000] <annevk>
tobie: yeah, there's a ton of unresolved issues at the moment

[02:42:17.0000] <annevk>
tobie: it's not entirely clear how to resolve them and nobody seems super keen on doing the work

[02:42:54.0000] <tobie>
annevk: right--

[02:43:39.0000] <tobie>
it's interesting because nodejs seems to implement a browser-like event loop system with tasks and microtasks (though I should check)

[03:31:53.0000] <annevk>
MikeSmith: any idea why https://github.com/whatwg/html/search?l=html doesn't list "source" and why there's still a .inc file listed as PHP?

[03:52:19.0000] <annevk>
jgraham: reviewable still seems enabled? https://github.com/w3c/web-platform-tests/pull/2356

[03:52:44.0000] <annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2329 currently looks not okay due to reviewable, while I did address all the feedback

[03:52:50.0000] <annevk>
jgraham: I just don't want to create yet another account

[03:54:04.0000] <jgraham>
annevk: reviewable uses your GH account

[03:54:12.0000] <jgraham>
But I will try to disable it

[03:55:02.0000] <jgraham>
It seems to be disabled for new PRs

[03:56:31.0000] <annevk>
jgraham: well I just created that PR

[03:56:45.0000] <annevk>
8 minutes ago that is

[03:57:46.0000] <jgraham>
OK I also removed the webhook

[03:57:55.0000] <jgraham>
Pretty sure that's a bug in reviewable

[04:02:07.0000] <mkwst>
Reviewable looks great, but it requested write access to my repositories. I'd prefer that not be required to submit tests. :)

[04:12:25.0000] <nox>
mkwst: I'm not seeing this.

[04:12:45.0000] <nox>
https://usercontent.irccloud-cdn.com/file/uTe9h3Am/Capture%20d%E2%80%99e%CC%81cran%202015-11-18%20a%CC%80%2013.12.28.png

[04:12:49.0000] <nox>
mkwst: ^

[04:14:59.0000] <mkwst>
nox: Click publish after adding a comment.

[04:15:14.0000] <mkwst>
That ends up asking me for write permissions to repositories.

[04:15:47.0000] <mkwst>
See the first answer on https://github.com/Reviewable/Reviewable/wiki/FAQ :)

[04:16:23.0000] <mkwst>
Totally reasonable explanation (GitHub's permissions aren't granular enough). But still.

[04:24:47.0000] <nox>
Oh I see.

[04:24:58.0000] <nox>
GitHub's permissions generally suck, yeah.

[04:29:04.0000] <roc>
I'm glad I'm not the only one who noticed that

[04:30:19.0000] <roc>
I wanted to give an application push access to one specific repository under my account with an API key, but that seems to be impossible. You can only create API keys that have write access to *all* repos your account can write to.

[05:05:55.0000] <philipj>
roc: I think I did that when I maintained the html-mirror repo, using a deploy key

[05:06:02.0000] <Ms2ger>
roc, there's an easy solution, but it involves creating a new account :)

[05:06:15.0000] <philipj>
is that what you've tried, or are you all talking about something else?

[05:07:03.0000] <philipj>
oh, applications..., yeah that's something completely different

[05:07:22.0000] <MikeSmith>
> annevk: MikeSmith: any idea why https://github.com/whatwg/html/search?l=html doesn't list "source" and why there's still a .inc file listed as PHP?

[05:07:34.0000] <MikeSmith>
no idea

[05:08:13.0000] <MikeSmith>
I'm not sure how to control the behavior

[05:08:37.0000] <MikeSmith>
I don't know if the .gitattributes file affects that

[05:09:58.0000] <roc>
Ms2ger: yeah. that's horrible :-)

[05:12:34.0000] <roc>
While you github fans are here: if I want to have HTML-format documentation checked in alongside the code in a project, but I also want to have the latest checkout of that documentation available on the Web, what are my options?

[05:13:01.0000] <Ms2ger>
You can have travis publish to another git repo and use gh-pages

[05:13:46.0000] <Ms2ger>
That's how https://servo.github.io/rust-cssparser/cssparser/index.html works

[05:14:00.0000] <philipj>
roc: If you want to publish it on your own domain or something, a webhook that just pulls the latest into your ~/www or similar works too

[05:14:01.0000] <Ms2ger>
(Except that it pushes to a branch in the same repo for some reason)

[05:14:29.0000] <roc>
ick

[05:14:31.0000] <roc>
ok

[06:01:31.0000] <annevk>
roc: most WHATWG specifications are published by a commit-hook that just fetches a zip from the GitHub repository and publishes it

[09:59:30.0000] <smaug____>
annevk: want to do a sanity check? push/replaceState https://html.spec.whatwg.org/multipage/browsers.html#dom-history-pushstate don't seem to care at all whether the current entry is actually for the document for which the history object was created. I mean a case when one takes a reference to a history object and then navigates browser context to some other page, yet uses the old history object

[09:59:43.0000] <smaug____>
maybe I'm missing something here

[10:32:49.0000] <gsnedders>
Hixie_: yer site's down

[10:40:30.0000] <tantek>
gsnedders: I thought he was on G+ now

[10:41:06.0000] <gsnedders>
/me has no idea what the best way to prod him is now :)

[10:45:18.0000] <Domenic>
So in the spirit of the topic... is there a spec for navigator.javaEnabled?

[10:45:39.0000] <Domenic>
I guess I should check the html spec instead of just google... it'll be embarassing if it's there

[10:46:17.0000] <Domenic>
OK it does exist in the spec but is an attribute not a property

[10:46:21.0000] <Domenic>
s/property/method

[10:48:47.0000] <Hixie_>
whatwg.org just got updated to a newer distro

[10:49:00.0000] <Hixie_>
let me know if anything broke

[12:30:37.0000] <gsnedders>
ergh. feeling like I have to use sync xhr. :(

[12:31:00.0000] <gsnedders>
tl;dr: need to open a pop-up conditionally, depending on the result from an XHR request

[12:31:13.0000] <gsnedders>
and I can't use async XHR because then it's not a user-initiated window.open call

[12:31:40.0000] <gsnedders>
I suppose I could always open an about:blank popup and then close it depending on the XHR response, but that seems like a poor work-around

[12:32:05.0000] <gsnedders>
or just reimplement popups using an iframe and position absolute…

[12:32:16.0000] <gsnedders>
suggestions, anyone?

[13:30:48.0000] <darobin>
gsnedders: can you maybe do the XHR call before the user clicks? get the data in advance

[13:31:09.0000] <darobin>
otherwise, yeah, go with a modal+iframe

[13:33:23.0000] <gsnedders>
nah, an iframe is a bad idea actually, given no browser chrome to give URL + security status, bah

[13:33:33.0000] <gsnedders>
guess just doing a probably pointless XHR call is best

[13:46:01.0000] <caitp>
is there any reason why an iframe couldn't display security status?

[13:46:08.0000] <caitp>
like a little overlayed frowny face

[13:47:41.0000] <roc>
compat

[13:50:35.0000] <caitp>
if it's a potential phishing attack, the compat issue is probably second to the phishing issue

[13:52:05.0000] <zcorpan>
if we identify a phishing attack, don't we basically block the page?

[13:52:23.0000] <caitp>
ideally

[13:54:34.0000] <caitp>
or, the security advisory could show up outside of the iframe when you tried to interact with it

[13:54:46.0000] <caitp>
i'm sure there are clever ways around that issue

[13:58:11.0000] <bblfish>
annevk: is there a way to reduce the number of connections when using CORS? My server connects with a GET to remote resource. I think it 1) makes an OPTIONS request. This 2) returns a GET with a 401 and then 3) one gets the result

[13:59:43.0000] <gsnedders>
is there anyway to find declarations with a given selector in CSSOM easily?

[13:59:54.0000] <gsnedders>
like, better than just iterating through the entire Stylesheet?

[14:13:48.0000] <smaug____>
session history... hopeless

[15:06:50.0000] <smaug____>
so hopeless

[15:07:00.0000] <smaug____>
can we remove it from the platform ? :)

[15:07:28.0000] <zcorpan>
gsnedders: no :-(

[15:07:40.0000] <zcorpan>
smaug____: no :-(

[15:07:59.0000] <zcorpan>
we suck

[15:08:48.0000] <zcorpan>
smaug____: is there a problem with specifying no-op for non-active documents' history?

[15:09:58.0000] <smaug____>
this time I'm actually looking at the recent scroll restoration mode

[15:10:19.0000] <smaug____>
which is defined to do something, and that something isn't defined

[15:10:30.0000] <smaug____>
so actually, it isn't defined to do anything :)

[15:11:13.0000] <zcorpan>
very well then

[15:15:13.0000] <zcorpan>
smaug____: i think the spec was equally hand-wavy about scroll restoration before there was an api to turn it off

[15:16:19.0000] <smaug____>
that is true, but now I need to figure out what to actually turn off

[15:18:15.0000] <zcorpan>
yeah.. and i suppose if we want interop in this area, we should spec it better


2015-11-19
[00:37:52.0000] <bblfish>
annevk: thanks for answering. Do you have a pointer to work on caching for the whole site?

[00:39:05.0000] <bblfish>
Also timbl made an interesting point: that if the browser made a HEAD instead of an OPTIONS on a GET preflight, then there would be a need for 1 less connection.

[00:40:56.0000] <bblfish>
mhh, but perhaps the reason for the 3 calls for me is that the browser first does a GET

[00:41:51.0000] <bblfish>
It's odd in chrome I always see the GET first, then OPTIONS. But I suppose that is just a display error.

[00:44:40.0000] <bblfish>
Yes, on my server I first see the GET, then then OPTIONS. Presumably because the GET returned a 401?

[00:48:46.0000] <bblfish>
but the GET has all the required headers.

[01:20:42.0000] <bblfish>
annevk: I got the whole order wrong of what was happening. So I rewrote the entry. https://github.com/solid/solid-spec/issues/52#issuecomment-157882202

[01:22:41.0000] <bblfish>
It actually looks like things might be perfectly efficient.

[01:22:55.0000] <bblfish>
at least for a GET, which should be the most usual case.

[01:23:19.0000] <bblfish>
It's just weird that a GET returning a 401 then is followed by an OPTIONS

[01:27:40.0000] <MikeSmith>
nice to see patches finally landing in gecko for <details>+<summary> https://bugzilla.mozilla.org/show_bug.cgi?id=591737#c96

[01:40:00.0000] <rits_>
hello everyone, i am glad to start working as an outreachy intern in whatwg, thanks for the opportunity :-)

[01:40:49.0000] <MikeSmith>
hi rits_

[01:41:03.0000] <MikeSmith>
your application was accepted?

[01:42:05.0000] <rits_>
MikeSmith: hello, yes it was accepted, was there any issue related to it?

[01:42:22.0000] <MikeSmith>
rits_: very cool

[01:42:28.0000] <MikeSmith>
that's great to hear

[01:43:00.0000] <MikeSmith>
no, no issues that I know of

[01:43:36.0000] <rits_>
MikeSmith: great, thanks :)

[01:43:47.0000] <MikeSmith>
and I didn't have anything to do with helping with it so far, but going forward I'm happy to help you when I can

[01:44:45.0000] <MikeSmith>
I just had a new baby born about a month ago, and still in the process of trying to figure out some new work-life balance around that

[01:44:58.0000] <MikeSmith>
right now my baby has mostly been winning :)

[01:45:17.0000] <MikeSmith>
as far as where I've been spending time

[01:45:22.0000] <rits_>
MikeSmith: yeah, i wanted to discuss about my further steps, i am starting with bugs according to the timeline i made

[01:45:28.0000] <MikeSmith>
ok

[01:45:29.0000] <annevk>
zcorpan: happy b-day! 🎂

[01:45:40.0000] <zcorpan>
annevk: thx!

[01:45:44.0000] <jgraham>
++

[01:45:56.0000] <rits_>
congrats for the baby :) MikeSmith

[01:46:06.0000] <jgraham>
++ to that too

[01:46:09.0000] <MikeSmith>
rits_: thanks :)

[01:46:18.0000] <MikeSmith>
zcorpan: felix navidad!

[01:47:18.0000] <rits_>
MikeSmith: baby would be winning around 1year of yours more :D

[01:47:32.0000] <jgraham>
MikeSmith: Out by about a month there :)

[01:47:33.0000] <rits_>
zcorpan: Happy b'day :)

[01:48:02.0000] <MikeSmith>
rits_: yeah but I need to get better skilled at squeezing in more work between baby time

[01:48:47.0000] <rits_>
MikeSmith: yeah if the baby allows you

[01:48:53.0000] <MikeSmith>
yeah

[01:48:57.0000] <MikeSmith>
rits_: as far as next steps I think it's just "more of what you already did"

[01:49:09.0000] <MikeSmith>
you already landed at least one spec change, right?

[01:49:41.0000] <rits_>
MikeSmith: yeah i did

[01:50:18.0000] <zcorpan>
thx. and congrats MikeSmith :-)

[01:50:46.0000] <MikeSmith>
rits_: ok, so far as I know it's up to you to decide what bugs to work on next or where else to put your time

[01:51:42.0000] <rits_>
MikeSmith: yes i will resolve the critical issues first,

[01:52:26.0000] <annevk>
rits_: indeed, you can make up your own schedule, but also, to be clear, at this point you're not expected to do anything

[01:53:01.0000] <annevk>
rits_: I believe the internships starts with the week in Orlando and will last three months or so from that point

[01:53:29.0000] <annevk>
rits_: having said that, if you want to contribute now, that's perfectly fine and appreciated :-)

[01:54:09.0000] <rits_>
annevk: yeah ok, then i will try to learn about solving the issues till then, this time can be utilized for that

[01:54:10.0000] <annevk>
bblfish: there may or may not be an open issue or bug against Fetch

[01:54:12.0000] <annevk>
bblfish: not sure

[01:55:03.0000] <bblfish>
annevk: I rewrote the entry, it looks like everything is fine, except for the weirdness that an OPTIONS follows a GET with CORS headers

[01:55:13.0000] <rits_>
annevk: i will work both ways :), will contribute in parallel with working according to the timeline,

[01:56:04.0000] <yoav>
annevk: regarding your "this should not use <code>" comment, did you refer to the "supported tokens"?

[01:56:10.0000] <annevk>
yoav: yes

[01:56:15.0000] <yoav>
OK, thanks

[01:56:27.0000] <annevk>
bblfish: hmm, are you sure something is not cached?

[01:56:31.0000] <annevk>
bblfish: sounds very fishy

[01:56:43.0000] <annevk>
rits_: \o/

[01:56:53.0000] <bblfish>
I'll make a new resource

[01:57:03.0000] <rits_>
annevk: :-)

[01:57:07.0000] <bblfish>
To mee it sounds brillant though :-)

[02:01:31.0000] <yoav>
annevk: addressed your comments

[02:02:44.0000] <annevk>
yoav: so instead of <code> you want to use <span>

[02:02:55.0000] <annevk>
yoav: and the sandbox entry needs to be consistent with that of course

[02:02:57.0000] <yoav>
Oh, OK

[02:03:05.0000] <yoav>
that's what I was missing :)

[02:03:36.0000] <annevk>
yoav: it also seems that the xref for "the sandbox attribute" is wrong

[02:04:01.0000] <annevk>
yoav: you want to xref just "sandbox", as <code data-x="attr-iframe-sandbox">

[02:05:51.0000] <yoav>
annevk: OK, fixed

[02:06:54.0000] <annevk>
yoav: is the xref for supported tokens not still wrong?

[02:07:04.0000] <annevk>
yoav: and it's still inconsistent with sandbox, where you use <code>

[02:07:13.0000] <yoav>
yeah, just saw that

[02:07:20.0000] <yoav>
fixing it

[02:07:48.0000] <annevk>
yoav: using a separate paragraph for relList's DOMTokenList's supported tokens might be good too

[02:07:54.0000] <annevk>
yoav: to make them completely identical

[02:08:10.0000] <annevk>
yoav: oh, and "the sandbox attribute" is not fixed yet

[02:09:49.0000] <yoav>
separated relList to its own <p>

[02:10:05.0000] <yoav>
what is still wrong with the sandbox attribute?

[02:10:54.0000] <yoav>
annevk: should it be <code>? should it just xref "sandbox"?

[02:11:07.0000] <annevk>
yoav: yes and yes

[02:11:15.0000] <yoav>
OK

[02:11:33.0000] <annevk>
When in doubt, just look at what the rest of HTML does

[02:13:17.0000] <annevk>
yoav: also, the second 's doesn't seem to make sense for the sandbox sentence...

[02:13:50.0000] <yoav>
so:

[02:13:54.0000] <yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>

[02:13:55.0000] <yoav>
  for <code data-x="sandbox">sandbox</code>'s <code>DOMSettableTokenList</code>'s are

[02:13:55.0000] <yoav>
  the allowed values defined in <code data-x="sandbox">the sandbox attribute</code>

[02:13:56.0000] <yoav>
  and supported by the user agent.</p>

[02:14:27.0000] <zcorpan>
s/'s are/ are/

[02:15:26.0000] <annevk>
yoav: hmm, no

[02:15:34.0000] <zcorpan>
data-x="attr-iframe-sandbox" i think?

[02:15:35.0000] <annevk>
yoav: "the <code data-x="attr-iframe-sandbox">sandbox</code> attribute"

[02:15:54.0000] <annevk>
yoav: is what the rest of HTML does, as far as I can tell

[02:16:53.0000] <annevk>
Hmm, Twitter is done?

[02:16:56.0000] <annevk>
down, even

[02:17:33.0000] <yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>

[02:17:34.0000] <yoav>
  for <code data-x="attr-iframe-sandbox">sandbox</code>'s <code>DOMSettableTokenList</code> are

[02:17:34.0000] <yoav>
  the allowed values defined in <code data-x="attr-iframe-sandbox">the sandbox attribute</code>

[02:17:35.0000] <yoav>
  and supported by the user agent.</p>

[02:20:11.0000] <annevk>
yoav: shouldn't the first sandbox reference the IDL attribute? The second is still not as I quoted it

[02:22:39.0000] <yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>

[02:22:39.0000] <yoav>
  for <code data-x="dom-iframe-sandbox">sandbox</code>'s <code>DOMSettableTokenList</code> are

[02:22:39.0000] <yoav>
  the allowed values defined in the <code data-x="attr-iframe-sandbox">sandbox</code> attribute

[02:22:41.0000] <yoav>
  and supported by the user agent.</p>

[02:22:45.0000] <yoav>
OK, sorry for missing that

[02:24:36.0000] <yoav>
annevk: OK, pushed that latest version. Gotta go now, but let me know if there are any further issues

[02:27:23.0000] <annevk>
Hmm, I wish I'd know earlier he was in a hurry

[02:27:30.0000] <annevk>
known*

[02:37:09.0000] <annevk>
I wonder how html/browsers/origin/cross-origin-objects/cross-origin-objects.html ever landed since it hardcodes domain names

[02:37:33.0000] <annevk>
Seems like Ms2ger might have reviewed that

[02:38:46.0000] <annevk>
jgraham: would the best course of action here be to rename the files to include .sub and make the appropriate modifications?

[02:38:59.0000] <annevk>
jgraham: or first land a rename commit and then make modifications?

[02:43:06.0000] <annevk>
Well, I'll just do my best to get them fixed...

[02:48:40.0000] <jgraham>
annevk: Fix and rename in one step seems fine

[02:49:57.0000] <Ms2ger>
Hrm, I didn't notice that bit

[02:53:09.0000] <annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2360

[02:53:12.0000] <annevk>
Ms2ger: ^

[02:53:24.0000] <annevk>
Running that locally makes Firefox still pass all tests

[02:54:08.0000] <annevk>
jgraham: how is it clear btw what is test and what are support files?

[02:54:16.0000] <annevk>
that doesn't really seem indicated in that test

[02:54:28.0000] <Ms2ger>
"includes testharness.js"

[02:54:49.0000] <Ms2ger>
I don't think '//{{domains[www1]}}:' + location.port is right

[02:54:51.0000] <Ms2ger>
jgraham, ^

[03:04:13.0000] <annevk>
Ms2ger: why would that be wrong?

[03:23:44.0000] <jgraham>
Well I would usually write {{ports[http][0]}} unless that wasn't what was required

[03:24:20.0000] <zcorpan>
jgraham: {{GET[foo]}} in .sub.html escapes &, but doesn't escape "?

[03:25:22.0000] <zcorpan>
jgraham: this makes it impossible to use literal &quot; (in attribute value)

[03:27:05.0000] <jgraham>
zcorpan: Hmm, it uses cgi.escape

[03:28:03.0000] <zcorpan>
If it is used as cgi.escape(string_to_escape, quote=True), it also escapes ". https://wiki.python.org/moin/EscapingHtml

[03:28:16.0000] <zcorpan>
/me lunch

[03:30:33.0000] <jochen__>
annevk, is "content attribute" a defined term?

[03:30:33.0000] <jgraham>
zcSounds reasonable if it doesn't break anything

[03:30:47.0000] <jochen__>
annevk: i.e. should I reference some spec for it, or just write "content attribute"?

[03:31:50.0000] <MikeSmith>
annevk: with the changes Hixie made on the whatwg.org host does that now mean it's possible to get https://lists.whatwg.org/pipermail/whatwg-whatwg.org URLs working

[03:40:14.0000] <Ms2ger>
jochen__, there's a definition you can link to, I believe

[03:41:18.0000] <Ms2ger>
Hrm

[03:42:18.0000] <Ms2ger>
jochen__, nevermind, there's a definition, but it doesn't get an ID for some reason

[03:42:28.0000] <jochen__>
kk

[03:42:32.0000] <Ms2ger>
https://html.spec.whatwg.org/multipage/infrastructure.html#terminology

[03:42:35.0000] <Ms2ger>
annevk, ^

[03:52:12.0000] <annevk>
MikeSmith: that still depends on DreamHost enabling HTTPS support for hosted email lists

[03:52:39.0000] <MikeSmith>
ah OK

[03:52:53.0000] <MikeSmith>
I thought they told you they were going to do that

[03:52:56.0000] <MikeSmith>
or something

[03:53:01.0000] <annevk>
jgraham: wouldn't you just want to reflect the port in use typically?

[03:53:19.0000] <annevk>
MikeSmith: no, unfortunately not

[03:53:33.0000] <MikeSmith>
ah

[03:58:52.0000] <jochen__>
annevk, hope I've addressed all your comments on the referrerPolicy IDL thing

[03:59:49.0000] <jgraham>
annevk: I guess that's also fine if it's what you want

[03:59:49.0000] <jgraham>
It depends if you already using script or not

[03:59:49.0000] <jgraham>
If you are then using location.port isn't too bad. If you are trying to write a href attribute or stylesheet or something, that doesn't work

[04:00:19.0000] <annevk>
jochen__: looks more reasonable now

[04:00:49.0000] <annevk>
jgraham: this already uses script, I've used {{location[port]}} for the other cases in recently submitted PRs

[04:03:39.0000] <jgraham>
annevk: Yeah, it isn't a problem afaik

[04:30:09.0000] <Ms2ger>
Suddenly, <details> support in Gecko

[04:37:25.0000] <nox>
Interesting.

[04:37:26.0000] <odinho>
boom

[04:54:18.0000] <zcorpan>
jgraham: is it https://github.com/w3c/wptserve/blob/b6b082fb70c592c6164c76aa167ae4dc284ebb69/wptserve/pipes.py#L422 ?

[05:00:29.0000] <jgraham>
zcorpan: Yes

[05:04:42.0000] <catalinb>
JakeA: ping

[05:07:12.0000] <JakeA>
catalinb: morning!

[05:08:38.0000] <catalinb>
JakeA: hey. I need some help understanding something regarding SW registrations. Do you have a few minutes?

[05:13:03.0000] <JakeA>
catalinb: sure, although I'm on my phone so my debugging is limited

[05:14:22.0000] <catalinb>
JakeA: okay, so we have a sequence of two register calls for the same scope with two different scripts. The first service worker script will reject the install handler after some.

[05:15:04.0000] <catalinb>
JakeA: can the following sequence happen?

[05:15:51.0000] <catalinb>
1. call register() number two which will invoke Get Registration and find the registration created by the previous call

[05:16:20.0000] <catalinb>
2. the install handler from the first sw rejects and ends up clearing the registration and thus removing it from the registration map

[05:16:57.0000] <catalinb>
3. continue updating (from the second register call) with a registration that's not in the registration map

[05:20:35.0000] <catalinb>
JakeA: does it make sense?^

[05:21:54.0000] <JakeA>
catalinb: sounds like a bug, which could be a spec bug. Hang on, let me dig into the spec (it's 5am here so expect slowness)

[05:23:53.0000] <catalinb>
thanks! and sorry for bothering you so early in the morning :)

[05:29:12.0000] <JakeA>
catalinb: at what point is register 1 at when register 2 is invoked?

[05:30:23.0000] <zcorpan>
jgraham: https://github.com/w3c/wptserve/pull/68 - it does what i want but i don't know if some existing test relies on not escaping ". it seems unlikely though

[05:34:30.0000] <catalinb>
JakeA: register 2 is called while waiting  for the first sw to reject the install waitUntil promise.

[05:36:38.0000] <catalinb>
at this point the registration is in the map

[05:37:33.0000] <catalinb>
We then get to Step 4.1 from Update Algorithm which is called in parallel

[05:39:26.0000] <catalinb>
I think this can race with steps 13-18 from "Install Algorithm" for the first service worker

[05:41:41.0000] <JakeA>
catalinb: is the race solved by https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#dfn-registration-queue-adt

[05:41:46.0000] <smaug____>
oh, I just realized Gecko does something very different to what the spec says with pushState/replaceState.  Hmm, spec seems to have yet another bug there, but whether Gecko is sane...dunno

[05:43:28.0000] <catalinb>
JakeA: well no, because the first service worker's timestamp was already popped from the registration queue

[05:43:57.0000] <smaug____>
(or maybe it isn't that bad)

[05:45:51.0000] <JakeA>
catalinb: so 4.2 is hit at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#update-algorithm - the installing worker is terminated. When is the registration removed from the map?

[05:47:19.0000] <catalinb>
JakeA: at 16.3 at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#installation-algorithm

[05:47:23.0000] <catalinb>
before 4.2 is hit

[05:48:38.0000] <catalinb>
this is possible since 4.2 from Update is not reached atomically from Register

[05:48:58.0000] <JakeA>
Ahhhh so registration 1 rejects itself, I thought it was being rejected because reg2 terminated it

[05:49:05.0000] <JakeA>
Following now

[05:50:14.0000] <JakeA>
catalinb: yeah, I don't think this should happen. Can you file a bug?

[05:50:23.0000] <catalinb>
yup.

[06:06:41.0000] <zcorpan>
argh when will i learn to git add before git commit --amend

[06:09:48.0000] <roc>
just use -a a lot and try to pretend the index doesn't exist

[06:12:45.0000] <smaug____>
Why TokenList validation steps convert to lowercase ascii?

[06:20:03.0000] <smaug____>
in all the cases

[06:20:05.0000] <smaug____>
looks odd

[06:20:15.0000] <smaug____>
oh well, not going to care about this

[06:52:08.0000] <gsnedders>
is there any telemetry for % of users with user stylesheets?

[06:53:36.0000] <jgraham>
I don't know, but I would guess it's very very low

[06:53:52.0000] <gsnedders>
This is the obvious answer. :)

[07:01:46.0000] <Ms2ger>
Does Stylish count?

[07:04:09.0000] <gsnedders>
Ms2ger: I'm going for yes

[07:04:45.0000] <Ms2ger>
amo says ~600000 users

[07:04:54.0000] <Ms2ger>
That's still very low, of course

[07:23:08.0000] <Ms2ger>
> W3C Invites Implementations of XSL Transformations (XSLT) Version 3.0

[07:24:26.0000] <gsnedders>
hey, I'm sure there will be implementations!

[07:24:31.0000] <gsnedders>
…just not in browsers

[07:53:31.0000] <caitp>
heycam|away|away / annevk / whoever: is it a good idea to ship DOM @@iterator stuff in the state they're in (with inconsistencies between certain iterable DOM interfaces), or should more time be spent poking and prodding people to make them consistent

[07:53:50.0000] <caitp>
eg window[@@iterator] vs NodeList.prototype[@@iterator]

[07:53:54.0000] <annevk>
caitp: I think bz would prefer some more prodding

[07:54:19.0000] <caitp>
I'd prefer some more modding too it just doesn't look like it's been happening

[07:54:34.0000] <annevk>
caitp: there's not much folks working actively on IDL

[07:54:48.0000] <annevk>
so it's always a bit behind the facts

[07:54:54.0000] <caitp>
:(

[07:57:13.0000] <caitp>
on the one hand, it would be nice to ship now, on the other hand, might be hard to fix things later if they do ever change

[07:57:29.0000] <annevk>
maybe run it by bz?

[07:57:49.0000] <caitp>
does he hang out here? I don't spend a lot of time on public-script-coord etc

[07:57:58.0000] <annevk>
see /msg

[07:58:51.0000] <annevk>
jgraham: so can I merge https://github.com/w3c/web-platform-tests/pull/2360?

[08:21:39.0000] <Ms2ger>
No

[08:21:45.0000] <Ms2ger>
(I beat you to it :))

[08:23:40.0000] <annevk>
ta

[09:20:35.0000] <annevk>
mkwst: did you look at the latest in https://github.com/whatwg/html/pull/323 very recently?

[09:20:40.0000] <annevk>
mkwst: would appreciate review

[11:22:59.0000] <mkwst>
annevk: Sorry, was out this afternoon. Will look at the PR tomorrow morning. :)

[12:32:27.0000] <emerson>
https://gist.github.com/emersonveenstra/f79807307abae9a16401 with this document, would Baz be a subsection of Bar?


2015-11-20
[01:01:24.0000] <mkwst>
annevk: https://github.com/whatwg/html/pull/323 LGTM % bz's comments.

[01:01:52.0000] <mkwst>
I added some tests which verify that the things he suggested actually do match existing Chrome/Firefox behavior.

[01:15:28.0000] <annevk>
Cool

[01:15:41.0000] <annevk>
I'll do some review of all that now

[01:43:58.0000] <mkwst>
annevk: thanks! I was wondering why substitution wasn't working... ;)

[01:44:18.0000] <annevk>
mkwst: did you even ran that test? :-P

[01:44:29.0000] <annevk>
run*

[01:44:36.0000] <mkwst>
I did! I hard-coded `web-platform.test:8000`.

[01:44:44.0000] <annevk>
I see

[01:44:50.0000] <mkwst>
Then I just assumed that my server was broken, so I changed it to a {{}} thing and uploaded.

[01:45:33.0000] <annevk>
mkwst: appreciated that comment on the race condition, it was totally unnecessary to have that

[01:46:12.0000] <mkwst>
Internet high-five!

[01:46:12.0000] <annevk>
Ms2ger: jgraham: can https://github.com/w3c/web-platform-tests/pull/2344 be merged?

[01:47:11.0000] <Ms2ger>
mkwst, you don't have push access?

[01:47:24.0000] <mkwst>
I do. I can click the button if you like.

[01:47:47.0000] <Ms2ger>
If you think it's good to go, push away

[01:47:50.0000] <mkwst>
Easy.

[01:51:16.0000] <annevk>
Ms2ger: I was mostly wondering about squashing policies and such

[01:51:26.0000] <annevk>
Ms2ger: but I guess web-platform-tests likes it rather messy

[01:51:44.0000] <Ms2ger>
Heh

[01:52:02.0000] <Ms2ger>
I think I would have squashed this one, but I think it was fine like this too

[01:57:49.0000] <mkwst>
eh. squashing is for the weak of mind.

[02:19:15.0000] <annevk>
mkwst: so can https://github.com/w3c/web-platform-tests/pull/2329 be merged now?

[02:19:57.0000] <mkwst>
annevk: Other than the fact that your ';' key is apparently broken, LGTM.

[02:21:20.0000] <annevk>
mkwst: as long as there is no forced coding style I will exercise my rights

[02:25:23.0000] <mkwst>
I'm sure we can all agree on https://google.github.io/styleguide/javascriptguide.xml without any discussion or argument, right?

[02:27:26.0000] <Ms2ger>
No

[02:28:11.0000] <annevk>
Ms2ger: so how do I checkout an old branch to rebase it without running into the tools/ mess?

[02:29:15.0000] <annevk>
mkwst: reminds me of http://w3cmemes.tumblr.com/post/66860522018/jeff-jaffe-tells-robin-berjon-how-it-is

[02:30:57.0000] <philipj>
annevk: thoughts on having DOMTokenList.add() return false in contexts that have no supported tokens?

[02:31:42.0000] <philipj>
this would be to avoid the case where a DOMTokenList attribute is "upgraded" from something class-like to something rel-like, even though I don't know if that will ever happen

[02:31:56.0000] <Ms2ger>
annevk, I think maybe it works if you rm -r tools

[02:32:24.0000] <annevk>
philipj: sounds reasonable, might happen for <a rel> I suppose

[02:32:36.0000] <philipj>
annevk: ok, will file a spec issue!

[02:38:37.0000] <annevk>
philipj: make a PR!

[02:39:21.0000] <philipj>
annevk: uh... :)

[02:39:24.0000] <philipj>
will try, then

[03:01:51.0000] <mkwst>
Hrm. If a method returns a Promise, should it still throw a TypeError if it's called with the wrong kinds of objects? Or should it reject the promise?

[03:02:13.0000] <mkwst>
idlharness seems to expect the former, which surprises ms.

[03:02:15.0000] <mkwst>
me.

[03:03:07.0000] <philipj>
mkwst: I'm pretty sure it should reject the promise, but did you check the WebIDL spec?

[03:03:29.0000] <mkwst>
philipj: y'all are faster. :)

[03:04:25.0000] <philipj>
mkwst: I think it's in http://heycam.github.io/webidl/#es-operations

[03:05:00.0000] <philipj>
The "If the operation has a return type that is a promise type" bit

[03:05:17.0000] <philipj>
Gotta have lunch, bye!

[03:05:20.0000] <mkwst>
Right. I think idlharness is wrong. Ha! Take that, testing framework!

[03:09:03.0000] <yoav>
philipj: replied on the issue, but if we're returning false, you would have the opposite problem

[03:09:42.0000] <yoav>
and the algorithm needs to be redefined so that in that case, the token is added to DOMTokenList, even if we returned false

[03:10:01.0000] <yoav>
all in all, I think currently it's better

[03:10:20.0000] <yoav>
philipj: Gotta go, but let's continue on the issue

[03:13:21.0000] <annevk>
mkwst: yeah, stuff that returns a promise never throws, only rejects

[03:16:33.0000] <mkwst>
annevk: Yup. https://github.com/w3c/testharness.js/issues/164

[04:10:17.0000] <jgraham>
Does anyone who knows anything at all about webcrypto want to look at https://github.com/w3c/web-platform-tests/pull/2352 ? I really know nothing

[04:36:17.0000] <Ms2ger>
Will do it if nobody beats me to it

[05:11:18.0000] <annevk>
jgraham: Ms2ger: done

[05:12:17.0000] <annevk>
Ms2ger: you should probably have another look since I missed that it attempted to fix a specific issue

[05:23:28.0000] <wanderview>
JakeA: ping

[05:23:43.0000] <wanderview>
or are you recovering from chromedevsummit?

[05:24:26.0000] <JakeA>
wanderview: half awake!

[05:25:04.0000] <wanderview>
JakeA: well, I have a service worker activating corner case to ask you about...

[05:25:13.0000] <wanderview>
JakeA: are you awake enough for that?

[05:28:01.0000] <wanderview>
JakeA: my question is... while a SW is activating fetch event gets delayed until activate event is done... so you may have a queue of fetch events to service when a SW becomes "activated"... but when a SW becomes activated, the next SW in the activation queue may immediately start replacing it... the way the spec is written the delayed fetch events fire on

[05:28:01.0000] <wanderview>
the first SW even though its being exited... is this correct?  should FetchEvents instead wait for an activated worker and an empty activation queue?

[05:28:08.0000] <JakeA>
wanderview: I can try. If not I can save it for my flight home

[05:28:47.0000] <wanderview>
JakeA: thanks... I have to go take my daughter to school... but will be back in 30 minutes or so... I need to implement something around this this morning... if you have time to give me an opinion

[05:28:48.0000] <wanderview>
thanks again!

[05:32:26.0000] <JakeA>
wanderview: just to confirm, the situation is: processing a queue of fetches, then a waiting worker calls skipWaiting() and starts activating?

[05:33:39.0000] <JakeA>
If so, it feels like queue processing should be halted until the new SW activates.

[05:56:28.0000] <annevk>
mkwst: so https://github.com/w3c/web-platform-tests/pull/2354 can land?

[05:56:38.0000] <annevk>
mkwst: what about https://github.com/w3c/web-platform-tests/pull/2356?

[06:01:28.0000] <wanderview>
JakeA: ok, I'll write a spec issue then... currently the spec get the local activeWorker variable from registrations active worker, then waits, then fires events at activeWorker... sounds like it should reaquire the activeWorker variable and loop there

[06:05:58.0000] <mkwst>
annevk: https://github.com/w3c/web-platform-tests/pull/2354 LGTM. Looking at the orher one now.

[06:11:50.0000] <annevk>
ta

[06:16:43.0000] <wanderview>
JakeA: hmm... we don't wait for activate event for other functional events like push AFAICT

[06:17:12.0000] <JakeA>
wanderview: we should

[06:17:20.0000] <wanderview>
JakeA: I'll write another issue

[06:18:50.0000] <JakeA>
wanderview: cheers. Sorry about that. The only events that shouldn't be queued are those that are directed at a specific worker regardless of state, eg postmessage

[06:19:18.0000] <wanderview>
JakeA: np... thanks for clarifying the waiting behavior for fetch

[06:22:27.0000] <wanderview>
JakeA: I guess the new activating worker does wait for the previous worker to finish handling any in flight events... so maybe it could still fire fetch events on the old worker

[06:22:55.0000] <mkwst>
annevk: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/Frame.cpp&rcl=1448007983&l=201 are Chrome's current navigation checks.

[06:23:20.0000] <mkwst>
Certainly not set in stone, but that's what we're currently doing when failing the test you wrote.

[06:24:53.0000] <annevk>
mkwst: I mostly wrote that test because someone claimed it was a bug in Gecko, but then when I looked into it I couldn't really figure out what Chrome was protecting

[06:24:57.0000] <JakeA>
wanderview: since activation involves deleting caches and migrating data, the old SW must be gone before activation starts

[06:25:13.0000] <mkwst>
annevk: It's protecting my sanity, if nothing else. :)

[06:25:42.0000] <wanderview>
JakeA: true... I guess the question is do we want the fetch event to use the new caches or the soon to be deleted old caches?

[06:25:42.0000] <annevk>
mkwst: seems like your sanity might be my insanity then

[06:25:53.0000] <wanderview>
JakeA: issue 1: https://github.com/slightlyoff/ServiceWorker/issues/785

[06:26:01.0000] <mkwst>
I don't understand why the 1frame can access it's parent's opener in the first place.

[06:26:01.0000] <annevk>
mkwst: also, I've no idea yet if any of this matches the specification or not :-/

[06:26:16.0000] <mkwst>
*shrug* We can worry about the spec later. ;)

[06:26:36.0000] <wanderview>
JakeA: issue 2: https://github.com/slightlyoff/ServiceWorker/issues/786

[06:27:02.0000] <annevk>
mkwst: well the <iframe> gets the crossOriginWindow of the parent, and that exposes opener to anyone...

[06:27:03.0000] <JakeA>
wanderview: cheers. Will reply when I'm in the office (couple of hours)

[06:27:20.0000] <wanderview>
JakeA: np, thanks for the help

[06:27:50.0000] <mkwst>
annevk: Can we stop doing that? :)

[06:28:40.0000] <annevk>
mkwst: well, if .parent works, you can then navigate that frame and then grab .opener from something that is same-origin with you and do all the things

[06:28:56.0000] <annevk>
mkwst: it's not clear what you're protecting

[06:29:09.0000] <mkwst>
1. sandbox would prevent that navigation.

[06:29:28.0000] <mkwst>
2. I don't like that we persist `opener` across top-level navigations. That's totally strange.

[06:29:56.0000] <annevk>
I was surprised by 2

[06:30:05.0000] <annevk>
Especially it being persisted across cross-origin navigations

[06:30:28.0000] <annevk>
Not sure if Gecko does that btw, only tested that in Chrome

[06:30:58.0000] <mkwst>
3. A frame that navigates the whole window is significantly more visible than a frame that silently navigates it's parent's opener.

[06:31:25.0000] <annevk>
Yeah, 3 is a somewhat reasonable reason to block it anyway

[06:32:47.0000] <mkwst>
It looks like firefox does #2.

[06:32:59.0000] <mkwst>
Which means folks probably rely on it. But it's crazy.

[06:35:26.0000] <annevk>
Agreed

[06:36:01.0000] <annevk>
So blocking the navigation for reason 3 but not the access I guess I can buy

[06:36:12.0000] <annevk>
Not sure what bz thinks of that though

[06:48:25.0000] <mkwst>
I think blocking the navigation is a totally reasonable thing to do. I also think denying `opener` on the cross-origin window objects is a totally reasonable thing to do.

[06:48:40.0000] <mkwst>
Also also, let's break whoever relies on #2.

[07:36:32.0000] <annevk>
mkwst: sounds reasonable, but I'm starting to lose track of how we want to change the specification if what we want to implement is still unclear

[07:41:00.0000] <annevk>
mkwst: I have attempted to summarize your position

[07:41:04.0000] <annevk>
mkwst: in the issue

[07:41:15.0000] <mkwst>
Thanks! I'll take a look in a second.

[07:41:16.0000] <annevk>
mostly for my own understanding

[07:41:19.0000] <mkwst>
Well, a minute.

[07:41:26.0000] <annevk>
Take two!

[08:07:02.0000] <gsnedders>
given a well-formed XHTML document (with no other namespaces, default namespace is XHTML), what changes with HTML parsing? non-void elements?

[08:07:41.0000] <annevk>
gsnedders: if it's only well-formed, lots

[08:07:42.0000] <gsnedders>
the CDATA stuff

[08:07:53.0000] <gsnedders>
and valid

[08:08:00.0000] <annevk>
gsnedders: aaah, you didn't say that!

[08:08:34.0000] <gsnedders>
/me really isn't awake today

[08:08:41.0000] <annevk>
gsnedders: <br></br> would change

[08:08:51.0000] <gsnedders>
whitespace after </body> would change

[08:09:04.0000] <annevk>
gsnedders: whitespace at the start too, maybe?

[08:09:08.0000] <annevk>
hmm

[08:09:09.0000] <gsnedders>
maybe

[08:09:17.0000] <annevk>
still quite a bit of changes I think

[08:09:36.0000] <annevk>
but euh, I thought we could stop caring about this?

[08:09:39.0000] <gsnedders>
/me wants to see how he can move over the majority of the CSS testsuite to HTML source files with minimal diffs

[08:09:59.0000] <gsnedders>
So I kinda want to know if I can just rename the file without changing the content at all.

[08:11:46.0000] <gsnedders>
Because parsing/reserialising causes a lot of churn from removing trailing slashes and the like

[09:50:24.0000] <jsx>
Reading MSDN, readyState state names (UNSENT, LOADING, DONE etc) seems to be different in the IE implementation. For example, instead of DONE, they use READYSTATE_COMPLETE. So does this mean that XMLHttpRequest.DONE is not available in IE?

[10:43:54.0000] <Ms2ger>
jsx, I would assume they support XMLHttpRequest.DONE by now

[10:49:57.0000] <jsx>
Ms2ger: Unfortunately I don't have a windows machine to test it and make sure :/

[11:04:32.0000] <jsbell>
wanderview: FYI I'm working to sync up the wpt and blink copies of the cache storage tests. (Just so we don't duplicate efforts)

[11:05:25.0000] <wanderview>
jsbell: sounds good

[11:05:44.0000] <wanderview>
jsbell: I don't think we have touched the cachestorage tests in a while... although we have heavily, heavily modified the blink service worker tests we imported

[11:06:39.0000] <jsbell>
wanderview: cool. I just need to dig through why they've diverged (presumably spec changes inconsistently tracked). Don't expect anything 'til after thanksgiving

[11:07:58.0000] <wanderview>
jsbell: np... I'm going on PTO shortly :-)

[12:07:41.0000] <wanderview>
Domenic: what do you think about relaxing the same-object requirment for tee'd stream chunks?  some discussion here: https://github.com/whatwg/streams/issues/401#issuecomment-152176591

[12:08:35.0000] <wanderview>
Domenic: it seems allowing same-object would make some optimizations hard (since chunks are observable across tee branches) and we could optimize out memory penalty of different-object using copy-on-write semantics

[13:18:39.0000] <Domenic>
wanderview: I am OK with either as long as we decide on a single strategy for all implementations: structured clone or don't

[13:18:55.0000] <Domenic>
wanderview: the current choice is because I have gotten repeated feedback from Chrome and Firefox people that copy on write is not implementable

[13:19:20.0000] <wanderview>
Domenic: ok :-) I'm not a js engine guy... I guess that makes sense

[13:19:58.0000] <Domenic>
If we think the other optimizations it might prevent are more important than the memory overhead though, we can change it...

[14:10:52.0000] <Domenic>
MikeSmith: can I get edit access to https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits ?

[14:12:04.0000] <Domenic>
How does HTML's inline bug tracking actually work? Is it just comments with bugzilla URLs in them?

[14:12:10.0000] <Domenic>
I guess I can test this theory

[15:55:03.0000] <wanderview>
annevk: should non-navigations that get respondWith(Response.redirect(url)) trigger service worker interception again?

[15:55:13.0000] <wanderview>
I think so, but would like confirmation


2015-11-21
[17:20:51.0000] <wanderview>
annevk: actually... what I really need to know now is if a navigate gets skip-service-worker set because the SW passed on doing anything, do further redirects skip the service worker?  Its unclear to me if http spec creates new requests for the navigate or continues with the current-marked-as-skipped Request

[17:31:35.0000] <wanderview>
I think the skip-service-worker flag should remain...

[17:31:38.0000] <wanderview>
I wrote a chrome issue https://code.google.com/p/chromium/issues/detail?id=559447&thanks=559447&ts=1448069478

[17:32:28.0000] <wanderview>
JakeA: when you get a chance, can you triage that issue ^^^

[17:34:45.0000] <wanderview>
or tell me I'm wrong

[18:08:40.0000] <MikeSmith>
Domenic: should be working now

[18:08:48.0000] <Domenic>
MikeSmith: \o/ thanks!


2015-11-23
[23:58:22.0000] <annevk_>
wanderview: it seems like there might be some problem with how that skip-servicer-worker flag gets set by the SW specification

[03:48:46.0000] <annevk_>
philipj: rewriting DOM to not use "name" is a bit more involved than I thought, but getting there I think

[03:55:34.0000] <philipj>
annevk: sweet!

[04:05:22.0000] <annevk>
philipj: does look like it's worth it to keep a "qualified name" concept around that just computes to something

[04:06:03.0000] <annevk>
philipj: the current diff has quite a few prefix is null and name is local name or prefix + ":" + local name is name which is not great

[04:26:06.0000] <philipj>
annevk: Sure, having it as a concept sounds fine, and in fact matches Blink. Doing it the otherway would make it more explicit where there could be a wasteful string being created, but the spec shouldn't micro-optimize at the expense of readability

[04:26:46.0000] <annevk>
philipj: the only change I haven't made yet is rename various arguments to qualifiedName

[04:26:55.0000] <annevk>
philipj: that's probably worth doing too at some point

[04:27:27.0000] <philipj>
annevk: yeah, some kind of clarity about when it's possible to use a colon in the input and not would be nice

[04:27:30.0000] <philipj>
    if (!isHTMLElement() && attrNode->document().isHTMLDocument() && attrNode->name() != attrNode->name().lower())

[04:27:33.0000] <philipj>
        UseCounter::count(document(), UseCounter::NonHTMLElementSetAttributeNodeFromHTMLDocumentNameNotLowercase);

[04:27:36.0000] <philipj>
oops

[04:27:44.0000] <philipj>
that's some code I just removed and had in my clipboard :)

[04:28:22.0000] <philipj>
annevk: while I have you here, there's another issue, namely that setAttributeNode and setAttributeNodeNS are simply aliases in Blink, but not in the spec

[04:29:09.0000] <gsnedders>
philipj: what about createElement/createElementNS?

[04:29:28.0000] <annevk>
philipj: spec matches Gecko?

[04:29:30.0000] <philipj>
and when I try to align with the spec, I get a place where I potentially lowercast the localName of an Attr object

[04:29:35.0000] <philipj>
annevk: I think so, yes

[04:30:26.0000] <philipj>
gsnedders: those aren't aliases, thankfully :)

[04:30:52.0000] <philipj>
annevk: so it seems weird, to me, to lowercase an Attr's localName, because we're already normalizing case in createAttribute

[04:31:26.0000] <philipj>
annevk: so what would you think of simply using the namespaceURI and localName of the attr?

[04:31:26.0000] <annevk>
philipj: I think that's called out in the spec as a weird case we don't care about

[04:31:55.0000] <annevk>
philipj: hmm, open an issue and discuss with bz / Ms2ger?

[04:31:56.0000] <philipj>
it is called out, but that was added before createAttribute lowercased its input, right?

[04:32:09.0000] <annevk>
philipj: true

[04:32:15.0000] <philipj>
ok, so I'll file a spec issue

[05:49:55.0000] <gsnedders>
is there any reasonable way to track a specific section of the HTML spec?

[05:54:10.0000] <annevk>
gsnedders: not really

[06:10:17.0000] <rom1504>
hi, are whatwg streams usable in node yet ?

[07:09:02.0000] <jgraham>
gsnedders: I was just going to merge the travis update pr, especially if master is already failing tests

[07:11:18.0000] <gsnedders>
jgraham: I still want to keep us having linear history. The lxml breakage looks like a small change in ihatexml is needed

[07:12:03.0000] <jgraham>
OK, well if you're going to fix I'm not going to complain

[07:14:10.0000] <gsnedders>
it's a three line fix :)

[07:15:19.0000] <rom1504>
why isn't the up to date reference implementation there https://www.npmjs.com/package/whatwg-streams ?

[07:16:28.0000] <gsnedders>
rom1504: a) it isn't a reference implementation; b) the author AFAIK isn't here

[07:17:05.0000] <rom1504>
https://github.com/whatwg/streams/tree/master/reference-implementation is not a reference implementation ?

[07:18:20.0000] <rom1504>
my question is how can I use this https://github.com/whatwg/streams/tree/master/reference-implementation (and should I) ?

[07:18:58.0000] <annevk>
rom1504: maybe Domenic can help you out

[07:19:04.0000] <annevk>
not sure if he's around

[07:19:23.0000] <rom1504>
I have no idea whether this is supposed to work, but since this is unpublished and in a subdir, there's no way to use it from node

[07:19:58.0000] <rom1504>
I'll open an issue on the repo

[07:20:13.0000] <gsnedders>
jgraham: https://github.com/html5lib/html5lib-python/pull/214 look good to you?

[07:21:19.0000] <gsnedders>
jgraham: bah, still failing tests :\

[07:22:43.0000] <jgraham>
gsnedders: Well it looks like a reasonable change at least, but yeah since it alters the comment you can see that it might fail the tests

[07:23:27.0000] <gsnedders>
jgraham: coercion in principle shouldn't cause failing tests

[07:23:38.0000] <gsnedders>
jgraham: the real problem is lxml is still throwing

[07:23:57.0000] <jgraham>
Oh

[07:32:46.0000] <annevk>
philipj: thank you for the review, fixing now

[07:39:03.0000] <gsnedders>
jgraham: plz look at https://github.com/html5lib/html5lib-python/pull/214 again

[07:41:55.0000] <jgraham>
gsnedders: "contain end"

[07:42:29.0000] <gsnedders>
jgraham: blargh. apart from that?

[07:43:10.0000] <jgraham>
Do you still need the += " " if it's going to throw anyway?

[07:44:33.0000] <gsnedders>
jgraham: it doesn't throw, it's a warning

[07:44:51.0000] <gsnedders>
jgraham: see everything else in ihatexml

[07:47:00.0000] <jgraham>
Right, I guess that makes sense

[07:47:04.0000] <jgraham>
Anyway r+

[07:48:59.0000] <gsnedders>
jgraham: basically we ignore test results if datalosswarning is raised

[07:50:47.0000] <jgraham>
gsnedders: Yeah, I remember that part

[08:38:16.0000] <gsnedders>
https://github.com/html5lib/html5lib-tests/pull/71#issuecomment-158989019 if anyone can remember about how the list of character references was derived

[08:44:53.0000] <annevk>
gsnedders: it's part of the build script https://github.com/whatwg/html-build

[08:45:03.0000] <gsnedders>
annevk: that's what I thought

[08:45:21.0000] <gsnedders>
annevk: which is odd, given it means the two things are divergent despite being based on the same source data

[09:49:50.0000] <annevk>
gsnedders: yeah not sure what is going on

[09:49:57.0000] <annevk>
:/


2015-11-24
[01:19:53.0000] <annevk>
philipj: does it matter what order I fix the attributeNode issues in?

[01:20:02.0000] <annevk>
philipj: seems relatively straightforward to fix the alias one

[01:24:11.0000] <philipj>
annevk: no, the order doesn't matter to me, but when I make the change in Blink I'd like to have a good sense that the spec, Blink and Gecko have precisely the same behavior as a goal

[01:24:19.0000] <philipj>
Which is looking pretty hopeful right now.

[01:24:55.0000] <annevk>
philipj: I thought we were aligning the spec with Blink?

[01:25:06.0000] <annevk>
philipj: oh, the other bits

[01:25:12.0000] <annevk>
makes sense

[01:25:14.0000] <philipj>
annevk: sorry, by order I mean the order of fixing issues :)

[01:46:54.0000] <Ms2ger>
philipj, and tests? :)

[01:48:45.0000] <philipj>
Ms2ger: for this attribute mess I was actually thinking I'd to it web-platform-tests style, yeah

[02:07:33.0000] <Ms2ger>
annevk, did location/workerlocation ever have searchparams?

[02:08:09.0000] <annevk>
Ms2ger: not sure about WorkerLocation, but yes

[02:08:19.0000] <annevk>
Ms2ger: it's a security hole though

[02:08:42.0000] <Ms2ger>
All the more reason to add a test it's not supported, then :)

[02:29:00.0000] <Ms2ger>
annevk, r? https://github.com/w3c/web-platform-tests/pull/2371

[02:30:24.0000] <annevk>
Ms2ger: worker.js is a convention for worker-only tests?

[02:31:09.0000] <Ms2ger>
annevk, a bit more than that; it automatically sets up the main-thread side

[02:31:36.0000] <Ms2ger>
Like http://w3c-test.org/XMLHttpRequest/XMLHttpRequest-withCredentials.worker

[02:32:33.0000] <annevk>
Ms2ger: neat

[02:32:38.0000] <annevk>
Ms2ger: r+

[02:33:00.0000] <annevk>
Ms2ger: is there a bug on the directory listing not supporting this feature?

[02:33:17.0000] <Ms2ger>
I don't think so

[02:33:20.0000] <Ms2ger>
I'll file that

[02:33:24.0000] <annevk>
thank you

[02:35:56.0000] <annevk>
yoav: any ETA on https://github.com/whatwg/dom/pull/114?

[02:36:14.0000] <annevk>
yoav: it's not a big deal since I assume all implementers are still aware, but it might become one

[02:37:37.0000] <Ms2ger>
https://github.com/w3c/wpt-tools/issues/42

[02:37:39.0000] <yoav>
annevk: I was under the impression that it's still under active discussion regarding the best return values

[02:38:14.0000] <yoav>
but maybe I haven't throughly checked the latest news on that thread (been offline during WE and yesterday)

[02:38:33.0000] <yoav>
I'll go over all replies later today and align the PR accordingly

[02:46:25.0000] <zcorpan>
annevk: why is searchParams a security hole on location?

[02:49:26.0000] <annevk>
zcorpan: because Location can be seen cross-origin to some extent

[02:49:34.0000] <annevk>
zcorpan: and is all kinds of complicated

[02:49:44.0000] <annevk>
yoav: I see

[02:49:47.0000] <annevk>
yoav: ta

[02:51:26.0000] <annevk>
philipj: I don't understand your comment in https://github.com/whatwg/dom/issues/115 about losing order

[02:54:12.0000] <annevk>
zcorpan: https://github.com/annevk/html-cross-origin-objects/ has some notes on defining Location more accurately

[02:55:55.0000] <zcorpan>
annevk: so the problem is that it's an object and we don't want to figure out how to support it in a secure way, because location is complicated enough already?

[02:59:48.0000] <annevk>
zcorpan: it would basically amount to introducing a new kind of URLSearchParams that is safe

[03:00:08.0000] <philipj>
annevk: commented again, does it make sense now?

[03:00:42.0000] <annevk>
zcorpan: at which point it seems better to just require var loc = new URL(location); /* manipulation here */ location = loc to do some manipulation

[03:01:29.0000] <zcorpan>
annevk: ok. thx

[03:01:34.0000] <annevk>
philipj: it seems with the getAttributeNamesNS API you wouldn't lose that, right?

[03:03:03.0000] <philipj>
annevk: oh, you mean that would return *all* the attributes?

[03:03:11.0000] <philipj>
I assumed you would split them into two buckets

[03:04:08.0000] <annevk>
philipj: the first would return all the qualified names

[03:04:19.0000] <annevk>
philipj: but yes, both would return all

[03:04:30.0000] <annevk>
philipj: just like setAttribute / setAttributeNS also both operate on all

[03:05:54.0000] <zcorpan>
can't the implementation avoid creating the Attrs if you only access the .name? or is that kind of lazy creation super-hard for some reason?

[03:11:20.0000] <annevk>
Try to implement it in JavaScript and see how easy it is? :-) I'm sure that kind of thing can be done, the question I guess is how much complexity should we put in the engine when we can expose something that wasn't really well-exposed thus far that would avoid doing all that...

[03:21:58.0000] <zcorpan>
annevk: i wouldn't be surprised if Presto does something like this

[03:22:54.0000] <Ms2ger>
zcorpan, what would you access the name on, then?

[03:24:09.0000] <Ms2ger>
Or do you mean var name = element.attributes[0].name; would magically collapse to fetching the name from somewhere else, or something?

[03:24:26.0000] <zcorpan>
Ms2ger: magic? proxy something? i dunno

[03:24:56.0000] <Ms2ger>
Sounds hard in SpiderMonkey, at least

[03:25:09.0000] <zcorpan>
ok

[06:46:20.0000] <gsnedders>
Why are we using a bash file instead of a Makefile for the building stuff?

[06:48:36.0000] <jgraham>
Wow, talk about out of the frying pan and into the fire

[06:50:02.0000] <jgraham>
Although the answer seems to be "becase that's what Hixie did"

[07:04:34.0000] <gsnedders>
:)

[07:04:39.0000] <gsnedders>
That's what I thought.

[07:05:09.0000] <gsnedders>
There's just so many comments like "We need to check if x file has changed before we avoid doing this". Which is, well, what Make is great at.

[07:19:38.0000] <MikeSmith>
it's great for saving time if the compile times are significant

[07:19:47.0000] <MikeSmith>
which they're not in our case

[07:20:12.0000] <MikeSmith>
so IMHO it'd be overkill to change it now

[07:21:07.0000] <MikeSmith>
though that said, myself I would have written it as a makefile to begin with

[07:21:45.0000] <MikeSmith>
I guess one argument is that it's easy to write a makfile that's not portable

[07:22:02.0000] <MikeSmith>
or that at least will break on windows/dos

[07:22:32.0000] <MikeSmith>
I mean, easy to accidentally write one that won't work on windows

[07:22:49.0000] <MikeSmith>
or won't work without GNU make

[07:23:16.0000] <Ms2ger>
As opposed to bash? :)

[07:23:29.0000] <MikeSmith>
yeah, good point

[07:23:29.0000] <jgraham>
It's also easy to write a write-only makefile

[07:23:31.0000] <MikeSmith>
fair enough

[07:23:45.0000] <MikeSmith>
jgraham: true that too

[07:24:46.0000] <MikeSmith>
anyway, ain't broke don't fix it and all that

[07:25:36.0000] <gsnedders>
aye

[07:25:44.0000] <MikeSmith>
at least we're not at maven vs gradle vs sbt

[07:26:12.0000] <gsnedders>
I do want to reach to a point where you can checkout the spec at a given revision and get the spec at that revision. With so many external deps, it can be hard to tell when things actually changed

[07:26:36.0000] <gsnedders>
I don't really care about the caniuse and bugzilla stuff, I only mean the normative content

[07:34:54.0000] <Ms2ger>
Pretty sure the html spec doesn't do reproducible builds

[07:35:02.0000] <Ms2ger>
Neither does any other spec, of course

[07:35:12.0000] <Ms2ger>
Maybe WebIDL

[07:39:10.0000] <gsnedders>
only because of xspec xref though, right?

[07:41:24.0000] <Ms2ger>
Also bikeshed/anolis/... versions

[07:41:52.0000] <Ms2ger>
And obviously the datestamp, but let's ignore that

[07:42:28.0000] <gsnedders>
really the build tools don't change enough for that to really be relevant, IMO

[13:15:36.0000] <Krinkle>
JakeA: Any chance https://code.google.com/p/chromium/issues/detail?id=393466 could get a little push? it'd be nice to drop the user-agent sniffing based polyfill we have for it now.

[14:15:37.0000] <Domenic>
Krinkle: might have better luck in Mozilla IRC #accessibility; I hear that is where a11y browser engineers hang out

[14:21:59.0000] <Krinkle>
Domenic: OK. Note though that despite its name, accesskeys are imho not an accessibility feature. More a power user feature. At least on Wikipedia it's historically been a feature much used, and never with javascript.

[14:25:44.0000] <tantek>
yeah that sounds about right

[14:34:09.0000] <Domenic>
Krinkle: sounds like a feature that will not be prioritized by a browser that is focused on mobile...

[14:35:14.0000] <Krinkle>
It should be a simple patch though. And it's part of the DOM spec. These kind of random gaps make it suck to develop for the web.

[14:37:23.0000] <Krinkle>
or maybe we should remove it from the spec. But this cycle of things being added to the spec, one browser implementing it, and then usually years of silence and uncertainty of whether the rest is going to follow is just weird from an outsider perspective. This feature in particular is probably "old enough" that it "would be done differently" if it were

[14:37:23.0000] <Krinkle>
proposed today, but I really hope there is some kind of process by which vendors are involved earlier so that there's more ability to optimise for the future.

[14:41:25.0000] <Domenic>
Krinkle: ever considered contributing to Chrome? :)

[14:42:24.0000] <Krinkle>
I have. But I simply don't have the capacity to add that. I'm already working a full time job with lots of open-source activity outside of that.


2015-11-25
[19:13:39.0000] <JonathanNeal>
Can anyone show me an example of traditional typographical shorthand notation where a slash is used to separate the font size and line height?

[19:26:09.0000] <JonathanNeal>
> The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts. — http://www.w3.org/TR/css3-fonts/#font-prop

[19:32:45.0000] <boogyman>
JonathanNeal: I don't know that it specifically relates to the optical size / line-height relationship, but rather the means of defining multiple characteristics

[19:46:03.0000] <JonathanNeal>
@boogyman, would you know why that syntax was used then, over say, spaces?

[19:49:08.0000] <boogyman>
I can speculate that since those are the two "numeric" characteristics, it was easiest to describe using the non-standard delimiter. eg, the other characteristics don't really overlap at all

[20:12:18.0000] <astearns>
JonathanNeal: I have seen 10/12 etc. notation for size/leading, usually in books on pre-desktop-publishing usage

[00:18:29.0000] <annevk>
"I presume, then, you have a W3C approved, feature-complete alternative implementation to SMIL with solid reasons for deprecating the specification."

[00:52:28.0000] <MikeSmith>
"I'm simply not confident you have the chops to lead the way in the area of web development standards."

[00:59:09.0000] <philipj>
What are you quoting from? :)

[01:02:15.0000] <annevk>
blink-dev <3

[01:03:14.0000] <annevk>
I hadn't really read past the initial bit of the email, but it's a real gem

[01:03:23.0000] <annevk>
"SVG is the only really capable image format that offers superb scalability and flexibility inside the XHTML framework."

[01:04:10.0000] <annevk>
"I'm coming to a place where I don't care if Web & CSS animations will walk my dog and cook my breakfast."

[01:11:18.0000] <roc>
who?

[01:21:28.0000] <annevk>
roc: I don't know who this person is, it's just the last email in the SMIL deprecation thread on blink-dev

[02:13:54.0000] <nox>
annevk: I don't usually care about tone, but wow.

[02:29:20.0000] <jochen__>
annevk: does fetch talk about 3xx redirects at all?

[02:29:26.0000] <annevk>
jochen__: yes

[02:29:52.0000] <annevk>
jochen__: https://fetch.spec.whatwg.org/#http-fetch step 5

[02:31:08.0000] <jgraham>
nox: People like that are an occupational hazard of working on web standards

[02:32:19.0000] <nox>
jgraham: I don't even comprehend why he would mention that the deprecation is bad because Blink is FOSS.

[02:33:33.0000] <nox>
"As an aside but wholly related, here's a gem in the form of a significant SMIL bug report dating back to 2011 that still hasn't been fixed. Given this and what I consider an ill-considered  deprication announcement I'm simply not confident you have the chops to lead the way in the area of web development standards." What.

[02:33:42.0000] <nox>
Oh MikeSmith had pasted that part, never mind.

[02:58:00.0000] <jochen__>
annevk, maybe I'm blind that step 5 already doesn't tell what to do with the referrer, no?

[02:58:31.0000] <annevk>
jochen__: yeah, we probably need to update that somehow

[02:58:39.0000] <annevk>
jochen__: if redirects affect the referrer

[02:58:48.0000] <annevk>
jochen__: which I guess they do

[02:59:07.0000] <annevk>
jochen__: seems like something that's not well defined at the moment

[02:59:35.0000] <jochen__>
at least not in fetch

[02:59:43.0000] <jochen__>
i'm pretty sure that http says what to do on downgrade

[03:03:10.0000] <annevk>
https://tools.ietf.org/html/rfc7231#section-5.5.2 doesn't say much

[03:04:37.0000] <jgraham>
nox: Logical arguments aren't a strong feature of the "you're all inept and shouldn't be allowed to do this work" rants

[03:12:14.0000] <annevk>
mkwst: any ideas on how to move https://github.com/whatwg/html/pull/323 forward?

[04:41:50.0000] <zcorpan>
it's annoying that github issue referencing doesn't work when it's in the PR title

[04:56:57.0000] <nox>
If only that was the only annoying thing.

[04:58:53.0000] <MikeSmith>
amen

[05:06:31.0000] <jochen__>
annevk, ship it and see what explodes?

[05:06:47.0000] <annevk>
jochen__: :-)

[05:07:30.0000] <annevk>
jochen__: try shipping something where A can only navigate B if A is B

[05:11:29.0000] <zcorpan>
jgraham: is it known that files with spaces in the file name get 404ed by wpt-serve?

[05:27:00.0000] <zcorpan>
/me looks at https://github.com/w3c/wptserve/blob/master/wptserve/handlers.py but can't see anything obvious to fix

[05:34:46.0000] <yoav_>
annevk: comments on not rejecting invalid values as per https://github.com/whatwg/dom/pull/114#issuecomment-159568709 ?

[05:36:54.0000] <annevk>
yoav: not really, having a bit of a hard time seeing what an ideal API might be here given the constraints

[05:38:11.0000] <yoav>
OK

[06:01:53.0000] <zcorpan>
jgraham: filed https://github.com/w3c/wptserve/issues/69

[06:04:07.0000] <zcorpan>
yoav: i suppose all-truthy strings is OK since code is going to care about legacy clients, and strings makes it more self-documenting than mystery falsy values

[06:05:01.0000] <yoav>
zcorpan: OK, so now the main question is whether invalid values should be rejected?

[06:06:38.0000] <zcorpan>
yoav: yeah. it was Domenic who wanted that, mostly?

[06:08:18.0000] <Domenic>
I still think it would be nice. If we're not going to do a solution that tries to sync what's actually added with what's supported, then we should just go with relList.supportedValues = ["foo", "bar", "baz", ...] or relList.supports("foo"), and accept that spec authors will have to be careful to synchronize supportedValues with reality.

[06:09:59.0000] <zcorpan>
relList.supports('foo') would be OK with me. we can write wpt tests that check that the claim matches the actual support

[06:10:14.0000] <Domenic>
does it return a boolean or an enum?

[06:10:48.0000] <zcorpan>
boolean. it doesn't have the problem that add() has because supports() doesn't exist today

[06:11:17.0000] <zcorpan>
hmm wait

[06:11:28.0000] <zcorpan>
there was this other case also

[06:11:50.0000] <zcorpan>
<a>.relList or other going from n/a to having a set of supported keywords

[06:12:04.0000] <Domenic>
I don't really understand how that's ever going to make sense

[06:12:41.0000] <Domenic>
If it's going to have a set of supported keywords we should do that now

[06:12:56.0000] <Domenic>
But I don't see why it ever would

[06:13:30.0000] <zcorpan>
to check for <a rel=noopener>?

[06:13:50.0000] <Domenic>
Then we should define the set of supported keywords for <a rel> now

[06:13:56.0000] <zcorpan>
yes, we should

[06:14:18.0000] <Domenic>
Then we can go back to .add :P. (Or supports I guess, whatever.)

[06:14:55.0000] <Domenic>
Next question: does "supports" mean "is specified" or does it mean "has some affect on browser processing"

[06:14:57.0000] <zcorpan>
and does classList.supports() exist at all, and if it does, what does it return?

[06:15:13.0000] <zcorpan>
the latter

[06:15:16.0000] <Domenic>
e.g., what does a.relList.supports("tag") return

[06:15:22.0000] <Domenic>
OK so a.relList.supports("tag") is false

[06:15:33.0000] <Domenic>
I think classList.supports("anything without a NUL byte") is true

[06:16:07.0000] <zcorpan>
right (re "tag")

[06:16:31.0000] <zcorpan>
why? (and why "anything without a NUL byte"?)

[06:17:03.0000] <Domenic>
because the browser now includes the class name you added in the list of things CSS selectors match, and because http://stackoverflow.com/a/6732899/3191

[06:18:04.0000] <Domenic>
although clicking through that StackOverflow answer to the spec I can't find the NUL byte clause

[06:18:57.0000] <zcorpan>
having a DOM API be affected of css syntax seems a bit weird

[06:19:30.0000] <zcorpan>
you can use class without using css

[06:20:04.0000] <Domenic>
Is it weirder than having a DOM API be affected by the preload spec?

[06:20:50.0000] <zcorpan>
i don't know what that is referring to

[06:21:01.0000] <zcorpan>
but maybe besides the point :-)

[06:21:18.0000] <Domenic>
a.relList.supports("preload") is determined by the fact that the preload spec says "preload" rel has normative impact

[06:21:27.0000] <Domenic>
despite .supports() being a DOM API

[06:22:19.0000] <Domenic>
Let me summarize this on the issue tracker... where's the latest place...

[06:22:53.0000] <zcorpan>
ok, sure, but classes don't do anything on their own, so they're not "supported" in that sense. unless we had classes with default styling, maybe

[06:25:29.0000] <zcorpan>
there isn't a use case for supports() on classList, it just gets the API by accident because it's also a DOMTokenList

[06:25:39.0000] <zcorpan>
maybe we should have a new interface

[06:46:55.0000] <annevk>
Domenic: zcorpan: note that two classes means four classes due to DOMSettableTokenList

[06:48:02.0000] <zcorpan>
yeah

[06:48:14.0000] <zcorpan>
except we might only need 3

[06:49:31.0000] <annevk>
zcorpan: HTML has been patched for both DOMTokenList and DOMSettableTokenList users to add a concept of supported tokens

[06:49:57.0000] <Domenic>
... why *isn't* classList a DOMSettableTokenList

[06:50:25.0000] <annevk>
Domenic: I think because className exists

[06:50:30.0000] <Domenic>
Why isn't everything a DOMSettableTokenList

[06:50:39.0000] <Domenic>
Stupid /topic

[06:50:50.0000] <annevk>
We might be able to do that...

[06:51:07.0000] <zcorpan>
annevk: yes. but there's no DOMSettableTokenList other than <iframe sandbox>, is there?

[06:51:40.0000] <annevk>
zcorpan: maybe not with supported values

[06:52:03.0000] <annevk>
zcorpan: but there's <a>.ping and <link>.sizes

[06:52:53.0000] <Domenic>
It would be nice to rationalize everything to [PutForwards=appropriateProperty] DOMSettableTokenList

[06:52:54.0000] <zcorpan>
oh ok yeah. and dropzone

[06:53:06.0000] <Domenic>
Then we could teach new web developers classList and never teach them className

[06:53:20.0000] <Domenic>
I guess [PutForwards] isn't that great of a behavior to teach

[06:54:10.0000] <Domenic>
Still, the fact that we have so many different patterns for this same idiom is weird

[06:54:55.0000] <zcorpan>
switching to [PutForwards] and DOMSettableTokenList everywhere seems good

[06:56:52.0000] <annevk>
Is it only HTML that uses DOMTokenList?

[06:59:18.0000] <Domenic>
annevk: yes in Blink; where's Gecko's codesearch again? https://code.google.com/p/chromium/codesearch#search/&q=DOMTokenList%20file:%5C.idl&sq=package:chromium&type=cs

[06:59:43.0000] <Domenic>
Wait lol Blink doesn't even use DOMTokenList anywhere

[07:00:12.0000] <Domenic>
Except as a base class for DOMSettableTokenList

[07:01:55.0000] <Ms2ger>
Domenic, mxr.mozilla.org

[07:03:05.0000] <Domenic>
Oh Blink has classList at least nevermind

[07:03:37.0000] <Domenic>
But yeah seems like's yes for Gecko as well https://mxr.mozilla.org/mozilla-central/search?string=DOMTokenList&find=.idl

[07:05:27.0000] <annevk>
Domenic: I'll file an issue suggesting this simplification and then we can see what folks say

[07:08:15.0000] <annevk>
https://github.com/whatwg/dom/issues/119

[07:10:07.0000] <annevk>
https://github.com/whatwg/html/issues/358

[07:54:47.0000] <zcorpan>
The HTML Working Group has published a W3C Recommendation of W3C DOM4.

[07:56:04.0000] <Domenic>
I guess the good part is that it'll become increasingly obvious what a joke it is given all the changes since the last snapshot.

[07:57:25.0000] <Ms2ger>
Domenic, changes? Why? The W3C has declared everything in DOM4 is implemented perfectly interoperably!

[07:57:41.0000] <zcorpan>
ok so can we fix Document vs HTMLDocument already?

[07:58:23.0000] <Domenic>
Document vs HTMLDocument seems like Attr as a Node... someone needs to try the current spec, nobody but Servo is brave enough to d oso

[07:58:27.0000] <annevk>
zcorpan: can you?

[07:59:09.0000] <annevk>
zcorpan: even if we are to admit defeat, defining the appropriate Document object for each context and then what properties each must expose is quite a big undertaking

[07:59:45.0000] <Ms2ger>
Is there a new reason to give up?

[07:59:57.0000] <zcorpan>
i meant fix as in implement what is specced now

[08:00:25.0000] <zcorpan>
i can't do it because i'm not a browser dev :-]

[08:02:05.0000] <Domenic>
jsdom is working on it!

[08:08:56.0000] <gsnedders>
zcorpan: become a browser dev!

[08:13:29.0000] <gsnedders>
jgraham: can you prod https://github.com/html5lib/html5lib-python/pull/198 such that Critic realises it exists and creates a review for it?

[08:14:36.0000] <gsnedders>
jgraham: also opinions welcome on whether it's worthwhile rewriting the history even more

[09:05:48.0000] <annevk>
Domenic: JakeA: https://twitter.com/phuunet/status/669515142057598976

[09:06:09.0000] <annevk>
/me yawns

[09:06:52.0000] <annevk>
MikeSmith: http://www.publickey1.jp/blog/15/html5whatwgw3c_tpac_2015.html is quite popular on Twitter, anything noteworthy?

[09:09:34.0000] <JakeA>
*sigh*

[09:14:00.0000] <Domenic>
Replied

[09:15:42.0000] <Domenic>
Google translate says that WHATWG is mostly mentioned in their "future of HTML" section

[09:16:54.0000] <zcorpan>
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2015%2FREC-dom-20151119%2F&doc2=https%3A%2F%2Fdom.spec.whatwg.org%2F

[10:30:15.0000] <zcorpan>
annevk: see https://code.google.com/p/chromium/issues/detail?id=324922#c6 for why i dislike quirks mode test cases :-)

[10:41:48.0000] <JonathanNeal>
Anyone here good at math? I am trying to calculate things like cover and contain in JavaScript.

[10:58:53.0000] <boogyman>
JonathanNeal: did you get a more authoritative opinion to your question about font shorthand notation?

[10:59:23.0000] <JonathanNeal>
boogyman, yes. You can read the thread here: https://twitter.com/tabatkins/status/669384360903073792

[11:00:56.0000] <boogyman>
ah, so I wasn't too far off

[11:01:03.0000] <boogyman>
good to know, thanks.

[11:10:52.0000] <JonathanNeal>
I used to know how to do the math. Something about getting the aspect ratios, min/max, produce result.

[11:33:49.0000] <zcorpan>
JonathanNeal: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3766 ? (the centering can probably be done in better ways, and maybe the other thing also)

[11:52:59.0000] <JonathanNeal>
zcorpan: thanks, I’ll review that.

[12:04:06.0000] <smaug____>
is there some "process" to backout spec changes

[12:04:41.0000] <smaug____>
I mean in those cases when a change was either clearly wrong or controversial, it probably should be backed out sooner than later

[12:05:49.0000] <Domenic>
No process, what do you think this is :P. Submit a PR or open an issue requesting an editor does it?

[12:08:20.0000] <smaug____>
I was kind of hoping some nice tool where one could easily backout changes :)

[12:08:28.0000] <smaug____>
not sure who should have rights to use such tool

[12:09:32.0000] <smaug____>
(tokenlist.add changes just came to my mind)

[12:10:05.0000] <Domenic>
Yeah, I mean, `git revert` is a pretty good approximation of that tool

[12:17:48.0000] <gsnedders>
jgraham: so yeah, I want to html5lib-python#198 asap given it allows us to get up-to-date with tests with no failures

[12:18:03.0000] <smaug____>
"navigation context" isn't any real spec thing, right?

[12:18:19.0000] <smaug____>
/me tries to understand web perf wg specs

[12:19:27.0000] <gsnedders>
smaug____: I've certainly never heard of it!

[12:19:54.0000] <smaug____>
bah, how does one change github issue title?

[12:20:19.0000] <gsnedders>
press the edit button to the left of it?

[12:20:34.0000] <smaug____>
doesn't work

[12:20:45.0000] <gsnedders>
hmm, wfm


2015-11-26
[16:23:34.0000] <MikeSmith>
annevk, Domenic so, one interesting part of http://www.publickey1.jp/blog/15/html5whatwgw3c_tpac_2015.html is that it translates the statement Travis made at the TPAC Future of HTML session where he said that the Edge team references/refers to the WHATWG HTML spec when doing their work

[16:23:59.0000] <MikeSmith>
but it also says a bit more than what was actually minuted there

[16:24:30.0000] <MikeSmith>
it actually also says, "...so, the Edge team wishes the WHATWG had a patent policy"

[16:25:03.0000] <Domenic>
*very* interesting

[16:26:04.0000] <MikeSmith>
incidentally, just prior to all that, it mentions that there is a WHATWG CG but that it's not active, so therefore Microsoft isn't participating in it

[16:28:44.0000] <jgraham>
I'm pretty sure Travis did say that, even though it's not minuted, FWIW

[16:28:56.0000] <MikeSmith>
ok

[16:29:19.0000] <MikeSmith>
yeah Niino-san probably took very detailed notes

[16:29:36.0000] <MikeSmith>
he'ss a very careful guy

[16:29:48.0000] <MikeSmith>
(they guy who wrote that)

[16:30:18.0000] <MikeSmith>
and he's very widely read by a lot of people in the tech world here in Japan

[16:30:56.0000] <jgraham>
I particularly like Google translate rendering what I assume is "unconference format" as "Anne conference format"

[16:31:20.0000] <MikeSmith>
haha

[16:31:48.0000] <MikeSmith>
Google Translate is near totally worthless for translating Japanese

[16:31:52.0000] <MikeSmith>
in my experience

[16:32:04.0000] <MikeSmith>
anyway, just after that part it says, "So, because of the patent-policy issue and also because the WHATWG doesn't follow a consensus process, work on HTML at the W3C will continue

[16:32:30.0000] <jgraham>
Well… comapred to it being totally unintelligible, this is better. Obviously less good than actually understanding the Japanese though

[16:33:17.0000] <MikeSmith>
yeah

[16:33:35.0000] <MikeSmith>
so the next-to-last part mentions modularization and also says that some parts of the HTML spec that aren't needed can be dropped

[16:34:16.0000] <MikeSmith>
oh

[16:35:44.0000] <MikeSmith>
actually it doesn't say "some parts of the HTML spec that aren't needed" but more precisely it says, "some parts of HTML that don't need to be maintained"

[16:36:39.0000] <MikeSmith>
anyway, I guess by far the most interesting bit of the whole thing is that part that says "the Edge team wishes the WHATWG had a patent policy"

[16:39:41.0000] <jv_>
Just read HTML5 by Jeremy Keith and this IRC was referenced in the back of the book. Greetings.

[16:40:00.0000] <boogyman>
jv_: welcome

[16:40:47.0000] <MikeSmith>
jv_: howdy

[16:41:11.0000] <MikeSmith>
pretty cool that the channel is feature on a book cover

[16:41:20.0000] <MikeSmith>
even if it's just the back cover

[16:41:25.0000] <MikeSmith>
Jeremy++

[00:34:31.0000] <annevk>
/me wonders where smaug does not have sufficient access to GitHub stuff

[00:35:13.0000] <annevk>
MikeSmith: that is a pretty interesting read

[00:35:28.0000] <annevk>
MikeSmith: guess I left that session just when things got interesting

[00:36:03.0000] <annevk>
MikeSmith: the first thirty or so minutes were just a lot of words for "uhm, what should we do"

[00:36:46.0000] <annevk>
Which as someone pointed out to me, isn't that different from how those sessions have been going for the past decade or so

[00:58:32.0000] <yoav_>
annevk: Do you think we should wait on https://github.com/whatwg/dom/issues/119 in order to move forward with the feature detection outlines in https://github.com/whatwg/dom/pull/114 ?

[00:58:40.0000] <annevk>
yoav_: nah

[00:58:48.0000] <yoav_>
cool, that's what I thought

[00:59:54.0000] <yoav_>
I'll prepare a separate PR with `supported()`

[01:02:23.0000] <zcorpan>
have we decided on A vs B vs C?

[01:04:02.0000] <zcorpan>
i think i prefer A because it leaves classList alone and makes it obvious how to feature-check for something moving from like-classList to like-relList

[01:05:16.0000] <zcorpan>
i can take a stab at merging the DOMTokenLists

[01:06:40.0000] <yoav_>
zcorpan: I have no particular preference there, as I don't think it will make much of a difference

[01:07:07.0000] <yoav_>
It's something that developers shouldn't do, as it tell them nothing

[01:16:23.0000] <yoav>
zcorpan: how are mutual DOM/HTML spec changes done?

[01:17:43.0000] <zcorpan>
yoav: PR both i guess?

[01:17:59.0000] <yoav>
OK

[01:20:54.0000] <zcorpan>
in httparchive i only see http://www.gstatic.com/caja/5678/es53-taming-frame.opt.js?debug=1 containing "DOMSettableTokenList.prototype" but it was actually "TameDOMSettableTokenList.prototype"

[01:26:57.0000] <yoav>
so, it should be safe to simply add `value` to DOMTokenList?

[01:27:31.0000] <yoav>
zcorpan: or should we keep the prototype around?

[01:29:12.0000] <zcorpan>
i think we don't need DOMSettableTokenList around. but there is a possibility of course that pages set prototype.value on DOMTokenList and assume it does not affect DOMSettableTokenList. unlikely though

[01:29:37.0000] <yoav>
yeah, I agree that it's unlikely

[01:32:01.0000] <zcorpan>
all i can find is classList polyfills

[01:37:06.0000] <zcorpan>
annevk: "Yes, the names {{DOMTokenList}} and {{DOMSettableTokenList}}are unfortunate legacy mishaps." does this note still apply if they are merged?

[01:50:26.0000] <annevk>
zcorpan: yes

[01:50:51.0000] <annevk>
zcorpan: they're ordered sets, lists can contain duplicates

[01:51:24.0000] <zcorpan>
ok, it wasn't clear to me what the note was referring to

[01:52:59.0000] <zcorpan>
hmm my bikeshed isn't curling the ' in <var>options</var>'

[01:53:28.0000] <annevk>
zcorpan: update?

[01:54:34.0000] <zcorpan>
annevk: yeah just did. looks like it fixed it

[02:05:50.0000] <annevk>
zcorpan: ta

[02:22:58.0000] <zcorpan>
yoav: ok i've PR-ed dom and html now

[03:11:46.0000] <yoav>
zcorpan: cool!

[04:22:54.0000] <nox>
annevk: Is it well-known that replaceChild is badly-specified?

[04:23:31.0000] <philipj>
smaug____: with the removal of SVGSVGElement.currentView/useCurrentView, do you envision some other stuff also being ripped out, like #svgView(...)?

[04:23:40.0000] <philipj>
davve` is poking at this

[04:25:04.0000] <annevk>
nox: not to me

[04:25:23.0000] <nox>
annevk: if node == child, how do we remove child once node was adopted?

[04:26:57.0000] <smaug____>
philipj: hmm

[04:27:15.0000] <annevk>
nox: I guess it needs a non-null parent check, good find

[04:27:33.0000] <nox>
annevk: I think we can just adopt only if node != child.

[04:27:35.0000] <smaug____>
philipj: ask heycam?

[04:27:45.0000] <annevk>
nox: fair

[04:27:51.0000] <annevk>
nox: do you want to patch or shall I?

[04:28:19.0000] <nox>
annevk: Anyway, just tried that in Servo and WPT now timeouts even if I make a dummy test suite with 0 tests. :) Will look into it and make a patch in the end. :)

[04:28:28.0000] <nox>
/me is slowly driven insane by this.

[04:28:55.0000] <annevk>
nox: interesting

[04:29:02.0000] <annevk>
nox: (not the part about you going insane)

[04:29:14.0000] <nox>
annevk: Servo just doesn't mutate anything in the tree if node == child.

[04:29:34.0000] <nox>
It took me two days to realise that was why the range tests related to replaceChild were failing.

[04:29:47.0000] <nox>
So I remove that shortcut, and Servo now panics, trying to remove 'child' which doesn't have a parent anymore.

[04:29:52.0000] <smaug____>
curious, (I wasn't aware of https://wicg.github.io/BackgroundSync/spec/ so started to think this) is there some comprehensive test suite for service workers, or will we end up with very different kinds of service workers in different UAs when new features are being added

[04:30:04.0000] <nox>
So I conditionally adopt 'node' only if it is different than 'child', and now everything timeouts.

[04:30:06.0000] <nox>
/me cries.

[04:30:54.0000] <smaug____>
last time I tried to do something with SW it was hard because blink implemented features Foo from the spec and Gecko features Bar

[04:31:14.0000] <annevk>
smaug____: I think WPT has tests

[04:31:22.0000] <smaug____>
luckily the spec has some redundancy (duplicated stuff) and FooBar worked in my case

[04:31:45.0000] <annevk>
smaug____: btw, yesterday you mentioned not being able to edit the title on a GitHub issue, where did that happen? I might be able to give you the relevant permissions (if that is indeed the problem)

[04:32:19.0000] <annevk>
nox: :-(

[04:32:19.0000] <smaug____>
it was webperf, but I think it was some network issue

[04:32:34.0000] <smaug____>
I closed that bug and just opened a new one

[04:32:45.0000] <annevk>
Oh, don't really control that, MikeSmith can probably give you permissions there

[04:36:31.0000] <smaug____>
oh, now I recall, I should file yet another bug. Resource hints spec doesn't hint what dns-prefetch should actually do

[04:36:55.0000] <smaug____>
all it says "The dns-prefetch relation is used to indicate an origin"

[04:37:44.0000] <smaug____>
oh, hmm, maybe it is fine after all

[04:38:13.0000] <annevk>
I've been working with Ilya on getting some of Resource Hints better defined

[04:38:32.0000] <annevk>
Haven't really looked at everything, but e.g., preconnect now hooks into primitives in Fetch

[04:38:56.0000] <smaug____>
preconnect case does talk about DNS lookup

[04:39:05.0000] <smaug____>
but dns-prefetch doesn't

[04:40:09.0000] <annevk>
Oh yeah, the dns-prefetch definition is pretty vague

[04:40:44.0000] <annevk>
I wonder when you want to use dns-prefetch but not preconnect

[04:43:21.0000] <smaug____>
perhaps dns-prefetch more and earlier, and then preconnect when mouse is moved over some link or so

[04:49:49.0000] <MikeSmith>
smaug____: lemme know if I need to set you up with perms for something

[04:50:27.0000] <smaug____>
nah, it was probably me doing something silly

[04:50:42.0000] <MikeSmith>
k

[04:51:28.0000] <smaug____>
(or even more likely some network issues)

[07:24:58.0000] <nox>
annevk: http://logs.glob.uno/?c=mozilla%23servo#c307273 What do you think of this?

[07:25:26.0000] <nox>
annevk: Is that a spec bug, or an unfortunate thing we can't do anything about, and piggy-backing mutation observers to update childNodes was a bid idea?

[07:26:41.0000] <nox>
Mmmh wait, no never mind, that's still wrong.

[07:30:10.0000] <yoav>
annevk: Thoughts on https://github.com/w3c/preload/issues/37 ?

[08:00:11.0000] <annevk>
yoav: *sigh*

[08:00:50.0000] <annevk>
yoav: each time this thing comes up it takes me so long to wrap my head around all of it

[08:01:03.0000] <yoav>
I can relate :)

[08:01:49.0000] <annevk>
yoav: so "as" is parallel to "type" precisely because we don't want it to interfere with CSP

[08:02:12.0000] <annevk>
yoav: so I think CSP should just be connect-src

[08:02:40.0000] <annevk>
yoav: having said that, we should really define preload in terms of Fetch, including the preload store and such

[08:02:45.0000] <annevk>
yoav: has that already happened?

[08:02:47.0000] <yoav>
But then users need to define every domain/path twice

[08:02:56.0000] <annevk>
yoav: the last time I spoke with igrigorik that was the plan

[08:04:01.0000] <yoav>
I don't think that preload was already defined in terms of Fetch

[08:04:05.0000] <annevk>
yoav: okay, so if the preload store has a strong tie between the request url and the request type/as, perhaps you can use the "as" value for CSP

[08:04:30.0000] <annevk>
yoav: right, the plan was to define it in terms of Fetch, so it would be more clear what the various security properties would be and how we could keep things secure

[08:04:54.0000] <annevk>
nox: I'm going with "never mind", if you still want me to look, let me know!

[08:05:25.0000] <nox>
annevk: Never mind, but conditionally removing is wrong in replaceChild. The conditional operation if node != child should be the adoption.

[08:05:31.0000] <nox>
annevk: That's why my code crashed.

[08:05:55.0000] <annevk>
nox: okay, that's you suggested earlier today too, right?

[08:05:59.0000] <nox>
If you conditionally remove after adopting, mutation observers will see the original node being removed twice and added once. :)

[08:06:28.0000] <yoav>
annevk: I want to get mkwst's blessing, but I think setting the context based on type would be best, avoiding the user to redefine everything twice, while not creating CSP holes

[08:06:58.0000] <annevk>
yoav: for that the "preload store" needs to have a strong tie between things

[08:07:08.0000] <annevk>
yoav: I went over this with igrigorik a while back

[08:08:00.0000] <yoav>
annevk: OK. I think that the preload store is still in the "to be defined" stage

[08:09:38.0000] <annevk>
yoav: I summarized my position in the issue

[08:09:49.0000] <yoav>
annevk: Thanks! :)

[08:10:26.0000] <annevk>
nox: I'd appreciate a PR, but let me know if you want me to do it

[08:10:39.0000] <nox>
annevk: Will do.

[08:10:49.0000] <nox>
annevk: Too fixated on making my code work first. :)

[08:10:56.0000] <annevk>
fair

[08:24:43.0000] <Ms2ger>
Anyone know websockets?

[08:25:22.0000] <Ms2ger>
If a server sends malformed utf-8 in a text frame, what should the event's data attribute return?

[08:26:03.0000] <caitp>
s/malformed sequence/\uFFFD/?

[08:26:11.0000] <Ms2ger>
Eh

[08:26:15.0000] <Ms2ger>
/me files a wpt issue

[08:26:48.0000] <caitp>
i'm just guessing, I have no idea

[08:27:19.0000] <caitp>
I expect some implementations truncate the text, some replace with a ?, or \uFFFD, or something else?

[08:27:26.0000] <caitp>
never seen anyone really use it

[08:27:43.0000] <Ms2ger>
https://github.com/w3c/web-platform-tests/issues/2378

[08:28:56.0000] <smaug____>
https://tools.ietf.org/html/rfc6455#section-8.1

[08:30:59.0000] <smaug____>
Ms2ger: writing WebSocket impl for Servo?

[08:31:58.0000] <Ms2ger>
No, reviewing an API change in the library we use

[08:32:16.0000] <gsnedders>
line-height is the most stupidly defined CSS property ever <_<

[08:32:30.0000] <gsnedders>
(I realise I voice this on a near weekly basis. It keeps on biting.)

[08:35:00.0000] <smaug____>
igrigorik: do you have some good tools for testing Resource Hints implementations?

[11:43:48.0000] <smaug____>
anyone want to review a wpt testchange?

[11:43:53.0000] <smaug____>
MutationObserver stuff

[12:39:42.0000] <nox>
annevk: Mmmh. I still wonder whether it makes more sense to conditionally adopt `node` or to conditionally remove `child`. What do you think?

[12:40:28.0000] <nox>
If we conditionally adopt `node`, there should be a single mutation record queued, with addedNodes = removedNodes = [node].

[12:41:05.0000] <nox>
If we conditionally remove `child`, there should be two mutation records queued, the first with removedNodes = [node], the other with addedNodes = [child].

[12:42:48.0000] <annevk>
nox: what do implementations do?

[12:42:58.0000] <nox>
annevk: No clue.

[12:43:03.0000] <nox>
annevk: You're the expert. :P

[12:43:09.0000] <annevk>
nox: I'd probably write a test first

[12:43:15.0000] <annevk>
nox: but not now

[12:43:22.0000] <nox>
annevk: There are tests. :'(

[12:43:29.0000] <nox>
Well, for ranges.

[12:43:38.0000] <nox>
But there is a comment that makes me cry. Let me find it.

[12:44:25.0000] <annevk>
Hmm I gotta go, sorry, will look tomorrow

[13:09:57.0000] <nox>
annevk: Safari queues 0 records, Firefox 2, my patch 1.

[13:10:02.0000] <nox>
Sorry.

[13:13:24.0000] <caitp->
is that good or bad

[13:13:41.0000] <nox>
caitp-: Bad, I would say.

[13:14:07.0000] <caitp->
oh :(

[13:14:14.0000] <nox>
I think Safari returns early when replacing a child by itself (I wonder if it passes the related Range tests then).

[13:14:29.0000] <nox>
And Firefox queues a removal, and then a replacement of the removed thing by itself.

[13:14:39.0000] <nox>
So (you see the thing being removed twice.)

[13:14:48.0000] <nox>
I can't parenthesis.

[13:36:01.0000] <nox>
Chrome says 0 too. So that must be in WebKit.

[13:37:24.0000] <caitp->
i'm still not even sure what you're talking about

[13:45:46.0000] <nox>
caitp-: I'm talking about the behaviour of https://dom.spec.whatwg.org/#concept-node-replace with regard to the queued mutation records for all the mutations done by the algorithm.

[13:45:58.0000] <nox>
caitp-: That's for annevk's backlog. :)

[13:46:41.0000] <nox>
https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/ContainerNode.cpp#L399-L400 WebKit shortcuts everything if node == child, even the sanity check done the method, that definitely doesn't seem the way to go.

[13:47:00.0000] <caitp->
as usual, the answer is to do the wrong thing faster than anyone else

[13:50:59.0000] <nox>
caitp-: Ah ah.

[15:20:27.0000] <nox>
annevk: https://github.com/whatwg/dom/pull/121#issue-119109540


2015-11-27
[05:14:27.0000] <smaug____>
/me tries to understand https://github.com/whatwg/dom/pull/121

[05:15:35.0000] <smaug____>
is that just the case when both params point to the same node?

[05:16:48.0000] <Ms2ger>
I think so

[05:32:27.0000] <smaug____>
nox: ping

[05:32:38.0000] <nox>
smaug____: Pong.

[05:32:48.0000] <smaug____>
nox: do you have testcase for 2nd comment in https://github.com/whatwg/dom/pull/121

[05:32:53.0000] <smaug____>
trying to understand what it is about

[05:33:15.0000] <nox>
smaug____: There are already in the file I changed in the PR I linked.

[05:33:30.0000] <nox>
smaug____: Which case in particular would you like to see?

[05:33:49.0000] <smaug____>
like which mutationrecords you see in gecko

[05:34:04.0000] <nox>
For which case?

[05:34:14.0000] <nox>
Replacing a child by itself?

[05:34:41.0000] <smaug____>
you say in the comment " queuing 2 records in total."

[05:34:42.0000] <nox>
(removedNodes = [child]), (removedNodes = [child], addedNodes = [child]).

[05:34:57.0000] <smaug____>
and I'd like to understand in which case

[05:35:02.0000] <smaug____>
what is the testcase there

[05:35:09.0000] <nox>
In the case of replacing a child by itself.

[05:35:27.0000] <nox>
It's the test case I linked. My test case follows my spec change, so obviously Gecko fails it.

[05:35:48.0000] <nox>
In the case where child ≠ node, it queues:

[05:35:51.0000] <smaug____>
/me doesn't know where the link to testcase is

[05:35:57.0000] <nox>
(removedNodes = [node]), (removedNodes = [child], addedNodes = [node]).

[05:36:10.0000] <smaug____>
oh, down there is somelink

[05:36:14.0000] <nox>
smaug____: https://github.com/whatwg/dom/pull/121#issuecomment-160137419

[05:41:37.0000] <smaug____>
nox: ok, and you'd like to get rid of the first MutationRecord, right?

[05:41:43.0000] <smaug____>
/me can see a bug in Gecko there

[05:41:44.0000] <nox>
smaug____: Yes.

[05:41:49.0000] <nox>
smaug____: In the case where child = node.

[05:42:05.0000] <smaug____>
we don't remove anything there, but queue record

[05:42:14.0000] <nox>
That's not a bug.

[05:42:32.0000] <smaug____>
hmm

[05:42:34.0000] <nox>
Actually, what do you mean?

[05:42:35.0000] <smaug____>
wait, we do remove there

[05:42:36.0000] <smaug____>
nm

[05:42:38.0000] <smaug____>
let me read

[05:42:39.0000] <nox>
Do you mean that no mutation should happen?

[05:42:46.0000] <nox>
Because that would be wrong too. Cf. ranges.

[05:43:08.0000] <nox>
parent.replaceChild(child, child) should move any range that starts or ends in child.

[05:44:47.0000] <smaug____>
nox: I don't mean no mutation should happen

[05:44:56.0000] <nox>
smaug____: Ok. :)

[05:45:09.0000] <smaug____>
I'm trying to understand where we get removedNodes in (removedNodes = [child], addedNodes = [node]).

[05:45:34.0000] <nox>
smaug____: Completely unrelated, could you paste somewhere your PrototypeList.cpp file? You are a Gecko developer, right?

[05:45:40.0000] <smaug____>
actually, I would totally expect 2 records here

[05:45:48.0000] <smaug____>
but I don't understand why (removedNodes = [child], addedNodes = [node]).

[05:45:48.0000] <nox>
Trying to fix something in Servo and I don't want to build Gecko. :P

[05:46:02.0000] <smaug____>
PrototypeList...

[05:46:13.0000] <nox>
I don't understand what you mean. Which records do you expect for replacing a child by itself?

[05:46:14.0000] <smaug____>
just a sec

[05:46:34.0000] <nox>
(removedNodes = [child]) (addedNones = [child])?

[05:47:18.0000] <nox>
You remove `node` from its previous parent, and then you replace `child` by node. That's why you end up with a mutation record with both removedNodes and addedNodes.

[05:47:47.0000] <nox>
In the case where child = node, we either need to avoid the record about removing from the previous parent, or the removedNodes part in the second mutation record.

[05:48:07.0000] <nox>
And my opinion is that the former is cleaner.

[05:48:20.0000] <smaug____>
fun, gedit becomes non-responsive after opening PrototypeList.cpp with it

[05:48:24.0000] <nox>
smaug____: Ah ah. :)

[05:48:39.0000] <smaug____>
https://pastebin.mozilla.org/8853215

[05:49:37.0000] <nox>
smaug____: How come the namespaces are empty? :(

[05:49:44.0000] <nox>
(prototypes and constructors)

[05:50:07.0000] <smaug____>
nox: so, first you remove from a parent, so you get (removedNodes = [node]), and then you add, so you get (addedNodes = [node]) - that is what I'd expect at least now

[05:50:18.0000] <smaug____>
but why gecko gives (removedNodes = [child], addedNodes = [node] there

[05:50:28.0000] <smaug____>
looking...

[05:50:36.0000] <nox>
This isn't what I would expect at all.

[05:50:37.0000] <nox>
It's a replacing.

[05:51:02.0000] <nox>
smaug____: In the most basic case, replacing a node removes two elements and adds one.

[05:51:06.0000] <smaug____>
nox: those empty namespaces look like just some codegen artifact

[05:51:18.0000] <nox>
It must removes the replacing node from its previous parent,

[05:51:28.0000] <nox>
and it must removes the to-be-replaced child from the new parent of the replacing node.

[05:51:44.0000] <nox>
The removing of the to-be-replaced child is the removedNodes in the mutation record of the actual replacement.

[05:52:11.0000] <nox>
The removing of the replacing node is part of `node` being adopted.

[05:52:13.0000] <smaug____>
first you remove node from parent, you get record 1, (now node is already removed), then you can't remove it again so the next record has just added node

[05:52:36.0000] <nox>
All replacements end with a (removedNodes = [child] addedNodes = [node]), so that shouldn't be the thing that is changed.

[05:52:55.0000] <nox>
smaug____: Then that is a replacement that doesn't look like a replacement.

[05:53:02.0000] <nox>
Hence why I think it would be wrong.

[05:53:25.0000] <nox>
Case 1: node has no previous parent: (removedNodes = [child], addedNodes = [node])

[05:53:43.0000] <nox>
Case 1: node has a previous parent: (removedNodes = [node]) (removedNodes = [child], addedNodes = [node])

[05:53:44.0000] <nox>
s/1/2/

[05:53:59.0000] <nox>
Case 3: node = child in current Gecko: (removedNodes = [child]) (removedNodes = [child], addedNodes = [child])

[05:54:19.0000] <nox>
You suggest changing case 3 to  (removedNodes = [child]) (addedNodes = [child]);

[05:54:30.0000] <nox>
I suggest (removedNodes = [child], addedNodes = [child])

[05:54:37.0000] <smaug____>
and I think that is wrong

[05:54:47.0000] <smaug____>
first you remove from whatever parent

[05:54:53.0000] <nox>
smaug____: Your suggestion makes case 3 out of the place when comparing to case 1 and 2…

[05:54:56.0000] <smaug____>
so you need to get (removedNodes = [node])

[05:55:24.0000] <smaug____>
and your suggestion makes case 2 out of place

[05:55:27.0000] <nox>
And it makes the algorithm way more complex than conditionally adopting.

[05:55:30.0000] <nox>
No it doesn't.

[05:55:33.0000] <smaug____>
you're missing one record

[05:55:38.0000] <nox>
No.

[05:55:42.0000] <nox>
It just makes it like case 1.

[05:55:43.0000] <smaug____>
which should always happen when something is replaced

[05:55:56.0000] <smaug____>
but it isn't like case 1

[05:56:10.0000] <nox>
When something is replaced, there should always be a mutation record corresponding to a damn replacement.

[05:56:11.0000] <nox>
In your case 3, it doesn't.

[05:56:11.0000] <nox>
it looks like remove and insertBefore were called.

[05:56:18.0000] <smaug____>
node *does have* previous parent

[05:56:27.0000] <smaug____>
so it is not case 1

[05:56:53.0000] <nox>
And it is a replacement, so no mutation record at all with both removedNodes and addedNodes is wrong too.

[05:56:55.0000] <nox>
And it makes the spec way more verbose than my suggestion.

[05:57:20.0000] <nox>
"Let nodes be node’s children if node is a DocumentFragment node, and a list containing solely node otherwise." becomes:

[05:57:45.0000] <nox>
Let nodes be the empty list if node is child, node’s children if node is a DocumentFragment node, and a list containing solely node otherwise.

[05:58:11.0000] <smaug____>
( I don't understand why Gecko gives that (removedNodes = [child], addedNodes = [child]), I need to debug)

[05:58:31.0000] <nox>
It does it because it's a replacement…

[05:58:36.0000] <nox>
And because the spec says to queue that.

[05:59:47.0000] <nox>
Err, what I said about step 12 is wrong.

[05:59:51.0000] <smaug____>
I don't care what the spec says, I care what should happen ;)

[06:00:04.0000] <nox>
It's step 14 that needs to be changed for what you said.

[06:00:10.0000] <nox>
smaug____: Sure, but replacing a node should always queue a replacement record,

[06:00:21.0000] <nox>
a record with just addedNodes isn't, whatever we say.

[06:00:46.0000] <smaug____>
"replacement record"

[06:00:51.0000] <nox>
"removedNodes a list solely containing child" would need to become "removedNodes a list solely containing child if child is not node, and the empty list otherwise."

[06:00:53.0000] <smaug____>
what on earth that is :)

[06:00:56.0000] <smaug____>
there are just MutationRecords

[06:00:59.0000] <nox>
smaug____: A record with both removedNodes and addedNodes, obviously.

[06:01:33.0000] <smaug____>
but let me debug this some

[06:01:47.0000] <smaug____>
I need to understand why gecko does what it does now

[06:04:39.0000] <nox>
And with 2 mutation records, I will need to invalidate childNodes' cache more frequently in Servo.

[06:05:12.0000] <nox>
A mutation record with (removedNodes = [node], addedNodes = [node]) tells me that the list of children didn't change size, so my cache is still correct.

[06:09:07.0000] <smaug____>
nox: so in Gecko I'm getting the records I expect

[06:09:09.0000] <smaug____>
2 records

[06:09:23.0000] <smaug____>
first one has the removal, 2nd one has the added node

[06:09:45.0000] <nox>
And why would that be more correct than what I said?

[06:09:49.0000] <smaug____>
nox: you use mutation records to invalidate childNodes cache?

[06:09:57.0000] <nox>
smaug____: Their machinery yes.

[06:10:09.0000] <nox>
That's written in the ticket, it would be nice if I didn't have to repeat myself. :)

[06:10:41.0000] <smaug____>
it is rather expected that replaceChild first removes the replacing node from its parent

[06:10:44.0000] <nox>
Mutation records in Servo will be queued somewhere in a children_changed method. That method is too used to update childNodes cache.

[06:10:54.0000] <smaug____>
so, you get one record for that

[06:11:03.0000] <nox>
It is rather expected that replaceChild will queue a record with both removedNodes and addedNodes.

[06:11:10.0000] <smaug____>
and then you create a record for the case when replacing node is added to context node

[06:11:12.0000] <nox>
What's wrong about what I'm saying?

[06:11:25.0000] <smaug____>
and whether or not something removed is just a side thing

[06:11:30.0000] <nox>
"replacement", i.e. something is removed and something is added.

[06:11:59.0000] <smaug____>
you somehow special case child == node

[06:12:09.0000] <nox>
You do too.

[06:12:16.0000] <smaug____>
not really

[06:12:29.0000] <annevk>
I think either way we'll have to special case that

[06:12:32.0000] <nox>
Yes you do. That case must be discriminated to not include child in removedNodes.

[06:12:44.0000] <nox>
Cf. step 14.

[06:12:47.0000] <smaug____>
if nothing is removed in the second phase, you don't get anything in the removedNodes

[06:13:02.0000] <nox>
And how do you initialise removedNodes?

[06:13:23.0000] <nox>
By saying it should be empty if child = node,

[06:13:23.0000] <nox>
that's discriminating.

[06:14:41.0000] <smaug____>
initialize removedNodes? it is empty list unless you've removed something from a node when the record is created

[06:15:17.0000] <nox>
That makes no sense. You are talking about this from the POV of implementation details of Gecko.

[06:15:26.0000] <smaug____>
I see Gecko's behavior, which is (removedNodes = [child], addedNodes = [child]), not (removedNodes = [child]), (removedNodes = [child], addedNodes = [child]) rather good one

[06:15:41.0000] <nox>
How do you *specify* what you are saying, if not by special-casing child = node?

[06:15:55.0000] <smaug____>
nox: I'm talking about from the point of view of how I see mutations in DOM should work ;)

[06:16:00.0000] <nox>
Me too.

[06:16:04.0000] <nox>
How do you specify it?

[06:16:12.0000] <smaug____>
and from a point of view of the MutationObserver API designer

[06:16:12.0000] <nox>
How do you write the prose that describe what *you* want?

[06:16:16.0000] <nox>
Me too.

[06:16:44.0000] <nox>
You say you aren't special-casing child == node, explain what would be the prose to do what you say without special-casing it.

[06:18:16.0000] <annevk>
Note also that we are special casing this case already elsewhere, in pre-insert

[06:18:43.0000] <nox>
annevk: Yeah, and insertion is not about removing something and putting something instead.

[06:19:01.0000] <nox>
From the POV of a MutationObserver API designer, I would expect the mutation records to strive to describe the actual mutations taking place,

[06:19:10.0000] <smaug____>
there is still special case sure, but different place. and I say removing the first "replacing node is removed from parent"  in some case would be weirder that having just the case later that if there isn't anything to remove anymore, don't add anything to removedNodes

[06:19:15.0000] <nox>
that's why we have the suppress observers flag and whatnot,

[06:19:47.0000] <nox>
making two records is to me like not having the suppress observers flag, and queueing mutation records for each removal and insertion instead of in bulk.

[06:20:00.0000] <nox>
smaug____: And that's not special-casing?

[06:20:30.0000] <nox>
How is changing the removedNodes property of the second record not as special-casing as not queuing the first one?

[06:20:50.0000] <annevk>
smaug____: it seems your solution requires changes to step 11 and step 14, whereas nox' solution requires only a change to step 10 and creates cleaner records...

[06:21:40.0000] <smaug____>
I'm looking if my solution needs any changes

[06:22:00.0000] <smaug____>
step 11 wouldn't just do anything, and I'm not sure what it does here... reading

[06:22:08.0000] <nox>
To the spec? Of course it does, that's what I've been saying for 15 minutes.

[06:22:11.0000] <annevk>
smaug____: it segfaults

[06:22:21.0000] <nox>
Removing a node from its parent needs a parent. `node` doesn't have a parent anymore.

[06:22:26.0000] <nox>
That's why the spec is wrong.

[06:22:53.0000] <smaug____>
ah, 14 would need change

[06:23:10.0000] <nox>
And 11.

[06:23:15.0000] <smaug____>
yes

[06:23:36.0000] <nox>
Mine needs a change in step 10 and makes better records.

[06:23:45.0000] <smaug____>
nox' solution creates unexpected records, since it is missing the first one

[06:23:54.0000] <nox>
Expected records*

[06:24:06.0000] <smaug____>
unexpected :)

[06:24:10.0000] <nox>
Yours are unexpected, because the second one doesn't describe a replacement.

[06:24:11.0000] <smaug____>
because it is missing the first one

[06:24:22.0000] <nox>
See my test.

[06:24:29.0000] <nox>
Find a replaceChild that produces a record without a removedNodes property.

[06:24:33.0000] <nox>
Hint: there is none.

[06:24:37.0000] <annevk>
smaug____: not describing the replacement seems at least equally weird

[06:24:45.0000] <annevk>
or unexpected

[06:25:10.0000] <smaug____>
I'm trying to see why what is unexpected

[06:25:16.0000] <nox>
https://github.com/nox/web-platform-tests/blob/replacechild-mutation-records/dom/nodes/MutationObserver-childList.html#L258-L296

[06:25:59.0000] <annevk>
smaug____: because in all cases, except for this one in Gecko, invoking replaceChild ends with a record that describes what node got removed and what it got replaced with

[06:26:03.0000] <nox>
{type: "childList", removedNodes: […], addedNodes: […]}

[06:28:41.0000] <smaug____>
can't see the light here

[06:29:26.0000] <nox>
Do you understand what annevk said?

[06:29:34.0000] <nox>
It's not rocket science.

[06:29:44.0000] <nox>
Do you not see the common element to all the tests I linked?

[06:32:01.0000] <smaug____>
53 is missing one record, that is what I see

[06:32:26.0000] <nox>
Are you kidding me?

[06:32:31.0000] <smaug____>
I'm trying to understand reasoning for this proposed change

[06:32:49.0000] <smaug____>
we need a fix to the spec sure

[06:33:18.0000] <nox>
Oh, n51 is the same test I see.

[06:34:06.0000] <smaug____>
one of the initial steps in replaceChild has always been that the node is removed from its parent

[06:34:09.0000] <nox>
Ah no, d51 doesn't exist. Different test.

[06:34:41.0000] <smaug____>
so I'm trying to understand why that step should now change

[06:34:45.0000] <nox>
smaug____: One of the final steps in replaceChild has always been that the mutation record has always a removedNodes.

[06:34:53.0000] <smaug____>
no

[06:34:59.0000] <nox>
What no?

[06:35:00.0000] <smaug____>
MutationObservers are a new thing

[06:35:04.0000] <nox>
Ok.

[06:35:08.0000] <smaug____>
added to DOM recently

[06:35:14.0000] <nox>
Let me reformulate.

[06:35:29.0000] <nox>
One of the initial steps in replaceChild has not been that the node is removed from its parent,

[06:35:38.0000] <nox>
since WebKit always short-circuited everything in case child = node.

[06:36:20.0000] <smaug____>
that is implementation detail

[06:36:42.0000] <smaug____>
I was talking about spec here

[06:36:46.0000] <nox>
And if the node wasn't in a parent, it isn't removed from anywhere, so what you are saying is wrong too.

[06:37:04.0000] <nox>
About spec, mutation records of replacement operations always include a removedNodes entry.

[06:37:12.0000] <nox>
That's right there in the spec, isn't it?

[06:37:36.0000] <nox>
Replacing a child by a node with no parent: removedNodes present;

[06:37:57.0000] <nox>
replacing a child by nothing: removedNodes present;

[06:37:57.0000] <nox>
replacing a child by another node in the document: removedNodes present;

[06:37:58.0000] <nox>
replacing a child by another node in another document: removedNodes present;

[06:38:07.0000] <nox>
replacing a child by itself: you want no removedNodes present, I want one.

[06:38:16.0000] <smaug____>
.innerHTML creates "replacement record", and may not contain anything in removedNodes

[06:38:36.0000] <smaug____>
same with .textContent

[06:38:41.0000] <nox>
That's because it's akin to "replace all".

[06:38:48.0000] <nox>
That's not "replacing a single thing by something else".

[06:38:59.0000] <nox>
replaceWith does like I just described.

[06:39:34.0000] <caitp>
would there be any harm done if implementations which short circuited the actual replacement, still queued up the mutation records?

[06:39:46.0000] <nox>
caitp: Yes.

[06:39:52.0000] <nox>
caitp: Ranges not being updated.

[06:42:36.0000] <caitp>
in webkit, they could probably get all the side effects with Node::didReplace() or whatever it's called

[06:42:48.0000] <smaug____>
(anecdote, even DOM 1 spec from 1997 says "If the newChild is already in the tree, it is first removed. ")

[06:44:18.0000] <nox>
You can't argue that mutation observers are new,

[06:44:22.0000] <nox>
and then argue about how the newChild must be removed from its parent in 1997.

[06:44:32.0000] <nox>
Even with my suggestion, newChild is still removed from its parent.

[06:44:47.0000] <nox>
But it does so with observer suppressed.

[06:45:18.0000] <nox>
Whereas you want to keep removing it during adoption (which doesn't look mentioned in 1997), with the observers unsuppressed.

[06:49:25.0000] <smaug____>
/me doesn't understand how the proposal would improve anything but thinking ... trying to understand

[06:50:40.0000] <annevk>
smaug____: well for one it'd keep the spec simpler

[06:50:54.0000] <nox>
And would queue less mutation records.

[06:52:43.0000] <smaug____>
and would change the behavior of shipping produces

[06:52:46.0000] <smaug____>
products

[06:52:58.0000] <smaug____>
nox: what does Edge do?

[06:53:22.0000] <nox>
I'm on a Mac.

[06:54:00.0000] <nox>
smaug____: I'm pretty sure Gecko has another bug anyway…

[06:55:45.0000] <nox>
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#1970 This, what is it?

[06:56:12.0000] <nox>
Isn't that about the child's next sibling being node?

[06:57:17.0000] <smaug____>
no

[06:57:36.0000] <smaug____>
that is the child

[06:58:12.0000] <nox>
Why could an error be thrown at that point?

[06:58:59.0000] <smaug____>
mostly because "this is mutation events, ensure we're some sane-ish state still"

[06:59:17.0000] <caitp>
"I'm pretty sure Gecko/AnyOtherEngine has another bug anyway" pretty safe bet =)

[06:59:27.0000] <smaug____>
well, mutation events aren't spec'ed

[06:59:44.0000] <nox>
Wha

[06:59:50.0000] <smaug____>
++caitp

[07:00:49.0000] <gsnedder1>
nox: you do "something vaguely like this"

[07:01:12.0000] <nox>
gsnedder1: My patch is pristine clear. =)

[07:01:26.0000] <annevk>
I still hold some hopes we don't have to define mutation events

[07:01:42.0000] <annevk>
But... I'm getting close to the point of just trying to figure them out and get it over with

[07:01:56.0000] <gsnedders>
annevk: I think that's a vain hope at this stage :(

[07:01:59.0000] <annevk>
Although maybe if Servo gets away with sanity and prevails

[07:02:16.0000] <nox>
Justice shall prevail.

[07:02:33.0000] <gsnedders>
May the odds be forever in your favour.

[07:02:48.0000] <smaug____>
so in Gecko the current behavior comes rather naturally from the implementation, I admit. Since MutationObserver implementation uses internal nsIMutationObserver to get notifications about actual removals and additions, if some removal just doesn't happen, removedNodes will be empty

[07:03:26.0000] <nox>
smaug____: In Servo too. :)

[07:03:50.0000] <smaug____>
so it is like merging 14 to 11

[07:04:01.0000] <smaug____>
partially

[07:04:18.0000] <nox>
smaug____: Following my DOM PR: https://github.com/nox/servo/blob/c63e8e62454a0ef2d1006c00a19d7aa62ba0777d/components/script/dom/node.rs#L2050-L2054

[07:05:37.0000] <smaug____>
nox: and you could have that same null check around Node::remove(child, self, SuppressObserver::Suppressed);

[07:05:43.0000] <smaug____>
and get Gecko's behavior

[07:06:11.0000] <nox>
smaug____: No. I would then have to change step 14.

[07:06:47.0000] <smaug____>
ok, so Servo has quite different setup then

[07:06:54.0000] <nox>
Specifically, I would need to call either ChildrenMutation::replace or ChildrenMutation::insert.

[07:07:15.0000] <smaug____>
in Gecko it is step 11 effectively which tells whether mutation record has something in removedNodes

[07:07:27.0000] <smaug____>
since it nothing is removed, nothing will be added to removed nodes

[07:07:33.0000] <nox>
smaug____: In Servo, mutation records are built explicitly.

[07:07:38.0000] <nox>
s/are/will be/

[07:07:56.0000] <nox>
From a ChildrenMutation struct, which we build in each method that queues a mutation record.

[07:08:24.0000] <nox>
That ChildrenMutation thing is what I use to update childNodes.

[07:08:59.0000] <nox>
https://github.com/nox/servo/blob/c63e8e62454a0ef2d1006c00a19d7aa62ba0777d/components/script/dom/nodelist.rs#L240-L267

[07:09:28.0000] <nox>
With your suggestion, calling replaceChild will mean we reach https://github.com/nox/servo/blob/c63e8e62454a0ef2d1006c00a19d7aa62ba0777d/components/script/dom/nodelist.rs#L233 way more frequently.

[07:09:31.0000] <nox>
With mine, never.

[07:09:48.0000] <nox>
With mine, only the case where we replace a child by nothing*

[07:14:39.0000] <smaug____>
in Gecko the latter record gets both removed/addedNodes because of http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp?mark=2168-2168,2189-2189#2168 and it nsAutoMutationBatch isn't ever initialized, you just get a normal record with addedNodes

[07:14:48.0000] <smaug____>
s/it/if/

[07:15:22.0000] <nox>
Someone should try my test on Edge.

[07:15:41.0000] <smaug____>
when no batching happens, all mutationrecord handling is based on actual insertions or removals

[07:18:05.0000] <nox>
I find the setup in Servo better because it follows closely the spec.

[07:20:23.0000] <smaug____>
oh, sure from readability point of view probably much better. Gecko just was there well before we had good DOM spec ;)

[07:20:41.0000] <smaug____>
and, nsIMutationObserver which we use for this too is super handy

[07:21:15.0000] <smaug____>
nsIMutationObserver has very little to do with MutationObserver, way lower level, C++ only notifications

[07:21:31.0000] <smaug____>
(nsIMutationObserver is used also to implement Range etc)

[07:22:46.0000] <nox>
smaug____: children_changed is Servo's nsIMutationObserver.

[07:23:25.0000] <smaug____>
sounds like it is a tad higher level thing

[07:23:33.0000] <nox>
For childList records that is.

[07:24:13.0000] <nox>
It is used for Rust-only things I mean.

[07:24:53.0000] <nox>
And will be usable for actual MutationRecord things.

[07:29:39.0000] <smaug____>
lunch

[07:30:04.0000] <Ms2ger>
5:30pm?

[07:30:54.0000] <nox>
Ms2ger: Actually just went outside to buy a sandwich too.

[07:31:12.0000] <nox>
But I woke up at 11:30.

[07:41:43.0000] <nox>
:'(

[07:42:08.0000] <nox>
https://github.com/whatwg/dom/pull/121#issuecomment-160163345

[09:01:45.0000] <smaug____>
1) We should aim for consistency as long as possible. So if some step in an algorithm can be executed, it should be (by default) (step 10), and aim for adding special cases to steps which just can't be executed (step 11)

[09:02:02.0000] <smaug____>
2) with your proposal we end up creating such mutation records which no other mutation creates, same node in removed and in added nodes

[09:02:05.0000] <smaug____>
nox: aha, even more reasons for Gecko's behavior :)

[09:02:06.0000] <nox>
Yeah.

[09:38:42.0000] <annevk>
Well glad that got sorted

[09:38:51.0000] <annevk>
I guess now we need to figure out what the steps actually need to say

[09:39:05.0000] <annevk>
And we should add some more tests

[09:45:29.0000] <nox>
annevk: Will do.

[09:46:31.0000] <smaug____>
annevk: just to verify, getAttributeNames is supposed to return attributes in the same order as .attributes, right?

[09:46:49.0000] <gsnedders>
We should probably try and make sure we have tests for every spec change going forward, somehow.

[11:27:32.0000] <smaug____>
annevk: FYI, I'm adding some getAttributeNames tests in a Gecko bug

[11:27:34.0000] <smaug____>
wpt tests

[11:54:10.0000] <annevk>
smaug____: yes and nice!

[11:54:47.0000] <annevk>
gsnedders: some kind of specification dashboard from which you can file bugs for commits would be great

[11:54:54.0000] <annevk>
gsnedders: so you can file bugs against browsers and wpt

[11:57:23.0000] <gsnedders>
annevk: like, updating an impl to the current spec from something a few years ago where the spec hasn't changed much is so much easier if there's tests for it rather than looking through the *whole* spec and impl

[11:57:40.0000] <gsnedders>
so we really need tests for everything

[11:57:44.0000] <gsnedders>
and people to write them

[11:57:47.0000] <gsnedders>
which is really the problem :P

[11:57:54.0000] <gsnedders>
TabAtkins: yt?

[12:01:48.0000] <astearns>
and people to review them

[12:02:55.0000] <gsnedders>
astearns: wpt has almost no problems getting test review

[12:03:05.0000] <gsnedders>
astearns: that's a csswg-test problem, pretty much

[12:03:13.0000] <astearns>
yep

[12:03:25.0000] <gsnedders>
astearns: really you guys just need to relax the requirements as to who can review

[12:03:49.0000] <gsnedders>
But there's not really much point in me rambling about this again :)

[12:03:51.0000] <astearns>
afaik, we have - we should be allowing anyone to review

[12:04:04.0000] <astearns>
if that's not the case, I'll push at it again

[12:05:16.0000] <gsnedders>
I have no idea.

[12:05:30.0000] <gsnedders>
There's no good written documentation saying what the policies are nowadays, and what there is is so out of date.

[12:07:08.0000] <gsnedders>
astearns: really I think a lot of the problem is half the time when there's any discussion almost nobody responds, and it's only the people who object respond

[12:07:35.0000] <gsnedders>
astearns: probably just need to take some large proposal of "here's what we want to do" to the whole group and see if there's consensus

[12:07:38.0000] <astearns>
gsnedders: on the mailing list, you mean?

[12:08:21.0000] <gsnedders>
astearns: yeah

[12:08:52.0000] <gsnedders>
I think there's much more explicit implicit agreement at F2Fs :)

[12:09:24.0000] <gsnedders>
(I presume I won't be showing up in Sydney, given costs and not having any funding in place for next year presently)

[12:09:26.0000] <astearns>
from people who don't subscribe to the testing mailing list, and so don't contribute to the discussions there :)

[12:09:35.0000] <gsnedders>
(FWIW)

[12:09:38.0000] <smaug____>
gsnedders: yet, even if wpt gets reviews, one should not rely on them in case implementing something you get test failures :) (I just fixed a broken MutationObserver test yesterday)

[12:09:56.0000] <gsnedders>
smaug____: oh, totally agreed

[12:09:58.0000] <smaug____>
but sure, usually things go well

[12:10:33.0000] <gsnedders>
smaug____: but even with far higher requirements for who can review you still end up with bad tests slipping through (probably fewer though), but then you also get far fewer tests reviewed too…

[12:11:03.0000] <smaug____>
very true. need some balance, yet mostly we need just more tests

[12:11:30.0000] <gsnedders>
my basic conclusion is we just need to swing policies in favour of more tests, because bad tests will be found when people debug failures

[12:11:43.0000] <gsnedders>
(though that does nothing for tests that bogusly pass)

[12:12:11.0000] <gsnedders>
and really the choice is between getting the major of tests vendors write v. very, very few

[12:12:22.0000] <gsnedders>
no policy will lead to any middle ground, AFAICT

[12:12:29.0000] <smaug____>
it would be great if we could get help from web devs to write tests, so that not only browser impls write them. It should be also interests for web devs to ensure browsers don't regress behavior

[12:13:19.0000] <gsnedders>
smaug____: FWIW, I know some major web companies have expressed interest in paying people to work on testing browsers (because long-term it's in there interest), but thus far nothing really has come of it

[12:13:37.0000] <astearns>
I'm going to be talking next week to a room full of web devs on that very topic - becoming responsible for the tech we use (writing tests, reporting bugs, etc.)

[12:14:01.0000] <gsnedders>
smaug____: the big problem with tests from TTWF and similar is that the devs will open PRs with what they've written, but then will never get back to respond to any sort of review comments

[12:14:09.0000] <gsnedders>
and quite frankly plenty of the tests are really poor

[12:14:38.0000] <gsnedders>
I think a lot of that is just the fact the majority of people are terrible at any sort of QA

[12:14:46.0000] <smaug____>
does that hint we need better documentation how to write good tests

[12:15:28.0000] <gsnedders>
smaug____: I think the issue is deeper than that: people don't know *how* to even start writing a test for a feature (not a web feature, but *any* feature)

[12:16:04.0000] <gsnedders>
like what we get is consistent with what I see in plenty of places: devs are simply terrible at testing

[12:16:20.0000] <smaug____>
hmm, I don't btw know how to run wpt tests if I'm not using mach from mozilla-central

[12:16:33.0000] <smaug____>
but like how to run wpt in other browsers

[12:17:01.0000] <smaug____>
looks like https://github.com/w3c/web-platform-tests/ explains

[12:17:24.0000] <gsnedders>
not really how to run all the tests in an automated manner

[12:17:31.0000] <gsnedders>
but how many people actually need to do that?

[12:17:41.0000] <smaug____>
jgraham_ et al have just make running tests so easy with gecko

[12:17:43.0000] <gsnedders>
like what matters is being able to run one test

[12:17:49.0000] <smaug____>
s/make/made/

[12:17:57.0000] <gsnedders>
smaug____: fwiw, wptrunner works with more than just Gecko and Servo

[12:18:12.0000] <gsnedders>
at least in principle, it should be cross-browser, without too much setup code per browser

[12:18:43.0000] <gsnedders>
the harder thing is running reftests in some user-friendly way, IMO

[12:23:30.0000] <gsnedders>
astearns: do you have any views on how to clarify policies about testsuite? just bring it up on www-style?

[12:23:38.0000] <gsnedders>
(and telecons?)

[12:24:20.0000] <smaug____>
gsnedders: but do other vendors yet run wpt automatically?

[12:24:35.0000] <smaug____>
I thought blink has plans, but not doing it yet

[12:24:43.0000] <gsnedders>
smaug____: Edge do

[12:24:47.0000] <smaug____>
ah, great

[12:25:06.0000] <astearns>
telecons and ftf would probably be more effective than the mailing list(s) (as you noted, only the people who are comfortable with the status quo respond on the lists)

[12:25:43.0000] <astearns>
I'm happy to spend telcon time talking about testing

[12:25:55.0000] <gsnedders>
we should probably do this once I formally back in the group :)

[12:26:51.0000] <gsnedders>
smaug____: I think within six months we really hopefully can be at a point where everyone is running wpt+csswg-test. idk quite how realistic that is for Blink.

[12:26:54.0000] <astearns>
yep yep (and/or before the formalities are done, depending on how long that takes)

[12:27:12.0000] <astearns>
brb

[12:27:38.0000] <gsnedders>
as I said, I won't be at the next F2F (and idk really until next TPAC, given travel costs, depending on what happens about funding)

[12:27:57.0000] <gsnedders>
(I mean I /can/ self-fund, but long-haul travel starts having real effects on income fast)

[12:36:34.0000] <astearns>
gsnedders: where are you based?

[12:37:59.0000] <gsnedders>
astearns: Scotland

[12:39:19.0000] <astearns>
I think good progress can be made if we spend some time talking on the weekly calls about tests

[12:40:03.0000] <astearns>
prod people about the review queue, get some testing voids identified to spur test writing

[12:41:17.0000] <gsnedders>
I think stuff would be easier if we just viewed the tests in the repo as de-facto reviewed (by virtue of being run by some), and just kept on top of new tests

[12:42:11.0000] <gsnedders>
(I also don't think finding test voids really helps *that* much, because browser vendors will mostly write tests when it's in their interest and not much otherwise)

[12:42:55.0000] <astearns>
the review queue I'm concerned about is pending pull requests. I don't much care about the review "status" of tests already in the repo

[12:45:59.0000] <gsnedders>
I'll try and write something up as to what there's mostly consensus on (mostly those who've spoken except for Gérard) to www-style for the sake of somewhere to *start* discussions; I'll probably throw in a few things that I feel strongly about too :)

[12:48:51.0000] <gsnedders>
there wasn't anything more than "west coast US" said for the May F2F was there?

[13:01:45.0000] <astearns>
gsnedders: nothing more definite yet for May. I don't expect we'll have a destination until after the new year

[15:54:00.0000] <paxcoder>
Hello. annevk: Why don't you write something on your blog? Are you too busy?


2015-11-28
[16:15:50.0000] <nox>
annevk: Actually, not sorted out. :)

[04:57:48.0000] <bblfish>
Any idea what it means "CryptoKey objects are opaque" ?

[04:57:56.0000] <bblfish>
http://blog.engelke.com/2014/09/19/saving-cryptographic-keys-in-the-browser/

[04:58:25.0000] <bblfish>
I know how it works, but I wonder if there is a way to distinguish opaque objects from non opaque objects

[05:44:32.0000] <nox>
smaug____: Ping?

[05:46:18.0000] <nox>
smaug____: Never mind. :)

[07:51:18.0000] <smaug____>
nox: pong or nm


2015-11-30
[06:19:09.0000] <nox>
annevk: https://github.com/whatwg/dom/pull/121#issuecomment-160642738

[06:21:49.0000] <annevk>
nox: 1) thank you 2) I have nitpicks; I would prefer first declaring the variable and then moving the if statement to where you have "Otherwise" now; and the variables in the note need to be marked up as such

[06:22:43.0000] <annevk>
nox: also, you need to adjust step 14 to account for this new variable

[06:22:49.0000] <nox>
Oh right forgot that part.

[06:23:05.0000] <annevk>
nox: the reason for the first nit is that it seems cleaner to only use "let" once

[06:23:07.0000] <nox>
annevk: I had written this amend and checked it out of place when I thought smaug____ was wrong. :(

[06:23:10.0000] <nox>
annevk: Ok.

[06:23:33.0000] <annevk>
HTML sometimes uses the if X, let Y, otherwise let Y style and it always seems kinda sketchy to me

[06:23:41.0000] <nox>
annevk: I prefer two lets because that means no mutation, but I get your point.

[06:26:38.0000] <nox>
annevk: Amended.

[06:30:07.0000] <annevk>
nox: thank you, looks good, smaug____?

[06:32:19.0000] <smaug____>
what should I look at?

[06:34:11.0000] <smaug____>
perhaps https://github.com/nox/dom/commit/3daeba1bd04a2c8db09020ffa2a25828fba52416

[06:34:36.0000] <smaug____>
is it defined what "empty list" means?

[06:34:50.0000] <smaug____>
(just don't see from this context)

[06:35:22.0000] <nox>
smaug____: I suppose:

[06:35:29.0000] <nox>
<li><p>Let <var>event path</var> be a static ordered list of all <var>target</var>'s <a>ancestors</a> in <a>tree order</a>, if <var>target</var> is <a>participating</a> in a <a>tree</a>, and the empty list otherwise.

[06:35:36.0000] <nox>
It's already used elsewhere.

[06:35:59.0000] <Ms2ger>
"let document be the Document most recently associated with that Window object."

[06:35:59.0000] <smaug____>
k

[06:37:21.0000] <smaug____>
Ms2ger: ?

[06:38:08.0000] <Ms2ger>
Wondering if that's supposed to be anything more complex than window.document

[06:39:21.0000] <Ms2ger>
Defined as "The document IDL attribute must return the Window object's newest Document object.", where "the Window object's newest Document object" is a link to "Each Document in a browsing context is associated with a Window object."

[06:39:35.0000] <nox>
Ms2ger: Document.write?

[06:39:45.0000] <nox>
Ah misread your wondering. :)

[06:39:54.0000] <nox>
Thought you were saying it must be the most complex thing ever.

[06:39:55.0000] <Ms2ger>
No, jdm's event handler compilation stuff

[06:41:29.0000] <annevk>
nox: I think removedNodes should be set to null initially

[06:41:43.0000] <annevk>
oh no

[06:42:08.0000] <annevk>
never mind, I'm being silly

[06:42:33.0000] <annevk>
smaug____: "empty list" is about as detailed as we go typically

[06:44:02.0000] <nox>
annevk: Mmh, that's not as silly as it seems.

[06:44:20.0000] <nox>
annevk: "If removedNodes is given, set record’s removedNodes to removedNodes,"

[06:44:33.0000] <nox>
annevk: I feel like it shouldn't be set at all, and it's kinda a PITA to define that.

[06:45:14.0000] <annevk>
nox: I think empty list and not present ends up meaning the same thing though

[06:46:17.0000] <annevk>
nox: I guess technically the specification says "empty NodeList"

[06:46:18.0000] <annevk>
hmm

[06:46:34.0000] <nox>
annevk: Semantically yes, but it's not the same for the mutation record, AFAICT.

[06:47:35.0000] <annevk>
nox: why not?

[06:48:26.0000] <nox>
annevk: That's not what Firefox does, at the very least.

[06:49:01.0000] <nox>
annevk: Never mind, it doesn't matter you are right.

[06:58:58.0000] <annevk>
nox: if you could rebase I'll merge this as is, seems good enough

[07:06:17.0000] <nox>
annevk: Done.

[07:08:12.0000] <bblfish_>
 I put up  a web cryptography question on stack exchange http://stackoverflow.com/questions/33971634/how-can-one-distinguish-js-opaque-objects

[07:08:42.0000] <nox>
annevk: https://github.com/w3c/web-platform-tests/pull/2379 That too? :)

[07:10:06.0000] <annevk>
nox: merged

[07:10:17.0000] <nox>
annevk: Cool.

[07:10:25.0000] <annevk>
(both)

[07:57:32.0000] <bblfish_>
@annevk did I get the defaults right for RequestInit in  https://github.com/bblfish/scala-js-dom/blob/FetchAPI/src/main/scala/org/scalajs/dom/experimental/Fetch.scala#L69 ?

[07:58:07.0000] <bblfish_>
I am not sure that is the right way to do things yet ...

[07:58:23.0000] <annevk>
bblfish_: as I told you before, I don't really know scala

[07:58:53.0000] <annevk>
bblfish: also, some of the defaults depend on the specifics of the constructor algorithm so you can't really declare them upfront

[07:59:03.0000] <annevk>
bblfish: if you could, the IDL dictionary would have included them

[07:59:11.0000] <wanderview>
annevk: if you have time before leaving for PTO, can you comment on this issue? https://code.google.com/p/chromium/issues/detail?id=559447

[07:59:15.0000] <bblfish>
ah.

[07:59:29.0000] <wanderview>
unless its already been discussed in github issues (I haven't read that mail yet)

[07:59:45.0000] <wanderview>
(also, its weird that you don't show up in the members list for the channel)

[08:00:05.0000] <bblfish>
yes, it's really complicated to work out what the right way to build the constructor is

[08:00:27.0000] <annevk>
bblfish: well, just follow the list of steps

[08:00:35.0000] <annevk>
wanderview: hmmmmm

[08:00:38.0000] <bblfish>
they are really long :-/

[08:01:12.0000] <annevk>
wanderview: so, the whole skip service worker flag seems like a distraction

[08:01:33.0000] <annevk>
wanderview: the way this should work is that "navigate" does a fetch without following redirects

[08:01:35.0000] <bblfish>
yes, I kind of noticed. It depends a lot on what options you select. Perhaps a table of things that don't go together would help

[08:02:10.0000] <annevk>
wanderview: if it gets a redirect it creates a new request from that redirect and does it exactly like the first one, this may go to the same service worker, or not, depending on the URL

[08:02:22.0000] <wanderview>
annevk: I think the html spec navigate spec needs to clarify if it creates a new Request for each redirect follow

[08:02:31.0000] <wanderview>
annevk: it does?  where does it say that?

[08:02:44.0000] <wanderview>
all I could find was the vague "handle redirects"

[08:02:45.0000] <bblfish>
btw. in that method declaration the thing after the = is the default value.

[08:02:48.0000] <annevk>
wanderview: well, it's not exactly a new request, it uses the response and the original request to create a new request, but that isn't really defined

[08:03:11.0000] <wanderview>
annevk: ok... but does the not-really-defined process clear the skip-service-worker flag on the original request?

[08:03:33.0000] <annevk>
wanderview: I have no idea about the skip-service-worker flag business

[08:04:04.0000] <annevk>
wanderview: where does that even get set?

[08:04:12.0000] <wanderview>
annevk: HTTP Fetch step 4

[08:04:28.0000] <wanderview>
annevk: step 4.2

[08:04:44.0000] <bblfish>
I could create a number of constructors, one where one of the options is hardwired, and the other options are left open to help the user work out what he can chooose.... But would probably require a very very very careful study of that spec.

[08:06:02.0000] <annevk>
wanderview: so that only gets set if the service worker didn't give a reply

[08:06:21.0000] <annevk>
wanderview: if the service worker returns a redirect, response cannot be null, can it?

[08:06:34.0000] <wanderview>
annevk: exactly... didn't give a reply is the case we care about

[08:06:50.0000] <annevk>
wanderview: okay, catching up here :-)

[08:07:01.0000] <wanderview>
annevk: if the SW doesn't give a reply... should the navigate still check further service workers for interception?

[08:07:04.0000] <wanderview>
on redirect

[08:07:12.0000] <wanderview>
np... its confusing

[08:07:45.0000] <annevk>
so yeah, I guess we should only set it when redirect mode is "follow"

[08:08:11.0000] <annevk>
and of course, we should define the (request, redirectResponse) -> request thingie at some point...

[08:08:21.0000] <annevk>
so navigation can use that

[08:08:58.0000] <annevk>
wanderview: does that make sense? I have to go now, but I'll check back in a couple of hours

[08:09:17.0000] <Ms2ger>
annevk, r? https://github.com/whatwg/html/pull/365

[08:09:30.0000] <wanderview>
annevk: it does, but I guess I'm curious if it applies only to navigates... I'll write a spec issue

[08:09:36.0000] <annevk>
Ms2ger: better ask someone else

[08:10:00.0000] <annevk>
wanderview: well, navigate is the only place that doesn't follow redirects automatically

[08:10:29.0000] <annevk>
wanderview: anyway, my suggestion is to special case "redirect mode" rather than "navigate", as we did elsewhere

[08:10:41.0000] <Ms2ger>
someone else: r? https://github.com/whatwg/html/pull/365

[08:10:48.0000] <annevk>
wanderview: (step 3.3 of the same algorithm)

[08:11:19.0000] <wanderview>
annevk: ok, thanks

[08:11:49.0000] <Domenic>
annevk: how are you not the perfect person to review that?

[08:13:12.0000] <Ms2ger>
I even dropped the period

[08:13:15.0000] <annevk>
time

[08:13:21.0000] <wanderview>
/me can't tab-complete Domenic's name either...

[08:13:51.0000] <Domenic>
grumble grumble now I have to go re-learn the difference between listener and callback and other fun things...

[08:14:05.0000] <Ms2ger>
Domenic, afaict, listener was renamed to callback in DOM

[08:14:16.0000] <Ms2ger>
Domenic, if that's wrong, I'll revert that bit

[08:14:45.0000] <Domenic>
Ms2ger: "An event listener consists of a type, callback, and capture." (And in a second sentence following it, a removed flag.)

[08:16:17.0000] <Domenic>
Ms2ger: so I think your change is correct...

[08:16:18.0000] <Domenic>
reviewing

[08:20:58.0000] <Ms2ger>
Domenic, looks like I was right on renaming, and HTML was way behind the times: https://github.com/whatwg/dom/commit/e89fef9c0d80688736bbea2527047862eba238f6

[08:23:29.0000] <Domenic>
Having "event listener" and "event handler" and the callback function itself be different objects is ... special? Putting on my author hat the only reaction I can imagine is a massive WAT.

[08:32:58.0000] <Ms2ger>
Domenic, re-review? :)

[08:35:12.0000] <Domenic>
Ms2ger: all done! \o/

[08:35:21.0000] <Domenic>
that wasn't as bad as I feared

[09:00:24.0000] <annevk>
Domenic: I can do it next week most likely, oh, you did it, good

[09:21:49.0000] <annevk>
Domenic: why does https://github.com/heycam/webidl/pull/13 not handle {1:2,3:4} as input?

[09:47:30.0000] <Domenic>
annevk: why would it? objects are not iterable

[09:47:39.0000] <Domenic>
annevk: new Map({ 1: 2, 3: 4}) does not work.

[10:03:08.0000] <annevk>
Domenic: it seems kind of annoying to not have that work though

[10:03:21.0000] <annevk>
Domenic: for headers especially

[10:03:40.0000] <Domenic>
annevk: it makes sense for Map where keys are arbitrary objects. For headers, sure, you would want to dispatch on whether @@iterator is present

[10:04:34.0000] <annevk>
okay, coupled with not doing subclassing perhaps we can go IDL all the way then for now...

[10:05:06.0000] <Domenic>
"Let iterator be Get(argument, @@iterator). If iterator is undefined, run algorithm for extracting from an object. Otherwise, run initializing objects from iterables"

[10:41:11.0000] <Hixie_>
i have contacted dreamhost regarding the downtime

[10:52:18.0000] <bblfish>
Ok I think I found a good way to do the defaults: I leave it up to the browser :-)

[10:53:24.0000] <bblfish>
Mh I wonder if the client can capture more details when there is an exception due to a broken server certificate.

[10:53:32.0000] <bblfish>
That would be very useful to report this to the user.

[13:55:58.0000] <Domenic>
Can anyone help me write some basic cross-origin web platform tests? jgraham?

[13:56:33.0000] <Domenic>
I am guessing based on https://github.com/w3c/web-platform-tests/blob/master/cors/origin.htm there is a global CROSSDOMAIN variable that just points to the same files?

[13:57:04.0000] <Domenic>
oh nope that's in https://github.com/w3c/web-platform-tests/blob/master/cors/support.js

[14:05:44.0000] <Domenic>
Hmm support.js gives a syntax error for those {{ports[http][0]}} lines

[14:05:50.0000] <Domenic>
(I am use ./serve)

[14:34:11.0000] <jgraham_>
Domenic: So the trick is that there's two ways to enable template substitutions

[14:34:36.0000] <jgraham_>
You can either name the file foo.sub.ext or include it with ?pipe=sub

[14:34:55.0000] <jgraham_>
s/include/access/

[14:35:03.0000] <Domenic>
Ahh

[14:35:42.0000] <jgraham_>
So generally the foo.sub.ext is more obvious to others

[14:36:57.0000] <Domenic>
Hmm not working. support.sub.js?

[14:37:11.0000] <Domenic>
?pipe=sub works though

[14:39:36.0000] <jgraham_>
I mean that actually has to be the filename on disk

[14:39:52.0000] <Domenic>
Oh I see

[14:39:53.0000] <jgraham_>
The query string works if it isn't the filename

[14:40:10.0000] <Domenic>
Well I'm reusing /cors/support.js so I will just keep using ?pipe=sub

[14:55:31.0000] <jgraham>
OK