| 02:32 | <MikeSmith> | abinader: |
| 02:44 | <MikeSmith> | abinader: ignore thatー fat-fingered |
| 02:44 | <abinader> | MikeSmith: sure :) |
| 02:45 | <MikeSmith> | cheers |
| 02:48 | <MikeSmith> | rubys: http://intertwingly.net/projects/pegurl/idna.js is bold :) I hope it works out. because it would be nice to have a self-contained conforming implementation with no dependencies |
| 08:09 | <annevk_> | MikeSmith: still depends on punycode |
| 08:18 | <MikeSmith> | annevk: oh. Sam's idna.js doesn't implement it yet? |
| 08:19 | <annevk> | MikeSmith: I think he uses a different library or file for that |
| 08:20 | <MikeSmith> | ah ok |
| 08:20 | <MikeSmith> | annevk: btw I'm behind on reading up about suborigins. From what I've gleaned through mailing-list messages, it seems like a great idea but I've yet to read an actual writeup/proposal for it yet. Is there one somewhere? |
| 08:20 | <annevk> | MikeSmith: also afaict this is only ToACII, although I'm missing some bits |
| 08:20 | <MikeSmith> | ok |
| 08:20 | <annevk> | MikeSmith: http://www.chromium.org/developers/design-documents/per-page-suborigins |
| 08:20 | <MikeSmith> | super |
| 08:20 | <MikeSmith> | thanks |
| 08:31 | <MikeSmith> | annevk: my next question is whether somebody else has done a higher-level writeup for webdevs |
| 08:31 | <MikeSmith> | maybe JakeA knows |
| 08:31 | <MikeSmith> | http://blog.joelweinberger.us/2013/08/suborigins-for-privilege-separation-in.html is pretty good I guess |
| 08:31 | <annevk> | MikeSmith: I was going to point you to that |
| 08:31 | <annevk> | MikeSmith: he's the guy behind the proposal |
| 08:31 | <annevk> | MikeSmith: I don't think you'll find much else |
| 08:31 | <MikeSmith> | yeah |
| 08:31 | <MikeSmith> | ok |
| 08:32 | <MikeSmith> | I'll go with that for now |
| 08:32 | <JakeA> | I'm not aware of anything else |
| 08:32 | <MikeSmith> | Joel's working on the SRI spec too, right? |
| 08:32 | <MikeSmith> | JakeA: k |
| 08:34 | MikeSmith | stumbles across Devdatta Akhawe's PhD thesis http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-56.pdf "Towards High Assurance HTML5 Applications" |
| 08:51 | <annevk> | MikeSmith: he is |
| 08:53 | <MikeSmith> | annevk: seems he's in Japan this week. Will ping Domenic and try to meet up with them for lunch |
| 08:54 | <annevk> | MikeSmith: you mean Dominic? |
| 08:54 | <MikeSmith> | yeah |
| 08:55 | <MikeSmith> | the "i" Dominic |
| 08:55 | <MikeSmith> | the Cooney |
| 08:55 | <annevk> | heh |
| 09:03 | <MikeSmith> | the word "compartmentalization" has far too many letters in it to be useful on twitter |
| 09:04 | <MikeSmith> | time for c18n |
| 09:08 | <zcorpan> | didn't we come up with a compression scheme for twitter earlier? |
| 09:09 | <annevk> | zcorpan: did you review the security thing about encodings? |
| 09:10 | <annevk> | zcorpan: learn Chinese and you have a great compression scheme |
| 09:10 | <zcorpan> | annevk: i read it yeah. lgtm but i don't have a good grasp of all the issues |
| 09:10 | <annevk> | zcorpan: I was gonna add you also have a large audience, but then I remembered that firewall they put in place |
| 09:11 | <zcorpan> | oh yeah twitter is blocked in china isn't it |
| 09:11 | <annevk> | yeah, you would only get notifications about it through iOS |
| 09:12 | <annevk> | it was amusing |
| 09:12 | <annevk> | So is anyone going to review my iso-2022-jp and gbk/gb18030 tests? |
| 09:12 | <annevk> | They're not that hard |
| 09:12 | <annevk> | And if they land I might be compelled to add some more tests (for all the single-byte stuff, I already wrote those a few times...) |
| 09:13 | <MikeSmith> | 划分 is even half as many characters as c18n |
| 09:13 | <MikeSmith> | annevk: I will finally review them tonight, I promise. |
| 09:14 | <MikeSmith> | unless zcorpan wants to |
| 09:14 | <zcorpan> | i can do it if annevk reviews https://critic.hoppipolla.co.uk/r/3103 :-) |
| 09:14 | <MikeSmith> | haha |
| 09:15 | <MikeSmith> | if we could scale that review strategy, then we'd have something |
| 09:15 | <zcorpan> | heycam|away: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22808 |
| 09:20 | <annevk> | zcorpan: that looks rather ugly |
| 09:20 | <zcorpan> | annevk: yeah :-| |
| 09:21 | <annevk> | zcorpan: can't you move the test_obj.done()? |
| 09:21 | <annevk> | hmm |
| 09:22 | <zcorpan> | annevk: i should probably de-uglify everything about that test at some point |
| 09:23 | <zcorpan> | right now it works for exposing bugs and doubles as a stress test |
| 09:37 | <annevk> | Where would I put global object association tests? |
| 09:38 | <zcorpan> | where is it defined? |
| 09:42 | <annevk> | zcorpan: well, it isn't |
| 09:42 | <annevk> | My plan is that IDL gives spec algorithms some hooks |
| 09:42 | <annevk> | such as "context object", "current Realm", "base URL", whatever else |
| 09:43 | <annevk> | so I guess a mixture of IDL and any spec that defines an API |
| 09:43 | <annevk> | http://web.mit.edu/bzbarsky/www/testcases/global-object-association/createImageData.html |
| 09:43 | <annevk> | has an excellent example |
| 09:55 | <annevk> | jgraham: why is there no assert_instanceof? |
| 09:56 | <jgraham> | annevk: No one asked? |
| 09:57 | <annevk> | jgraham: see the file from bz above, it would make sense for that, no? |
| 10:00 | <gsnedders> | Because instanceof is probably too indirect for testing that, no? |
| 10:00 | <gsnedders> | Given it walks the prototype chain? |
| 10:02 | <annevk> | gsnedders: you have an alternative? |
| 10:03 | <gsnedders> | oh, wait, instanceof does [[HasInstance]] |
| 10:03 | <gsnedders> | um, ignore me |
| 10:05 | <zcorpan> | annevk: WebIDL/ if you want the tests in a central place i guess |
| 10:06 | <annevk> | jgraham: can I patch testharness.js from within web-platform-tests? |
| 10:07 | <Ms2ger> | It's in resources/ |
| 10:07 | <Ms2ger> | And I put tests like that with the spec that defines the API |
| 10:08 | <gsnedders> | should idlharness.js not be able to test that? |
| 10:08 | <Ms2ger> | That would be even better |
| 10:09 | <annevk> | gsnedders: how? |
| 10:11 | <annevk> | I'm not super interested in splitting the tests over a dozen directories |
| 10:11 | <gsnedders> | doesn't the IDL give enough to know what the constructor function is for a given object? |
| 10:12 | <gsnedders> | like idlharness.js knows how to create a given object and knows the Function object that can be used to create it, if one exists, no? |
| 10:12 | <annevk> | gsnedders: nope |
| 10:13 | <annevk> | well, maybe it can be an idl thing eventually... |
| 10:14 | <zcorpan> | annevk: i guess in general what is needed is "is a Foo" check, not "is a Foo of global X" |
| 10:14 | <JakeA> | annevk: want to find time for a call this week or next on the API generality/scope stuff. Any evenings you can't do? |
| 10:15 | <gsnedders> | zcorpan: yeah, that's what I'm thinking of |
| 10:16 | <annevk> | zcorpan: instanceof can't check that |
| 10:16 | <annevk> | JakeA: Tuesday-Thursday evening this week, Tuesday next week |
| 10:17 | <zcorpan> | annevk: i mean since instanceof does the latter, that's probably why it's not in testharness (and testharness explicitly avoids using instanceof for this reason) |
| 10:17 | <gsnedders> | We should definitely be testing that [[HasInstance]] and what it's renamed to in ES6 works correctly on them |
| 10:17 | <JakeA> | annevk: Just realised I asked the question really stupidly. Those are evenings you can't do, or can do? |
| 10:17 | <annevk> | cannot |
| 10:17 | <JakeA> | ta |
| 10:22 | <jgraham> | Oh yeah zcorpan has a good point |
| 10:22 | <jgraham> | It's because instanceof is broken in edge cases |
| 10:22 | <annevk> | So what pattern should I be using here? |
| 10:23 | <gsnedders> | jgraham: even in ES6? |
| 10:24 | <annevk> | cross-Realm it is |
| 10:24 | <jgraham> | gsnedders: I don't know, but if ES6 is making non-backward-compatible changes here then I certainly don't want the test harness to depend on the new semantics |
| 10:25 | <gsnedders> | jgraham: I could just be forgetting what edge-cases you're meaning |
| 10:25 | <jgraham> | annevk: bz's pattern with assert_true. Or assert_instanceof that takes an explicit global object |
| 10:32 | <annevk> | jgraham: is using a synchronous test() within onload fine? |
| 10:32 | <jgraham> | annevk: "maybe" |
| 10:33 | <Ms2ger> | Who to follow... |
| 10:33 | <Ms2ger> | * W3C Widget Specs |
| 10:33 | <Ms2ger> | I don't think so, Twitter |
| 10:33 | <annevk> | jgraham: it works |
| 10:33 | <jgraham> | annevk: The harness adds a load event listener and if there are no tests remaining when that fires it stops accepting new tests |
| 10:34 | <jgraham> | So you might be depending on the axact order of event listeners |
| 10:34 | <jgraham> | *exact |
| 10:34 | <jgraham> | Or not, depending on what other tests you have |
| 10:36 | <annevk> | jgraham: currently I just have a single test() within onload() |
| 10:36 | <jgraham> | Then I think you are depending on the order of the event handlers |
| 10:46 | <annevk> | jgraham: I guess I could make them single-page tests and just have one file per object-creating thingy |
| 10:47 | <annevk> | hmm |
| 10:52 | <annevk> | jgraham: so it's not a common case you want to wait for onload and run a bunch of tests? |
| 10:53 | <annevk> | jgraham: should I create a whole bunch of async tests and then wait for onload and then do the t.step business for each of them? |
| 10:55 | <Ms2ger> | "Let result be the result of calling the [[Call]] internal method of method" |
| 10:55 | <Ms2ger> | Oh, ES |
| 10:57 | <jgraham> | annevk: I don't know what you're trying to achieve, but in general the harness has to have *some* way of telling when there are no more tests and there isn't anything later than onload to use |
| 10:57 | <jgraham> | If you need it you can use explicit_done: true |
| 10:58 | <annevk> | jgraham: all I want is onload = function() { test(); test(); test() } |
| 10:58 | <annevk> | jgraham: e.g. I want to run a bunch of tests synchronously once the subresources have loaded |
| 11:00 | <jgraham> | Well using setup({explicit_done:true}) at the start and done() at the end certainly works there |
| 11:03 | <annevk> | jgraham: I could add that |
| 11:04 | <Ms2ger> | annevk, xhr.open('get', url1); xhr.open('get', url2); xhr.send(); will get url2, right? |
| 11:05 | <annevk> | Ms2ger: yup |
| 11:05 | <Ms2ger> | Ta |
| 11:06 | <SimonSapin> | annevk: I updated http://simonsapin.github.io/data-urls/ to not pretend to be a spec, since it wasn’t really |
| 11:09 | <annevk> | SimonSapin: that's not very useful :-( |
| 11:11 | <SimonSapin> | you mean it would me more useful if I (or someone) had done more work that hasn’t been done yet |
| 11:12 | <SimonSapin> | I might get to it at some point, it’s just not a priority right now |
| 11:14 | <SimonSapin> | but the pretend-spec full of issues that I had there before was not very useful either |
| 11:29 | <JakeA> | wanderview: What's the status of Firefox devtools and ServiceWorker? Are they friendlier? Would love to get more people playing with it in Firefox Nightly |
| 12:12 | <annevk> | hmm |
| 12:12 | <annevk> | MikeSmith: I just reviewed your test, but now I'm wondering whether the input format should use surrogate code points or not |
| 12:17 | <annevk> | yeah seems like that's baked in and would be annoying to change |
| 12:25 | <zcorpan> | annevk: should i read https://github.com/whatwg/encoding/commit/19b0ebf0e48c3a607ab7623b5b272642dd59d6e7 for reviewing your test? |
| 12:25 | <annevk> | zcorpan: you can read https://encoding.spec.whatwg.org/#iso-2022-jp |
| 12:26 | <annevk> | zcorpan: that would be somewhat required, yes |
| 12:28 | <zcorpan> | annevk: ok. so i don't need to understand the old spec |
| 12:34 | <annevk> | zcorpan: nope, it's obsolete |
| 12:44 | <annevk> | jgraham: if I write a script that generates a bunch of static test files |
| 12:44 | <annevk> | jgraham: do you want only the script committed or what it generates? |
| 12:52 | <jgraham> | Both |
| 12:55 | <annevk> | jgraham: and Python, correct? |
| 12:57 | <jgraham> | Yeah |
| 12:57 | <Ms2ger> | Preferably |
| 12:57 | <Ms2ger> | annevk, replied to https://critic.hoppipolla.co.uk/r/3127 |
| 12:57 | <annevk> | Ms2ger: so are you going to add it? |
| 12:57 | <Ms2ger> | I can |
| 12:58 | <annevk> | Ms2ger: e.g. if fetch/interfaces.html had BodyInit |
| 12:58 | <annevk> | Ms2ger: would that work? |
| 12:59 | <Ms2ger> | No, you need everything relevant in the one file |
| 12:59 | <Ms2ger> | Well, you don't need to, but that's easiest |
| 13:00 | <annevk> | Ms2ger: I guess add BodyInit with an explanation of its source |
| 13:00 | <Ms2ger> | And Blob and BufferSource and URLSearchParams, I guess |
| 13:01 | <annevk> | Ms2ger: hmm, are you going to add Document? |
| 13:01 | <Ms2ger> | Hrm |
| 13:01 | <annevk> | Ms2ger: and Node? and everything else? :-) |
| 13:01 | <annevk> | madness |
| 13:01 | <Ms2ger> | How about I leave it alone :) |
| 13:10 | <MikeSmith> | annevk: about that test, I wrote it with surrogates because I wasn't actually sure what format the test data expects for supplementary characters |
| 13:11 | <MikeSmith> | annevk: \ud83d\udca9 works as-is in Java, JavaScript, and (I think) in Python too |
| 13:11 | <MikeSmith> | annevk: is there some portable way to express it without using surrogates? |
| 13:12 | <annevk> | nah |
| 13:12 | <jgraham> | Whether that works in python might depend on what kind of build you have, I'm not sure |
| 13:12 | <MikeSmith> | ok |
| 13:13 | <MikeSmith> | I was assuming the test file data is sorta meant to be language-neutral |
| 13:20 | <annevk> | MikeSmith: which is why relying on surrogates is a bit weird, but it's fine I think |
| 13:21 | <MikeSmith> | annevk: OK |
| 13:21 | <annevk> | jgraham: actually, I'll prolly make it a dynamically generated resource so I can set some headers |
| 13:22 | <MikeSmith> | annevk: but my point was that I don't know a portable way to express it without surrogates. I mean if it were python-only, I think I could just do \U0001F4A9 (capital U). But that's not going to mean anything outside python. |
| 13:23 | <MikeSmith> | annevk: btw we really should have more URL tests with supplementary characters. The test file really doesn't have any |
| 13:23 | <annevk> | MikeSmith: well, e.g. \# is custom to that input format as well |
| 13:23 | <MikeSmith> | ok |
| 13:23 | <annevk> | MikeSmith: we could easily come up with something that languages would then have to convert before using |
| 13:24 | <MikeSmith> | yeah |
| 13:24 | <annevk> | feel free to add more tests |
| 13:24 | <MikeSmith> | we should just decide on something and use it consistently for any new tests |
| 13:24 | <MikeSmith> | heh |
| 13:24 | <annevk> | seems like a good idea |
| 13:24 | <annevk> | oh yeah, I think we decided that this is fine |
| 13:25 | <annevk> | after creating more Encoding tests I'll prolly create more URL tests |
| 13:27 | <MikeSmith> | annevk: yeah I wasn't volunteering necessarily to write more myself just now but was thinking about it in part because I just today got private mail from a guy saying: |
| 13:27 | <MikeSmith> | "One thing worth mentioning is there are some weird special cases in the URL standard for allowed content in query strings, and these differ from the rules used for the rest of the URL. RFC 3987 also special cases query strings, but it looks like it works a bit differently to the URL standard." |
| 13:27 | <MikeSmith> | "I suspect these cases are particularly important for non-English search queries passed to search engines. Whichever standard is used, it's probably worth some additional test coverage for query strings." |
| 13:28 | <annevk> | MikeSmith: yeah, the tests I'm creating for Encoding actually cover this |
| 13:28 | <MikeSmith> | rubys: ↑ FYI |
| 13:28 | <MikeSmith> | annevk: OK, good |
| 13:28 | <annevk> | MikeSmith: I'm using the URL parser to test the Encoding Standard |
| 13:28 | <MikeSmith> | hah cool |
| 13:28 | <annevk> | it's either that or <form> and the latter would require server-side setup |
| 13:28 | <MikeSmith> | ah yeah |
| 13:29 | <annevk> | though I guess I should cover that too at some point |
| 13:29 | <MikeSmith> | we could do something with wptserve I think, if/when it comes to that |
| 13:39 | <MikeSmith> | annevk: about https://github.com/w3c/web-platform-tests/pull/1369 I don't understand how you actually made a PR from two separate branches. I didn't think that was actually possible |
| 13:39 | <MikeSmith> | jgraham: ↑ |
| 13:39 | <MikeSmith> | annevk: anyway I'm finally reviewing those right now |
| 13:40 | <rubys> | MikeSmith: thanks. Annevk: is there a javascript implementation of Encoding? |
| 13:41 | <Ms2ger> | jsbell wrote something |
| 13:42 | <rubys> | annevk: re: "I'm using the URL parser to test the Encoding Standard" ... which URL parser? |
| 13:42 | <jgraham> | MikeSmith: I don't understand what you don't understand :) |
| 13:43 | <zcorpan> | rubys: https://github.com/search?q=user%3Amathiasbynens+encoding+standard |
| 13:44 | <zcorpan> | mathiasbynens: iso-2022-jp is missing :-) |
| 13:45 | <rubys> | zcorpan: thanks! |
| 13:45 | <rubys> | Ms2ger: what I found was http://src.chromium.org/viewvc/blink?view=revision&revision=173754 (which is c++) |
| 13:46 | <mathiasbynens> | zcorpan: i only have packages for the legacy single-byte encodings |
| 13:46 | <MikeSmith> | jgraham: I thought you could only create a PR from a single branch |
| 13:46 | <MikeSmith> | jgraham: I don't know what buttons to push to do a PR from multiple branches |
| 13:49 | <zcorpan> | mathiasbynens: ah ok |
| 13:49 | <zcorpan> | mathiasbynens: and utf-8 |
| 13:49 | <mathiasbynens> | zcorpan: https://mths.be/utf8js |
| 13:50 | <mathiasbynens> | yeah and WTF-8 |
| 13:51 | <jgraham> | MikeSmith: I don't know what you mean by "from". If you mean that you have master - A - B and you want a PR containing only B, you can edit the branch that the PR is against when you are in the create PR screen (I don't remember what the buttons look like). But in that case the merge button will try to merge into A rather than master which often isn't what you want |
| 13:52 | <zcorpan> | mathiasbynens: the readme doesn't say if it implements the encoding standard utf-8 or something else |
| 13:54 | <mathiasbynens> | yeah there’s an open issue on it; it doesn’t atm (allows lone surrogates) |
| 13:55 | <zcorpan> | mathiasbynens: looks like it throws on invalid input rather than emitting u+fffd (different contexts need different error handling iirc) |
| 13:56 | <zcorpan> | mathiasbynens: i see there's a bug about that also |
| 13:58 | <MikeSmith> | jgraham: I mean specifically look at https://github.com/w3c/web-platform-tests/commit/25c529dc883227d6417ab25cd167c135cba72541 So I guess what I mean is more, a PR with commits that are in multiple branches. i.e., in this case that's one commit that's both in PR #1369 (gbk branch) and also in PR #1367 (iso-2022-jp branch). I suppose that's just due to annevk having merged it into the gbk branch |
| 13:59 | <MikeSmith> | anyway no big deal. me being confused by git and github is nothing new |
| 14:00 | <wanderview> | JakeA: I'm not sure what the devtools status is... but a lot of our work is not in nightly yet since we're developing on a project branch |
| 14:00 | <jgraham> | MikeSmith: Well sure, that just falls out of the data model |
| 14:01 | <jgraham> | If you have a tree like: |
| 14:01 | <jgraham> | master - B - C |
| 14:01 | <JakeA> | wanderview: no worries, thanks for the update |
| 14:01 | <jgraham> | \ D - E |
| 14:02 | <jgraham> | And you create reviews of branches pointing to C and E they will both contain B |
| 14:02 | <wanderview> | JakeA: we want more people to use it as well, of course... so we're working to get it into nightly |
| 14:02 | <JakeA> | wanderview: lemmie know when it happens & I'll make sure demos and docs are updated to work in Firefox |
| 14:03 | <wanderview> | JakeA: it is possible to run what we have in our project branch, though: http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/maple-macosx64_gecko-debug/latest/ |
| 14:03 | <wanderview> | that install will auto-update when the project branch is updated too (I believe) |
| 14:03 | <JakeA> | wanderview: Ohh cool, can I link to that from isserviceworkerready? |
| 14:04 | <wanderview> | JakeA: I think so... its a public link... note, thats mac only... I can get the other platform links in just a sec |
| 14:05 | <wanderview> | http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/maple-win32_gecko-debug/latest/ |
| 14:05 | <wanderview> | http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/maple-linux64_gecko-debug/latest/ |
| 14:05 | <wanderview> | JakeA: ^^^ also note those are debug builds... so not as fast as optimized builds |
| 14:05 | <wanderview> | thanks! |
| 14:06 | <JakeA> | wanderview: Cheers! Is there any way to discover errors thrown within the SW? Even via a lower-level output that can be grep'd? |
| 14:07 | <JakeA> | (don't worry if not, just want to get as much info out as possible) |
| 14:08 | <wanderview> | JakeA: I'm pretty sure we report errors in the ServiceWorker script itself now... and I think console.log() is working in workers now, although I could be wrong about that |
| 14:08 | <wanderview> | let me ask |
| 14:08 | <JakeA> | ta! |
| 14:10 | <wanderview> | JakeA: hmm... the console in SW bug is not fixed yet... code in review... not sure if we have it on our project branch |
| 14:10 | <wanderview> | https://bugzilla.mozilla.org/show_bug.cgi?id=1058644 |
| 14:10 | <wanderview> | :-\ |
| 14:11 | <JakeA> | Sounds like it's close though, which is great |
| 14:13 | <MikeSmith> | annevk: so if you have a minute, I'm trying something basic about the spec for the iso-2022 decoder, which is: Where does it require implementations to return �$ for 0x1b, 0x24 rather than just returning � only? |
| 14:14 | <annevk> | MikeSmith: looking |
| 14:14 | <annevk> | So https://encoding.spec.whatwg.org/#iso-2022-jp-decoder 0x1B puts it into escape start |
| 14:14 | <MikeSmith> | ah, it continues after the �, it doesn't just abort |
| 14:14 | <annevk> | 0x24 puts it into escape |
| 14:15 | <annevk> | Step 8 of escape puts 0x24 back |
| 14:15 | <annevk> | Step 9 returns error |
| 14:15 | <annevk> | (and sets state back to ASCII) |
| 14:16 | <annevk> | ASCII then outputs 0x24 as code point |
| 14:16 | <MikeSmith> | annevk: yeah I had (mis)thought it aborted after returning error |
| 14:17 | <annevk> | rubys: the one in the browser |
| 14:17 | <MikeSmith> | annevk: but I realize now the spec doesn't say abort, it says continue |
| 14:17 | <annevk> | rubys: https://github.com/inexorabletash/text-encoding is an actual polyfill |
| 14:18 | <annevk> | MikeSmith: oh yeah, the handler stops being invoked once finished is return |
| 14:18 | <annevk> | ed |
| 14:19 | <annevk> | MikeSmith: as for the PR, I think I messed up |
| 14:19 | <annevk> | MikeSmith: I don't really know how to git |
| 14:21 | <MikeSmith> | annevk: I don't know how either. But anyway you didn't mess up anything. It doesn't create any merge conflicts or anything |
| 14:21 | <annevk> | MikeSmith: well I now I have two PRs, one being a superset |
| 14:21 | <annevk> | zcorpan_: I think you meant "does not suffice" |
| 14:46 | <wanderview> | JakeA: console for SW patch just pushed to the project branch... so in theory should be supported in that download later today or tomorrow |
| 14:48 | <JakeA> | ohh, that's brilliant |
| 14:51 | <pikaren> | which browser vendor honor whatwg html5 the most? |
| 14:53 | <jgraham> | Browser vendors have honour? |
| 14:54 | <jgraham> | pikaren: By which I mean, that doesn't make much sense as a question |
| 14:54 | <JonathanNeal> | Domenic: https://github.com/promises-aplus/promises-tests/blob/master/lib/tests/2.2.1.js#L30 why are we checking non-functions for fulfilled on a rejected promise? |
| 14:55 | <JonathanNeal> | I’m trying to understand this part of the chaining process. It’s broken in my current Promise polyfill. |
| 15:16 | <rubys> | MikeSmith: here is a self-contained (no dependencies) punycode library: https://github.com/bestiejs/punycode.js/ |
| 15:16 | <rubys> | annevk: thanks for the pointer to https://github.com/inexorabletash/text-encoding |
| 15:46 | <JonathanNeal> | Ah, figured out chaining. Woohoo!! |
| 15:46 | <caitp> | right on |
| 15:47 | <JonathanNeal> | Wow, everything passes. Woohoo! |
| 15:47 | <caitp> | isn't that just the best feeling? |
| 15:48 | <JonathanNeal> | Yes, like getting one of those tall pieces in Tetris. |
| 16:06 | <annevk> | rubys: it's not really clear to me how you're implementing http://www.unicode.org/reports/tr46/#ToASCII in idna.js |
| 16:07 | <annevk> | rubys: or www.unicode.org/reports/tr46/#Processing for that matter |
| 16:08 | <annevk> | ugh, address bar copy and paste is really terrible these days |
| 16:13 | <rubys> | annevk: take a look at https://github.com/rubys/url/blob/peg.js/url.pegjs#L603 |
| 16:13 | <annevk> | rubys: yeah that looks wrong |
| 16:13 | <rubys> | annevk: explain? |
| 16:14 | <annevk> | rubys: you're running something called processing_map whereas the spec calls for running domain to ASCII |
| 16:15 | <rubys> | domain to ASCII has a number of steps. I believe I implement those steps, but I unwrap them a bit so that I can do better error reporting. |
| 16:15 | <annevk> | rubys: should domain to ASCII be part of the IDNA module? |
| 16:16 | <rubys> | example: I now report conformance errors if IDNA ignore characters are encountered |
| 16:17 | <rubys> | I could refactor that logic into the IDNA module, sure. I would like to retain the ability to detect conformance errors. |
| 16:18 | <annevk> | rubys: I guess you removed the optional bits that the URL Standard not ended up using |
| 16:18 | <rubys> | Meanwhile, if you could identify where this logic is wrong, I will try to fix. |
| 16:18 | <rubys> | My goal at the moment is to implement the URL standard. In the process, I'm iteratively implementing more and more of the underlying dependencies. |
| 16:19 | <rubys> | well, implementing is too strong a word… implementing or incorporating implementations. |
| 16:19 | <annevk> | What is your plan for the conditional domain to Unicode step? |
| 16:20 | <mathiasbynens> | rubys: https://github.com/mathiasbynens/todo/issues/9 |
| 16:20 | <JakeA> | annevk: If I open a tab, enter a url & go, is that request "no-cors"? |
| 16:21 | <annevk> | rubys: http://intertwingly.net/projects/pegurl/idna.js what I cannot find here e.g. is "xn--" while http://www.unicode.org/reports/tr46/#Processing definitely calls for that |
| 16:21 | <annevk> | JakeA: yeah |
| 16:22 | <rubys> | annevk: can you identify a test that requires that step? |
| 16:23 | <JakeA> | annevk: I think we've regressed on being able to provide another site's HTML in response to a navigation |
| 16:23 | <JakeA> | dunno if our implementation has |
| 16:23 | <annevk> | rubys1: http://xn--†/ or some such? |
| 16:23 | <annevk> | JakeA: you'll have to elaborate a bit |
| 16:25 | <JakeA> | annevk: I satisfy a request to evil.com with a response from example.com. I now have the content of example.com executed in the origin of evil.com |
| 16:26 | <JakeA> | annevk: if that includes something like a <script src> I'll pick that up again, and inject scripts that can inspect the content |
| 16:26 | <annevk> | JakeA: you'll have to elaborate more, e.g. what document is currently loaded, what SW is in effect |
| 16:26 | <JakeA> | annevk: I own evil.com, user visits, I install sw at /sw.js |
| 16:27 | <JakeA> | annevk: User visits evil.com again (or I force a refresh), I catch the request in the sw, and respondWith(fetch('//example.com', {mode: 'no-cors'})) |
| 16:28 | <annevk> | JakeA: ah yeah, I was expecting the Navigate algorithm to catch that |
| 16:29 | <annevk> | JakeA: perhaps navigate is always same-origin? |
| 16:29 | <annevk> | JakeA: navigation is a bit of a special case... |
| 16:30 | <JakeA> | annevk: that would fix it, although I should still be able to satisfy navigates with new Response, CORS requests are fine too |
| 16:31 | <JakeA> | annevk: Maybe navigates are CORS? |
| 16:31 | <JakeA> | no that doesn't work |
| 16:31 | <annevk> | perhaps we need mode=navigate |
| 16:31 | <annevk> | hmm |
| 16:32 | <annevk> | CORS doesn't work |
| 16:32 | <annevk> | Somewhere we need additional logic |
| 16:32 | <annevk> | "Just" have to decide where and what it should be |
| 16:32 | <JakeA> | Yeah, I was about to file that fetch bug about the contexts, and I was thinking "what we actually need is mode=navigate, didn't we have that to stop…" etc etc |
| 16:35 | <JakeA> | Is clicking a link a navigation? |
| 16:35 | <JakeA> | Even if it responds content-disposition? |
| 16:36 | <annevk> | JakeA: clicking a link invokes navigate |
| 16:37 | <JakeA> | annevk: mode=navigation would work then |
| 16:37 | <JakeA> | trying to figure out if we need it for sharedworker too |
| 16:38 | <JakeA> | I think we do |
| 16:38 | <JakeA> | not as much is exposed |
| 16:38 | <annevk> | JakeA: content-disposition however doesn't create a new Window |
| 16:38 | <annevk> | JakeA: it's treated as a download |
| 16:39 | <annevk> | JakeA: so basically when you click a link, navigate is invoked, which waits for the response to decide what to do |
| 16:39 | <annevk> | JakeA: sharedworker is always same-origin iirc |
| 16:41 | <JakeA> | annevk: if we know something is a navigation, we may not need that context group |
| 16:50 | <annevk> | JakeA: sure, but sharedworker isn't really a navigation |
| 16:50 | <annevk> | JakeA: it doesn't invoke navigate, for instance |
| 16:50 | <annevk> | JakeA: it does get its own SW and CSP |
| 16:50 | <annevk> | JakeA: and it does need mode=same-origin to do the right thing |
| 16:51 | <annevk> | JakeA: SW is similar, it gets its own CSP, it's the one thing that goes without SW, and it also needs mode=same-origin |
| 16:52 | <annevk> | JakeA: so we need some amount of orthogonality, and some amount of grouping |
| 16:53 | <annevk> | JakeA: see also this email that went unanswered: http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0120.html |
| 16:53 | <annevk> | Hixie: ^ that email was also addressed towards you |
| 16:59 | <JakeA> | annevk: I guess we could still have a group for navigates + sharedworker |
| 17:00 | <annevk> | JakeA: I think same-origin for navigation is not so bad |
| 17:00 | <JakeA> | annevk: Being able to expose mode=navigate to JS would be great. It's important when it comes to the type of fallback to display |
| 17:00 | <rubys> | annevk: https://github.com/rubys/url/blob/peg.js/url.pegjs#L646 is where xn-- is added |
| 17:01 | <JakeA> | annevk: does `new Response("Hello!")` count as same-origin? |
| 17:02 | <annevk> | JakeA: I think a synthetic response would also be same-origin, yes |
| 17:02 | <annevk> | always, even |
| 17:03 | <JakeA> | annevk: The alternative is https://fetch.spec.whatwg.org/#http-fetch 2.2.3 if request is navigate and response is opaque, fail |
| 17:03 | <JakeA> | (which allows CORS responses) |
| 17:04 | <rubys> | mathiasbynens: have you seen https://github.com/rubys/url/tree/peg.js/reference-implementation and http://intertwingly.net/projects/pegurl/liveview.html ? |
| 17:06 | <annevk> | JakeA: I think there is some sense in allowing a stored CORS response to a same-origin request |
| 17:06 | <JonathanNeal> | The order or timing in which Promises fire in Firefox and Chrome are pretty inconsistent. |
| 17:06 | <annevk> | JakeA: just have to make sure not to lose the masking |
| 17:07 | <annevk> | JonathanNeal: JavaScript <> HTML haven't worked out the spec for timing |
| 17:07 | <JonathanNeal> | Once started, Firefox moves through a promise chain synchronously. |
| 17:07 | <JonathanNeal> | Or at least, that’s how it appears to be when compared to Chrome. |
| 17:07 | <Hixie> | annevk: i don't understand the question in that e-mail |
| 17:08 | <annevk> | :-( |
| 17:08 | annevk | tried to be very elaborate for once |
| 17:08 | <annevk> | Hixie: actually, the question is just "Thoughts?" |
| 17:08 | <Hixie> | then the answer is "no" :-) |
| 17:08 | <Hixie> | i don't have the service workers stuff paged in |
| 17:09 | <Hixie> | the statement "Since you cannot message to a dedicated worker from anything but the" seems false |
| 17:09 | <Hixie> | environment that created it |
| 17:09 | <Hixie> | er |
| 17:09 | <Hixie> | mispaste |
| 17:09 | <Hixie> | but anyway |
| 17:09 | <Hixie> | that bit is wrong |
| 17:10 | <Hixie> | but fundamentally i don't understand the problem in that e-mail |
| 17:10 | <annevk> | Hixie: e.g. could you have multiple Worker objects in different environments communicating with the same DedicatedWorkerGlobalScope? |
| 17:10 | <Hixie> | sure |
| 17:10 | <Hixie> | MessagePorts lets anyone communicate with anyone |
| 17:11 | <Hixie> | just vend a port and send it along to the other place |
| 17:11 | <Hixie> | via as many other ports as you need |
| 17:11 | <annevk> | Hixie: I thought that the ports setup by new Worker() was a 1:1 channel |
| 17:11 | <Hixie> | that port is, but you can send others through it |
| 17:11 | <Hixie> | there's nothing special about that port other than that you can't get a hold of it from script directly |
| 17:12 | <Hixie> | the context that i'm missing in that e-mail is why we care about "clients" at all |
| 17:12 | <annevk> | The question is basically whether DedicatedWorker should be treated as a slave of its environment or more of an independent entity |
| 17:13 | <Hixie> | why treat it as either? |
| 17:13 | <Hixie> | what does it mean to treat it as either? |
| 17:13 | <wanderview> | JakeA: do we need to do anything if the SW script remains the same, but one of its importScript() resources changes? as far as I can tell the spec doesn't check for that... so you have to change the SW script itself to get updates to your importScripts... correct? |
| 17:13 | <annevk> | Hixie: a service worker exposes the environments it handles fetches for |
| 17:13 | <Hixie> | why |
| 17:13 | <Hixie> | how? |
| 17:13 | <annevk> | Hixie: can't we just assume that it does? |
| 17:13 | <Hixie> | what does that mean |
| 17:13 | <Hixie> | the environment is the global object? |
| 17:13 | <annevk> | Hixie: whenever a new fetch comes in, there's some object that allows communicating back with the environment |
| 17:14 | <Hixie> | ok... |
| 17:14 | <Hixie> | so why is a worker any different than a Window here? |
| 17:14 | <Hixie> | i don't get the problem here |
| 17:14 | <annevk> | Hixie: well, SharedWorker is designed to be connected with multiple environments |
| 17:14 | <annevk> | Hixie: a dedicated worker is not |
| 17:15 | <Hixie> | no |
| 17:15 | <annevk> | Hixie: but I can see how a Window isn't either |
| 17:15 | <Hixie> | sharedworker and dedicatedworker and window are all identical in the regard of how they communicate to service workers |
| 17:15 | <Hixie> | sharedworker is like dedicatedworker, except that when a new connection _from a SharedWorker object_ comes in, you get a 'connect' event |
| 17:15 | <Hixie> | but you wouldn't want that event to be used for service workers |
| 17:15 | <Hixie> | that would make no sense |
| 17:16 | <Hixie> | shared workers and dedicated workers are both able to communicate with multiple environments |
| 17:16 | <annevk> | Thanks |
| 17:16 | <Hixie> | the only difference is that when you create a dedicated worker, you get back a new one, and when you create a shared worker, you get back the existing one if it's already there |
| 17:17 | <annevk> | You're right, I'm not sure why I was being silly |
| 17:18 | <annevk> | Not sure it's a good sign that nobody else noticed... or maybe they get bored of telling me |
| 17:19 | <annevk> | JakeA: ^^ is good material for sorting out the client stuff |
| 17:20 | <Hixie> | what kinds of communication are you expecting btw? between service workers and whoever is making a particular request? |
| 17:26 | <JakeA> | wanderview: correct |
| 17:26 | <wanderview> | thanks! |
| 17:27 | <JakeA> | Hixie: if you were going to polyfill something like client headers you may want to have a conversation about image size |
| 17:28 | <Hixie> | if the only use case is polyfill, then i'd drop it entirely. |
| 17:28 | <Hixie> | but i don't understand what client headers means in this context |
| 17:28 | <Hixie> | and i don't understand how you imagine this conversation would procede |
| 17:28 | <JakeA> | JakeA: or maybe just signal "hey, that thing I send you from the cache, well I make a network request for it too and found an update" |
| 17:28 | <Hixie> | can you elaborate? |
| 17:28 | <JakeA> | Didn't mean to reply to myself |
| 17:29 | <Hixie> | how do you expect to identify "that thing"? |
| 17:30 | <JakeA> | Hixie: isn't it part of the extensible web to allow polyfills? |
| 17:30 | <Hixie> | "extensible web"? |
| 17:31 | <Hixie> | you mean, "the web"? |
| 17:31 | <JakeA> | Hixie: maybe sending the window width or pixel density as a header |
| 17:32 | <JakeA> | Hixie: well it's certainly not extensible if we remove stuff from the spec because it only supports polyfilling potential future behaviours |
| 17:33 | <Hixie> | well a worker isn't going to know the pixel density. so you'd have to talk to a window for that, even if the client is the worker. so talking to a client doesn't help. |
| 17:33 | <Hixie> | imho, if something is polyfillable then we shouldn't be speccing it. |
| 17:33 | <Hixie> | and if something isn't truly polyfillable then we should just ship it and not waste authors' time with making them polyfill it. |
| 17:35 | <MikeSmith> | annevk: I'll do the rest of that PR (the gbk tests part) after a few hours |
| 17:35 | <MikeSmith> | s/do/review |
| 17:35 | <JakeA> | Hixie: no, but having some request clients have different methods would be surprising. Especially if there's no reason we can't post message to a particular type |
| 17:36 | <Hixie> | not sure what you're responding to there |
| 17:37 | <JakeA> | "a worker wouldn't know the pixel density" |
| 17:37 | <Hixie> | i didn't suggest anything having methods at all, let alone different ones |
| 17:37 | <Hixie> | so i don't follow |
| 17:38 | <JakeA> | I want to expose the request client so you can see its type and postmessage to it |
| 17:38 | <Hixie> | how would the client associate these incoming service worker messages with requests? |
| 17:39 | <JakeA> | Data sent with the postmessage |
| 17:40 | <JakeA> | There may be ambiguity linking it to the particular image element, that's fair. But window width & density shouldn't be an issue |
| 17:41 | <Hixie> | your solution doesn't address window width and density |
| 17:41 | <Hixie> | you'd need to find a request that came from a Window so you could ask it for the density (and hope that Window is on the same screen as the canvas that the dedicated worker that asked for the image is going to later have its data painted onto) |
| 17:42 | <Hixie> | and for the update use case, if you can't associate it to a particular image element, what's the client supposed to do? |
| 17:42 | <Hixie> | for the use cases you've given, the solution you've given seems suboptimal. |
| 17:43 | <Hixie> | i would recommend a different approach. First, have all the potential clients have a way to contact the service worker directly, similar to how shared workers work. |
| 17:43 | <Hixie> | second, have Fetch include a port to the service worker associated with that fetch |
| 17:44 | <JakeA> | In this case, the worker would respond "I don't know the pixel density, I'm a worker, assume [fallback]" |
| 17:44 | <Hixie> | so if you want to be notified of out-of-band data for a request, you use Fetch |
| 17:44 | <Hixie> | that response would be terrible |
| 17:44 | <Hixie> | why not just have the window send the service worker the right answer. |
| 17:44 | <JakeA> | In the update case can't you assume all elements using that url? |
| 17:45 | <Hixie> | you want the client to crawl its DOM doing URL checks? that's a pretty bad API |
| 17:46 | <JakeA> | All clients already can contact the SW |
| 17:46 | <JakeA> | "have Fetch include a port to the service worker associated with that fetch" I don't understands this. |
| 17:47 | <JakeA> | How would that surface in the API? |
| 17:47 | <Hixie> | when you do new Fetch() |
| 17:48 | <Hixie> | you expose fetch.port |
| 17:48 | <Hixie> | and on the service worker side, a fetch that corresponds to a Fetch has a port on it |
| 17:48 | <JakeA> | That will always be navigator.serviceWorker.controller |
| 17:48 | <Hixie> | ? |
| 17:49 | <JakeA> | navigator.serviceWorker.controller is a reference to the worker the page will send requests to. It has postMessage |
| 17:49 | <Hixie> | no i mean a _new_ port |
| 17:49 | <Hixie> | specifically for that fetch |
| 17:50 | <Hixie> | new Fetch().port != new Fetch().port |
| 17:50 | <JakeA> | Oh ok, what wouldn't work for <img> |
| 17:50 | <Hixie> | right this would only be for Fetch |
| 17:50 | <Hixie> | if you want updates, you do it via Fetch |
| 17:50 | <Hixie> | maybe later if we expose the Fetch of images, it gets exposed there too |
| 17:52 | <JakeA> | Hmm, that could work well for progress stuff too |
| 17:53 | <JakeA> | Although the SW can enumerate its clients and send them messages |
| 17:53 | <JakeA> | I wanted those objects to be the same as request.client |
| 17:53 | <JakeA> | Seems weird to make them different |
| 17:54 | <Hixie> | imho request.client shouldn't exist |
| 17:54 | <Hixie> | exposing clients leads to bad patterns |
| 17:54 | <Hixie> | similar to ambient authority |
| 17:54 | <Hixie> | basically you get confused deputy issues |
| 17:55 | <Hixie> | consider an implementation where there's just a Window that does all requests |
| 17:55 | <Hixie> | and then one day, the code is refactored so that some requests are actually done from a worker |
| 17:55 | <Hixie> | it shouldn't change anything |
| 17:55 | <Hixie> | but it does |
| 17:56 | <JakeA> | Feels like we should expose as much about the request as we can safely expose, and treat devs like adults |
| 17:56 | <Hixie> | you don't give an untrained adult a loaded gun with the safeties off |
| 17:57 | <Hixie> | or to put it another way: guardrails on balconies aren't just for children |
| 17:57 | <annevk> | MikeSmith: thanks |
| 17:57 | <JakeA> | Which would include the type of client, it's visibility state on request, its url |
| 17:57 | <Hixie> | imho that's making the same mistake that was made by cookies |
| 17:58 | <Hixie> | the model used by capabilities is way more sensible |
| 17:59 | <annevk> | I like the idea of exposing Request.port |
| 17:59 | <annevk> | or some such, if we need it |
| 17:59 | <annevk> | makes more sense since you can actually negotiate things about the request with the party that initiated it |
| 18:00 | <JakeA> | Yep |
| 18:02 | Hixie | discovers that a mail filter for "Subject: * deadline *" on standards lists reliably catches only pointless e-mail |
| 18:02 | <annevk> | heh |
| 18:02 | <annevk> | JakeA: perhaps we should reconsider the clients model |
| 18:04 | <JakeA> | annevk: we still need it for interaction post push message, but will reconsider it for reqiest |
| 18:05 | <JakeA> | annevk: and announcing updates |
| 18:09 | <annevk> | jgraham: is there some way to require TLS for a test? |
| 18:10 | <jgraham> | annevk: Not for a top level page at the moment |
| 18:10 | <annevk> | jgraham: that seems problematic |
| 18:10 | <jgraham> | You can use an iframe or window.open a tlbc for the moment |
| 18:10 | <jgraham> | (also tls doesn't work at all until someone reviews my changes |
| 18:10 | <jgraham> | ) |
| 20:52 | <caitp> | annevk, is it noted in the xhr spec anywhere that people might want to some day get rid of synchronous requests? if that's ever feasible... I just want to have something (other than https://www.w3.org/Bugs/Public/show_bug.cgi?id=24790) to discourage people from using it |
| 20:52 | <caitp> | well, doesn't matter I guess |
| 20:54 | <zcorpan> | caitp: https://xhr.spec.whatwg.org/#sync-warning |
| 20:54 | <caitp> | not quite a deprecation notice, just a warning of why it's a bad idea |
| 20:54 | <caitp> | i guess that works though |
| 21:02 | <rniwa> | wycats: yt? |
| 21:28 | <zcorpan> | caitp: what would you expect from a deprecation notice? |
| 21:28 | <caitp> | it would be nice to have a hardline "we want to get rid of this" |
| 21:28 | <caitp> | even if it was in the spec rather than in implementations, that would be awesome |
| 21:29 | <caitp> | because then whenever anyone asks for it (and they do :() I could say "hey look over there, it's gonna be gone in 6 months, so we can't" even if I know that's not really true |
| 21:29 | <zcorpan> | caitp: isn't that what the second sentence says? |
| 21:30 | <caitp> | it's definitely a discouragement |
| 21:30 | <caitp> | but it's maybe not a hard "no" |
| 21:30 | <zcorpan> | it says browsers are encouraged to throw so the feature can be removed |
| 21:30 | <zcorpan> | the first sentence says authors must not use it |
| 21:30 | <zcorpan> | i don't understand what you're missing |
| 21:32 | <caitp> | > when the JavaScript global environment is a document environment |
| 21:32 | <caitp> | ^--- this statement doesn't mean anything to non-implementors |
| 21:33 | <caitp> | most people won't even interpret that as a "this doesn't apply to workers" |
| 21:33 | <caitp> | "as it has detrimental effects to the end user's experience" <<< a lot of people think they have reasons to use it in spite of that --- so it's definitely good that it's there, but they still think they know better |
| 21:34 | <caitp> | "encouraged to warn about such usage in developer tools and may experiment with throwing" <<< not really normative, not a strong statement |
| 21:35 | <caitp> | all I'm saying is it would be nice to have a strong statement against it |
| 21:35 | <caitp> | there are some in bugs, but it's hard to get people to look at those |
| 21:37 | <zcorpan> | caitp: what do you think of https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents ? |
| 21:38 | <caitp> | that's a lot nicer, and in cases where there are actually threads on removing them from the platform, you can link people to them so they can get the anger off their chests |
| 21:39 | <zcorpan> | technically it's weaker since it doesn't have anything normative. but i can see that it's easier to understand the message |
| 21:39 | <caitp> | just my opinion, though, it's up to you guys on the xhr thing --- it would just be a bit easier for for me |
| 21:40 | <zcorpan> | annevk: ^ |
| 21:45 | <annevk> | caitp: zcorpan: thanks, let's try to fix that now |
| 21:56 | <annevk> | caitp: zcorpan: https://xhr.spec.whatwg.org/#sync-warning |
| 21:58 | <caitp> | that looks good :) |
| 21:58 | <caitp> | that oughta shut em up... I mean, convince them that they don't need to be able to do that** |
| 21:58 | <zcorpan> | annevk: the second sentence now has two "therefore"s |
| 21:59 | <caitp> | it does? |
| 21:59 | <annevk> | http://portal.cs.oag.state.tx.us/OAGStaticContent/portal/login/help/listPasswordRules.htm and no TLS |
| 21:59 | <annevk> | what the fuck |
| 21:59 | <zcorpan> | well one therefore and one as |
| 21:59 | <annevk> | (via Twitter) |
| 22:00 | <zcorpan> | annevk: maybe put "as it has detrimental effects to the end user's experience" in the first sentence? |
| 22:02 | <annevk> | zcorpan: thanks, done |
| 22:02 | <zcorpan> | lgtm |
| 22:10 | <heycam> | zcorpan, ack |
| 22:11 | <annevk> | heycam: 1) are you free to work on IDL bugs again? 2) will be in Portland? |
| 22:12 | <heycam> | annevk, yes, though so far this week I've been catching up on bugs. and yes. |
| 22:13 | <heycam> | annevk, haven't read mailing list mail / w3c bugs yet |
| 22:13 | <annevk> | heycam: twice awesome |
| 22:14 | <annevk> | heycam: enjoy |
| 22:14 | <heycam> | yeah always my favourite part of returning :/ |
| 22:14 | <annevk> | heycam: I've been working on the associated Realm thing with bz |
| 22:15 | <annevk> | heycam: https://github.com/w3c/web-platform-tests/pull/1381 has a bunch of tests for the near empty WebIDL directory |
| 22:15 | <heycam> | annevk, oh cool, so this will replace the "associated ECMAScript global environment" wording? |
| 22:15 | <annevk> | heycam: haven't gotten quite that far yet |
| 22:15 | <annevk> | heycam: mostly figuring out what the status quo is |
| 22:15 | <heycam> | annevk, ok. tbh I never looked into what the ES6 spec did with Realms and how useful/realistic they are. |
| 22:16 | <annevk> | well they're a match for ES |
| 22:16 | <annevk> | but platform is more complicated :-( |
| 22:16 | <annevk> | so we have the current Realm, the entry settings object, and the incumbent settings object |
| 22:17 | <annevk> | and then specification writers have to make sure to pick the right one for base URLs, origins, etc. |
| 22:17 | <annevk> | hint: doesn't work |
| 22:17 | <heycam> | what a pain |
| 22:17 | <heycam> | seeing tests for this stuff will be awesome though! |
| 22:18 | <annevk> | yeah, so hopefully we can figure out what we want the default setup to be going forward, make that easy, and then prefix the rest with legacy or some such |
| 22:18 | <heycam> | sounds great |
| 22:19 | <heycam> | erm |
| 22:19 | <heycam> | where did my Web IDL tests go? |
| 22:19 | <annevk> | heycam: are they still in a pull request? |
| 22:19 | <heycam> | annevk, oh yeah that's right |
| 22:19 | <heycam> | annevk, I never addressed plh's/dom's comments |
| 22:22 | <annevk> | heycam: gotta go, guess we'll talk later about the open issues once you've caught up |
| 22:22 | <heycam> | annevk, cool, ttyl |
| 23:20 | <MikeSmith> | gb18030 is nuts |
| 23:21 | <jgraham> | or gblboeo as I call it |
| 23:23 | <MikeSmith> | heh |