| 02:18 | <MikeSmith> | Hixie: not that it matters much but I think you flagged https://www.w3.org/Bugs/Public/show_bug.cgi?id=27149 as a duplicate of the wrong bug |
| 02:19 | <MikeSmith> | ah I see why |
| 02:19 | <MikeSmith> | I'll fix it |
| 07:41 | <annevk> | Domenic: it seems I had not read the actual proposal, that does seem like an amazing outcome |
| 07:41 | <annevk> | Domenic: my bad |
| 07:47 | <JakeA> | annevk: if I make a forced-preflight fetch, but there's no non-basic method or headers, I don't get a preflight? |
| 07:49 | <annevk> | JakeA: you can't make a forced-preflight fetch |
| 07:50 | <JakeA> | annevk: fair |
| 07:51 | <annevk> | forced preflight only exists for some event listener thing from XMLHttpRequest |
| 07:51 | <annevk> | perhaps we also require it if you pass an actual stream to new Request |
| 07:51 | <annevk> | as that would effectively be the same thing |
| 07:51 | <JakeA> | (someone suggested it as a way to do SW security, not entertaining the idea but wanted to explain fully) |
| 07:52 | <annevk> | although... request needs to make a copy of that data... |
| 07:53 | <annevk> | JakeA: we might want to investigate at some point if we want a fail-on-redirect option or no-clone option for a request's stream |
| 07:53 | <annevk> | JakeA: due to redirects and authentication you might end up submitting the request body several times, which doesn't seem very optimal for perf if you're uploading 50GiB of 4K video or some such |
| 07:54 | <annevk> | JakeA: I'm not sure what SW security means |
| 07:54 | <annevk> | JakeA: note that from a specification layer you can make a forced-preflight fetch |
| 08:12 | <JakeA> | annevk: fail-on-redirect sounds like a good solution there. Or no-buffer, which would prevent cloning and implicit buffering from redirects |
| 08:13 | <JakeA> | annevk: By SW security I mean the whole path vs header debate |
| 08:13 | <annevk> | Are we still tracking the addition of streams in an issue somewhere? We should mention this there |
| 08:13 | <annevk> | JakeA: ah okay, then a forced-preflight would not work, since this is same-origin |
| 08:14 | <annevk> | JakeA: unless you say the request origin is null, but that would be a super weird way to get hold of a SW |
| 08:15 | <JakeA> | annevk: yeah http://jakearchibald.com/2014/launching-sw-without-breaking-the-web/#comment-1651245375 |
| 08:16 | <annevk> | FWIW, I really like the tie it to the origin idea |
| 08:16 | <annevk> | I have liked that since the start, I'm not sure why I didn't push for it. I thought it wasn't in the cards |
| 08:17 | <JakeA> | Tie it to the origin? |
| 08:18 | <annevk> | Use origin instead of scopes |
| 08:18 | <JakeA> | annevk: does that mean I can only have one SW per origin? |
| 08:19 | <JakeA> | I guess it must |
| 08:20 | <JakeA> | Scoping has been really useful for demos on https://jakearchibald.github.io/isserviceworkerready/ and seperate sites like https://jakearchibald.github.io/trained-to-thrill/ |
| 08:22 | <annevk> | Yeah, but let actual scoping solve that problem |
| 08:22 | <annevk> | I.e. suborigins |
| 08:25 | <annevk> | It simplifies service workers a lot and puts the complexity of scoping on suborigins, which can provide actual security benefits |
| 08:26 | <JakeA> | Github pages (and googledrive, and localhost) were the sweetener to the https requirement. I don't like things which throw those out (hence my fighting over the path stuff) |
| 08:28 | <annevk> | They are not thrown out, you can just experiment with a single service worker on them |
| 08:29 | <annevk> | (until suborigins) |
| 08:30 | <MikeSmith> | has some agreement emerged yet on the path thing |
| 08:30 | <annevk> | https://adactio.com/journal/7706 did someone tell adactio about service workers? Since you'll end up duplicating quite a bit of your server code |
| 08:31 | <annevk> | MikeSmith: depends more on https://github.com/slightlyoff/ServiceWorker/issues/445 at this point; Mozilla is not interested in shipping the current API as is |
| 08:31 | MikeSmith | looks |
| 08:35 | <annevk> | http://alistafart.com/ |
| 08:36 | <MikeSmith> | "worth making a breaking change for" |
| 08:36 | <MikeSmith> | doesn't seem like anything's strictly a breaking change at this point |
| 08:36 | <MikeSmith> | yet |
| 08:38 | <annevk> | MikeSmith: hence depends, but I'm pretty sure that unless we come to some agreement Firefox will break |
| 08:38 | <annevk> | MikeSmith: we said as much on blink-dev |
| 08:38 | <MikeSmith> | yeah I read that blink-dev thread too |
| 08:39 | <MikeSmith> | including https://groups.google.com/a/chromium.org/d/msg/blink-dev/QfxPGw0kJW8/mpvlkZR-AxwJ from Eric Seidel |
| 08:39 | <MikeSmith> | "The risk is high that we'll end up needing to support a spec-incompatible implementation." |
| 08:41 | <MikeSmith> | anyway, I can see it's some exceptionally difficult problems to sort out |
| 08:43 | <annevk> | It's not easy to deploy complex new technology quickly |
| 08:44 | <annevk> | And I doubt anyone would label this as quick |
| 08:44 | <annevk> | E.g. when I said 18 months ago or so this would take at least a year I was laughed at |
| 08:45 | <boogyman> | it will take another 6-10 yrs to become mainstream too. |
| 08:55 | <JakeA> | annevk: If scope is always the whole origin, github is no longer a viable place to host independant serviceworker projects |
| 08:56 | <JakeA> | localhost becomes awkward |
| 09:05 | <JakeA> | annevk: adactio's seem me speak about ServiceWorker at least twice |
| 09:07 | <JakeA> | m.lanyrd.com works offline but also with server rendering. It follows a fairly simple model of urls with data objects & templates. The templating system is mustache so works in obj-C for the ios app, java for android, js for clientside, python for service side |
| 09:07 | <JakeA> | of course, each mustache implementation had its own quirks |
| 09:07 | <JakeA> | so it was a bit of a ballache |
| 09:09 | <JakeA> | If I were developing twitter.com in 5 years, I'd probably make the logged-in timeline view entirely client-side. You only get there 2nd visit, so ServiceWorker can give you better performance than server-rendering |
| 09:09 | <JakeA> | For individual tweets, server rendering may still have a benefit for first load |
| 09:10 | <JakeA> | Same for the logged-out root |
| 09:10 | <JakeA> | Progressive enhancement in terms of connectivity is more valuable than PE in terms of JavaScript |
| 09:46 | <JakeA> | sicking: thanks for the detailed post on the generality thing |
| 09:55 | <MikeSmith> | JakeA: fwiw I've read at lot of the SW issue discussions and I think you're doing a stellar job of representing the web-developer concerns/priorities and of trying to find solutions that'll work. Getting this stuff right is obviously pretty important. |
| 10:05 | <JakeA> | MikeSmith: oh thanks! I guess I haven't been devrel long enough to forget what it's like to be a developer. Give it 6 months. |
| 10:05 | <MikeSmith> | heh |
| 10:31 | <annevk> | JakeA: yeah, the end game is more about perf |
| 10:31 | <annevk> | JakeA: I can see how it's a bit disconcerting though that the client side is no longer HTML and some JavaScript sprinkled on top |
| 10:33 | <JakeA> | annevk: I do think that one of the benefits of SW is "ajaxing" a page change is no longer a huge performance benefit |
| 10:33 | <JakeA> | especially if we get some way to transition between navigations |
| 10:34 | <JakeA> | because "ajax" navigations are a pain in the hole to get right |
| 10:36 | <annevk> | I just realized there's some issues now we figured out that dedicated workers are not clients |
| 10:37 | <annevk> | Fetch uses client for other things, such as CSP and Referer |
| 10:37 | <annevk> | Referer we could probably solve, but not CSP |
| 10:37 | <annevk> | Ugh :-( |
| 10:38 | <JakeA> | Is it easier to find a way to postMessage into dedicated workers from outside the document? |
| 10:38 | <annevk> | I don't know |
| 10:39 | <annevk> | The problem is that if a dedicated worker does a Fetch, SW wants to see the environment settings object from a document, whereas Fetch also needs the environment settings object from the dedicated worker |
| 10:43 | <JakeA> | If ServiceWorker can postMessage to a document's dedicated worker, then I'm happy for SW to see the dedicated worker as the request client (or some kind of proxy to it) |
| 10:45 | <annevk> | JakeA: I will email the relevant people |
| 10:45 | <annevk> | At least, if I can write out a decent enough problem statement |
| 10:46 | <JakeA> | annevk: we could even make postMessage to those fail, but I'm nervous of .client & getAll() getting wildly different APIs depending on client type |
| 10:48 | <annevk> | JakeA: either we should just expose them as a document (but with a different Referer and CSP policy...) or we should expose them as a worker without a channel and perhaps a pointer to the associated document? |
| 10:48 | <annevk> | JakeA: all of these require some amount of refactoring |
| 10:49 | <annevk> | JakeA: so I'll write up the known facts so everyone can think about them |
| 10:54 | <MikeSmith> | annevk: data:text/html;charset=utf-8,<!DOCTYPE%20html>%0A<style>%0A%20body%2C%20html%20%7B%20ma…<span>Qual%20Match%2037<%2Fspan>%20<span>Friday%2014%3A21<%2Fspan>%0A<%2Fdiv> is not a valid URL per spec, right? Because "<" and ">" are not URL code points. |
| 11:17 | <annevk> | MikeSmith: yeah |
| 11:18 | <annevk> | MikeSmith: I only changed a few things relative to RFC 3987 (likely mistakes), but have not changed conformance relative to RFC 3986 I think |
| 11:18 | <annevk> | MikeSmith: we could at some point, though we should probably be careful |
| 11:24 | <MikeSmith> | annevk: Ok, thanks |
| 11:26 | <MikeSmith> | I guess I need to file a bug against the source of the HTML spec, since Hixie's using that URL on the source |
| 11:27 | <MikeSmith> | also, data URL kitchen generates URLs with raw "<" and ">" |
| 11:33 | <annevk> | MikeSmith: yeah, I know the current set of restrictions is somewhat annoying |
| 11:34 | <annevk> | MikeSmith: we could have a distinct conformance class for URLs in HTML attribute values |
| 11:34 | <annevk> | MikeSmith: but I don't really want to get into that before we actually have conforming URL parsers |
| 11:40 | <MikeSmith> | annevk: yup |
| 12:00 | <rubys> | For discussion purposes: http://intertwingly.net/projects/pegurl/url.html |
| 12:02 | <annevk> | rubys: I thought the productions were for non-normative purposes? |
| 12:03 | <rubys> | When we last talked, I hadn't decided. I'm now proposing that they be normative. |
| 12:03 | <annevk> | rubys: I'm not a fan |
| 12:04 | <annevk> | This also heavily regresses my IDNA work |
| 12:07 | <annevk> | rubys: also, username/password together is userinfo; userinfo + host + port is authority |
| 12:07 | <annevk> | rubys: at least if you follow the original RFCs |
| 12:08 | <rubys> | that can be fixed |
| 12:13 | <annevk> | Alright, first, sorry for being being negative. Thanks for the work. Second, I'm willing to consider this after this evolved a bit to address the obvious mistakes. |
| 12:15 | <rubys> | Please do enumerate the mistakes. I can iterate quickly. |
| 12:16 | <annevk> | rubys: ipv6 needs to be inline |
| 12:16 | <annevk> | rubys: IDNA as mentioned |
| 12:16 | <annevk> | rubys: URL concat needs to be defined |
| 12:16 | <annevk> | rubys: it needs to be clearer about normative requirements |
| 12:18 | <annevk> | rubys: it would help if there was a distinction between properties and variables |
| 12:18 | <annevk> | rubys: e.g. "scheme is set to file" is ambiguous |
| 12:18 | <annevk> | rubys: also, apart from formatting you probably want "Set scheme to file", unless it somehow magically happens |
| 12:19 | <annevk> | rubys: "In the case of a relative-url, the value object to be returned is initialized to the value returned by relative-url, and then modified as follows:" does not make much sense without a description of base URLs |
| 12:20 | <annevk> | rubys: username and password also have their stuff percent-encoded |
| 12:22 | <annevk> | rubys: hopefully this helps |
| 12:23 | <rubys> | it does; and this might be easier on a mailing list, but first: this was not meant to be complete, but as a catalist for exactly this type of discussion. |
| 12:23 | <rubys> | I only have questions on 3 of your first 4 points. |
| 12:24 | <rubys> | 1) why does ipv6 need to be inline? |
| 12:24 | <rubys> | 2) can you expand on your IDNA comment? What tests would this fail? |
| 12:24 | <rubys> | 3) what in my mocked up spec should be non-normative? |
| 12:24 | <annevk> | rubys: the parser should be self-contained |
| 12:25 | <annevk> | rubys: I don't really want to elaborate on IDNA, IDNA is much harder than Punycode, the references in URL should make that clear enough |
| 12:26 | <annevk> | rubys: e.g. you have "Replace all Fullwidth unicode characters (in the range of U+FF01 to U+FF5E with their non-fullwidth equivalents." but normalization is much more complicated |
| 12:27 | <annevk> | rubys: you can't write a spec for URLs based on just 250 tests |
| 12:28 | <rubys> | I agree that the parser should be self-contained. I believe it is. |
| 12:28 | <rubys> | And I agree that this spec needs to be reconciled with, and defer to, the Encoding Living Standard. (and it even says so). |
| 12:30 | <annevk> | IDNA != Encoding Standard |
| 12:30 | <annevk> | I don't see how IPv6 as currently defined is self-contained |
| 12:31 | <annevk> | As for 3) you lack requirements in the form of "must" |
| 12:35 | <annevk> | rubys: query lacks encoding override stuff |
| 12:36 | <rubys> | one thing that would be helpful is more tests. |
| 12:37 | <JakeA> | annevk: Jonas' Alt 2 proposal (https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60362736) does that work for you? Perhaps even allowing scope to be set to null or an empty sequence to opt out of fetch. I could pursue that with Alex and our implementors. |
| 12:53 | <MikeSmith> | rubys: the lack of defined parse errors in this draft of your proposed approach make its hard for me to evaluate for my use case (URL conformance checking) |
| 12:53 | <rubys> | MikeSmith: ack. |
| 12:55 | <rubys> | Just curious, any reason why a URL conformance checker couldn't be in JavaScript? |
| 12:55 | <MikeSmith> | it could be sure |
| 12:55 | <MikeSmith> | rubys: but for my purposes I also need something that works for the command line, for one thing |
| 12:56 | <MikeSmith> | outside of a browser |
| 12:56 | <rubys> | node.js? |
| 12:56 | <MikeSmith> | for http://validator.github.io/validator/ |
| 12:56 | <MikeSmith> | vnu.jar and the other apps that integrate with that |
| 12:57 | <MikeSmith> | e.g., https://github.com/cvrebert/lmvtfy/ and https://github.com/jzaefferer/grunt-html |
| 12:59 | <MikeSmith> | and also really, a checker that integrates into the vnu backend in the same way as other checkers (as a SAX ContentHandler, basically) |
| 12:59 | <rubys> | MikeSmith: so a Java implementation would be preferred? |
| 13:04 | <annevk> | JakeA: haven't had time to review yet |
| 13:05 | <JakeA> | annevk: no worries. I need to get back on talk writing now & the weekend, but let me know & I'll help how I can |
| 13:08 | <MikeSmith> | rubys: yeah, for my purposes a Java implementation would be preferred. Though it's possible to make a Java implementation from a JS implementation, using Rhino. I'm doing that already (in a very limited way) in the vnu code, with TabAtkins' JS CSS tokenizer. |
| 13:09 | <rubys> | Given that I'm making my JS implementation from a grammar and a Ruby implementation, generating a Java implementation too wouldn't be difficult. |
| 13:10 | <MikeSmith> | rubys: to be clear, the code for the URL (error-reporting) parser itself doesn't have to be a ContentHandler. I can wrap a ContentHandler for vnu around pretty much anything |
| 13:10 | <rubys> | Java, at least, has sane classes. JavaScript has a bunch of building blocks that can be used to build class like structures. |
| 13:10 | <MikeSmith> | yeah |
| 13:12 | <MikeSmith> | rubys: basically the only interface I need exposed is something I can use to create a URL object, and to get back any messages reported from the code that creates that object |
| 13:12 | <rubys> | MikeSmith: doable |
| 13:15 | <MikeSmith> | rubys: cool |
| 13:15 | <MikeSmith> | rubys: if you want to peruse the existing vnu code which handles this, see https://github.com/validator/validator/blob/master/syntax/relaxng/datatype/java/src/org/whattf/datatype/IriRef.java#L126 |
| 13:16 | <MikeSmith> | and https://github.com/validator/validator/blob/master/syntax/relaxng/datatype/java/src/org/whattf/datatype/IriRef.java#L173 |
| 13:16 | <annevk> | rubys: I think the problem MikeSmith initially raised is that you dropped the "parse error" bits from the original specification |
| 13:16 | <MikeSmith> | this is using Sebastian Mola's galimatias |
| 13:16 | <MikeSmith> | rubys: yeah, what annevk said |
| 13:17 | <annevk> | rubys: making it impossible to tell whether e.g. "<" occurring at some point is at fault or not |
| 13:17 | <annevk> | rubys: it's important to preserve that |
| 13:17 | <MikeSmith> | with the "parse error" bit you can't create an error-reporting parser |
| 13:17 | <MikeSmith> | *without |
| 13:17 | <rubys> | annevk, MikeSmith: I even said so, right at the top. This is totally in the spirit of "release early and often". I know I can do parse errors, so I focused on what I didn't know. |
| 13:17 | <MikeSmith> | sure, makes sense |
| 13:18 | <rubys> | ... and in the process, I found even more that I didn't know. |
| 13:19 | <rubys> | meanwhile, I'm going to add more notes to the doc as to things that have yet to be done based on this input. |
| 13:19 | <MikeSmith> | rubys: incidentially looking back at that vnu code, I see I'm just catching the GalimatiasParseException that galimatias throws for parse errors, and essentially just passing that on to the vnu error-handling/reporting code |
| 13:19 | <boogy> | rubys: prototype inheritance is drastically different from classical inheritance. |
| 13:20 | <rubys> | boogy: I was on TC39 for many years; nearly became the editor of that spec. |
| 13:20 | <MikeSmith> | rubys: also incidentally if you want some early implementor feedback on your proposed approach, Sebastian Mola would be a good one to ask |
| 13:20 | <MikeSmith> | rubys: https://github.com/smola/galimatias and https://github.com/smola |
| 13:22 | <rubys> | one of the first things I can do is add smola's implementation to http://intertwingly.net/stories/2014/10/16/urltest-results/ |
| 13:42 | <rubys> | http://intertwingly.net/projects/pegurl/url.html#todos |
| 14:07 | <MikeSmith> | rubys: ah yeah that would be great |
| 14:07 | <MikeSmith> | rubys: I believe galimatias conforms to the spec on all the existing tests that are in the wpt repo |
| 14:37 | <annevk> | JakeA: can't things also break if someone has caches = ... or some such? |
| 14:37 | <annevk> | JakeA: assigning to something that returns a collection |
| 14:38 | <JakeA> | annevk: if someone did caches = "blah" wouldn't window.caches simply be "blah"? |
| 14:38 | <annevk> | JakeA: e.g. navigator = "test";w(navigator) returns Navigator |
| 14:39 | <JakeA> | ohh |
| 14:39 | <JakeA> | If there a way to make it overwritable? |
| 14:39 | <JakeA> | Is* |
| 14:41 | <JakeA> | I guess just don't make it [Unforgeable] |
| 14:43 | <JakeA> | Oh, we'd need to make it explicity [Replaceable] |
| 14:43 | <JakeA> | explicitly* |
| 14:43 | <JakeA> | Is there a problem doing that? |
| 14:45 | <annevk> | JakeA: ah yeah, that should probably work |
| 14:50 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/535 |
| 14:52 | <annevk> | ta |
| 14:57 | <wanderview> | is caches on window spec'd yet? |
| 14:58 | <JakeA> | wanderview: no :( will bump that issue |
| 14:58 | <wanderview> | JakeA: just curious if that will be in SW spec or somewhere else... since window is non-worker |
| 14:59 | <wanderview> | kind of like how fetch was moved out to a separate spec |
| 15:00 | <JakeA> | wanderview: ideally caches should be a separate spec |
| 15:01 | <wanderview> | JakeA: random other question that came up over here... should scriptCache be per-origin or unique for each SW script? |
| 15:02 | <JakeA> | ugh |
| 15:03 | <JakeA> | wanderview: how much do you like scriptCache? I dislike it |
| 15:03 | <JakeA> | ohhh, wait, I can get rid of it on security grounds! |
| 15:04 | JakeA | kisses security |
| 15:05 | <wanderview> | JakeA: thats fine with me... but behind the scenes it should then be a separate cache per SW script URL? |
| 15:05 | <wanderview> | or... should separate SW scripts within the same origin share or not share a single cache? |
| 15:06 | wanderview | begins to understand the origin vs scope issue better. |
| 15:07 | <JakeA> | wanderview: each SW version gets its own cache for itself and importScripts, but this cache doesn't show up in script access (eg caches.keys()) |
| 15:07 | <annevk> | JakeA: Fetch could host a Cache API section... |
| 15:07 | <annevk> | not that farfetched |
| 15:07 | <wanderview> | JakeA: got it... I'll open an issue to clarify that in the spec |
| 15:07 | <JakeA> | wanderview: I'll do it |
| 15:07 | <JakeA> | already started |
| 15:07 | <wanderview> | JakeA: even better :-) thanks! |
| 15:08 | <JakeA> | annevk: I'm not against this moving to fetch. Would be good to get a 2nd opinion on that before moving it though. |
| 15:09 | <annevk> | JakeA: happy to work on that together, but no rush |
| 15:11 | <wanderview> | JakeA: sorry, one last question... did we drop the Cache constructor thing? its not in the spec and I don't see an issue for it |
| 15:12 | <wanderview> | I think maybe it got burried in the mega "review cache api" issue |
| 15:13 | <JakeA> | annevk: in Aus next week, but then my talk commitments are over aside from MCing which doesn't need much prep. Hopefully I'll get some training wheels through this response client merging. Then yeah, will help move caches over. |
| 15:18 | <JakeA> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/473#issuecomment-60401602 |
| 15:18 | <wanderview> | thanks |
| 15:18 | <JakeA> | wanderview: appreciate how much you're soldiering through the cache implementation with pretty much only the ts & bare bones spec to go by |
| 15:19 | <wanderview> | np, thanks for fielding all my questions :-) |
| 15:19 | <JakeA> | trying to remember where we got to with new Cache |
| 15:22 | <wanderview> | JakeA: seems the conclusion was to add it: https://github.com/slightlyoff/ServiceWorker/issues/372#issuecomment-50937980 |
| 15:22 | <wanderview> | but that issue turned more towards the fetch data cloning, etc |
| 15:23 | <JakeA> | wanderview: creating a new issue to track it now |
| 15:23 | <wanderview> | thanks again |
| 15:23 | <wanderview> | well.. sort of... since I didn't really want the constructor :-) |
| 15:24 | <JakeA> | I'm not really into it either |
| 15:24 | <darobin> | highly recommended: https://soundcloud.com/daniemon/back-to-cr-one-more-time |
| 15:26 | <annevk> | darobin: that's great |
| 15:26 | <annevk> | darobin: he also made a few with Bruce while still at Opera, so much fun |
| 15:26 | <darobin> | annevk: yes, he's a genius |
| 15:27 | <darobin> | I hope he brings back Dr Stanley Dards |
| 15:27 | <annevk> | darobin: so did Tim turn down HTML5? |
| 15:28 | <darobin> | annevk: you'd have to ask him :) |
| 15:28 | <annevk> | darobin: or is this not the entertaining note to go with the press release |
| 15:28 | <darobin> | this is completely unrelated |
| 15:28 | <JakeA> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/536 |
| 15:32 | <annevk> | JakeA: how is alt #2 different from alt #1 if we make scope optional? |
| 15:32 | <annevk> | JakeA: isn't that the difference? |
| 15:32 | <annevk> | JakeA: personally I'd much rather make them origin-bound |
| 15:34 | <JakeA> | annevk: it's opt-in vs opt-out, and how close it is to the current API makes it easier for me to sell internally (less impact on our intent to ship) |
| 15:35 | <JakeA> | annevk: I really think we need to keep scopes for all the reasons Jonas pointed out, plus github pages & similar host-per-user systems |
| 15:35 | <JakeA> | origin-per-user I mean |
| 15:37 | <annevk> | JakeA: I think those can be solved later by suborigins |
| 15:37 | <JakeA> | annevk: We could keep tweaking the root of this API for years and not actually deliver anything to developers and ultimately users. I don't think the separation of fetch is a big benefit vs getting us on the path to features native is kicking our arse with |
| 15:37 | <annevk> | JakeA: understood about opt-out now, makes sense to have that |
| 15:38 | <JakeA> | annevk: where should I read about suborigins? |
| 15:38 | <annevk> | JakeA: http://www.chromium.org/developers/design-documents/per-page-suborigins |
| 15:39 | <annevk> | JakeA: chromium.org could use TLS |
| 15:39 | <JakeA> | Chromium? Are they a new standards group? |
| 15:39 | JakeA | runs away laughing |
| 15:39 | <JakeA> | Will read, cheers |
| 15:39 | <JakeA> | There's no excuse for a Google property not using TLS |
| 15:39 | <annevk> | JakeA: hmm, seems chromium.org just needs a 80->443 redirect and HSTS |
| 15:40 | <JakeA> | even less excuse then |
| 15:40 | <JakeA> | lemmie chase that |
| 15:41 | <wanderview> | so suborigins are basically an extra scoping http header |
| 15:50 | <annevk> | wanderview: they allow you to create an actual security boundary for some set of resources |
| 15:52 | <annevk> | wanderview: so yes, scoping with security guarantees rather than scoping without any |
| 16:02 | <caitp> | how can you keep reading those tweets and not feel sick to your stomach tab, jeeze |
| 16:45 | <gsnedders> | caitp: I'm managing by crying REAL MAN TEARS®. |
| 16:54 | <caitp> | (・_・ヾ)??? |
| 17:55 | <Hixie> | MikeSmith: thanks |
| 18:09 | <Hixie> | seems to be some issue with the mailing list |
| 18:09 | <Hixie> | i've sent in a support request |
| 18:12 | <TabAtkins> | caitp: You referring to me? |
| 18:12 | <TabAtkins> | (My name being a noun makes it confusing when you don't capitalize it.) |
| 18:13 | <caitp> | yeah, although I forget which retweet the comment was about |
| 18:13 | <TabAtkins> | (The alternative, that you have a stomach tab, or think that other people do, is just confusing.) |
| 18:13 | <caitp> | something about jerks trying to harm survivors of domestic assault |
| 18:14 | <TabAtkins> | Possibly the AVFM people using another charity's trademark? |
| 18:14 | <caitp> | charming stories like that, can only read so much of it before you feel sick =p |
| 18:14 | <TabAtkins> | I, like, gsnedders use REAL MAN TEARS to cope. |
| 18:15 | <caitp> | whatever that is it must be working |
| 18:15 | <TabAtkins> | It's like crying, but manlier. |
| 18:15 | <MikeSmith> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27161 |
| 18:20 | <TabAtkins> | caitp: Also, I only follow awesome people, so when I see something horrible, it's filtered to be just the important stuff, rather than a deluge. Other people can do the curating for me. |
| 18:21 | <caitp> | you should forward the question to people who are actively watching the GG hashtag then :z all of the cherrypicked stuff from it seems pretty horrible |
| 18:22 | <gsnedders> | caitp: I occasionally look at the hashtag; it's a pretty representative sample that goes out so it's not much worse |
| 18:25 | <boogy> | is there a way to load a module via a string or a buffer? |
| 18:25 | <caitp> | sounds like an es-discuss question ^_^ |
| 18:26 | <caitp> | seems like it would have the same issues as new Function(...) or eval() though |
| 18:26 | <caitp> | so maybe it hasn't been considered |
| 18:26 | <gsnedders> | can you not just use eval? |
| 18:26 | <boogy> | is the a channel or a mailing list? |
| 18:26 | <TabAtkins> | boogy: mailling list. |
| 18:26 | <TabAtkins> | es-discuss⊙mo |
| 18:27 | <boogy> | Thanks. I'll refer the op in another channel where to find more info. |
| 18:28 | MikeSmith | tries to imagine what an es-discuss IRC channel would be like |
| 18:28 | <caitp> | less quiet than #v8, slightly noisier version of #jslang? |
| 18:31 | <Domenic> | "slightly" |
| 18:36 | <Hixie> | MikeSmith: boo :-P should i reassign that to anne? :-) |
| 19:00 | <wanderview> | JakeA: I see Cache.add() and Cache.addAll() resolve with undefined... is that correct? |
| 19:31 | <estellevw> | If I have a concern with the spec - notably the value of the range input type’s value attribute when multiple is set not being backward compatible, what is the best way to address that? |
| 19:31 | <estellevw> | The value attribute, if specified, must have a value that is a pair of valid floating-point numbers separated by a single U+002C COMMA character (,). |
| 19:31 | <estellevw> | that makes an invalid value for all browsers supporting range, but not the multiple attribute |
| 19:32 | <TabAtkins> | Yeah, but you need a totally different fallback if you don't support multiple. |
| 19:32 | <estellevw> | old browsers not support range should be ok: value=“2,4” is valid for text input type |
| 19:32 | <TabAtkins> | You can feature-test tat. |
| 19:32 | <estellevw> | are we expecting all developers to feature test multiple attribute before using it? |
| 19:33 | <TabAtkins> | No, but if they don't, it wont' work. There's no good automatic fallback. |
| 19:33 | <estellevw> | yes. exactly, that’s why I wanted to raise a concern |
| 19:35 | <TabAtkins> | I don't mean "there isn't currently good automatic fallback". I mean "there's no way to do good automatic fallback". |
| 19:35 | <estellevw> | agreed |
| 19:35 | <estellevw> | should the dual values be placed in separate attributes? |
| 19:36 | <estellevw> | that doesn’t sound like a good solution, |
| 19:36 | <estellevw> | but not having range value fail seems important |
| 19:36 | <TabAtkins> | It doesn't matter, because it won't fallback properly. A single-value range input is *not* a fallback for a multi-value range input. |
| 19:36 | <TabAtkins> | You need to test it and use two range inputs or something, or just use a multi-range input and not worry about older browsers. |
| 19:37 | <estellevw> | obviously y’all have already thought this thru thoroughly. |
| 19:37 | <TabAtkins> | Unsure if sarcastic or serious. |
| 19:37 | <estellevw> | no, totally not |
| 19:37 | TabAtkins | is having to say that too often these days. ^_^ |
| 19:37 | <estellevw> | basically, yall have already thought of my concerns |
| 19:38 | <TabAtkins> | Ah, kk. Well, someone did. |
| 19:38 | <estellevw> | so i’ll go back to my life as usual ;) |
| 19:38 | <TabAtkins> | I just reasoned backwards on the spot. ^_^ |
| 19:38 | <smaug____> | hmm, multiple range |
| 19:38 | <smaug____> | sounds like a bug |
| 19:39 | <TabAtkins> | smaug____: What do you mean? |
| 19:39 | <smaug____> | what is the use case |
| 19:40 | <TabAtkins> | Specifying a value that ranges from A to B. |
| 19:40 | <TabAtkins> | Like, say, a work shift. |
| 19:40 | <smaug____> | and why limit to two values if there is a use case |
| 19:40 | <TabAtkins> | What's the use-case for more than two? |
| 19:40 | <smaug____> | ah, that kind of multiple |
| 19:40 | <estellevw> | smaug____: not sure how much thought went into not having a fallback, and where/when the discussing took place. But TabAtkins makes sense (always), but not having a native fallback is a concern |
| 19:40 | <smaug____> | does any browser support range + multiple ? |
| 19:40 | <estellevw> | nope |
| 19:40 | <estellevw> | none |
| 19:41 | <estellevw> | tested 2 weeks ago |
| 19:41 | <estellevw> | though created my own tests, not official tests |
| 19:42 | <smaug____> | TabAtkins: range contain more than just start and end points, it could have width (or would it be height ) in 2d coordinate space |
| 19:42 | <smaug____> | s/contain/could contain/ |
| 19:42 | <TabAtkins> | smaug____: That's more than a linear range input can represent. |
| 19:43 | <smaug____> | multiple is already very different to non-multiple |
| 19:43 | smaug____ | wonders why multiple was added |
| 19:43 | <TabAtkins> | Because lots of people asked for ti. |
| 19:43 | <TabAtkins> | (including me) |
| 19:43 | <estellevw> | likely because everyone more than one thumb |
| 19:43 | <smaug____> | multiple sounds like something a script library could do |
| 19:44 | <TabAtkins> | (I used jQuery for a two-thumb input on several previous projects.) |
| 19:44 | <TabAtkins> | smaug____: *All* of the inputs sound like something a script library could do. |
| 19:44 | <smaug____> | not all |
| 19:44 | <smaug____> | <input type="text"> is good :) |
| 19:44 | <TabAtkins> | The new ones, at least. ^_^ |
| 19:44 | <smaug____> | yup |
| 19:45 | <wanderview> | JakeA: nevermind... I think I buy add/addAll resolving to undefined |
| 20:21 | <JonathanNeal> | Where might I find information regarding the Window constructor? |
| 20:22 | <TabAtkins> | JonathanNeal: Don't think there is one. |
| 20:22 | <TabAtkins> | (Which means it'll throw when you call it.) |
| 20:23 | <JonathanNeal> | Is constructor the wrong word to use? I mean it in the same vain as HTMLDocument and HTMLElement. |
| 20:23 | <TabAtkins> | Yeah, you're using it right. There just isn't one. |
| 20:24 | <TabAtkins> | Windows are only constructed by the UA. |
| 20:24 | <Ms2ger> | JonathanNeal, interface object |
| 20:24 | <TabAtkins> | That's an IDL-ism. |
| 20:24 | <Ms2ger> | JonathanNeal, you would find that in WebIDL and HTML |
| 20:24 | <JonathanNeal> | There most definitely is a “Window” interface object. I’m just looking for it in a spec of some sort. |
| 20:24 | <Ms2ger> | TabAtkins, is there a reason you're being unhelpful? |
| 20:24 | <TabAtkins> | Ms2ger: I totally misunderstood what he was asking for until just now, that's why. ^_^ |
| 20:25 | <Ms2ger> | I see |
| 20:25 | <TabAtkins> | The constructor doesn't exist, but the corresponding object does. |
| 20:25 | <Ms2ger> | Dunno what you mean by constructor, then |
| 20:26 | <JonathanNeal> | Yes, they’re rather strange in that I treat their prototypes like I would the constructor’s prototype for other objects. |
| 20:26 | <TabAtkins> | Ms2ger: An actual function that constructs the object. |
| 20:27 | <JonathanNeal> | Ms2ger: would this be the spec for the Window interface object? http://www.w3.org/TR/WebIDL/#ImplicitThis |
| 20:27 | <Ms2ger> | JonathanNeal, oh dear |
| 20:27 | <Ms2ger> | JonathanNeal, https://heycam.github.io/webidl/ |
| 20:27 | <JonathanNeal> | Ms2ger: I don’t mind looking like a fool, if in the end I learn. |
| 20:28 | <JonathanNeal> | Ms2ger: as in https://heycam.github.io/webidl/#ImplicitThis ? |
| 20:28 | <Ms2ger> | Depends on what you're looking for, exactly |
| 20:30 | <JonathanNeal> | Something that defines Window.prototype as extending all window objects. |
| 20:30 | <TabAtkins> | That's from the definition of a prototype, no? |
| 20:30 | <JonathanNeal> | Right, so the thing that clarifies that Window targets all window objects. |
| 20:31 | <TabAtkins> | Probably the IDL in the HTML spec for the Window object. |
| 20:31 | <JonathanNeal> | It is their “interface object”. |
| 20:31 | <Ms2ger> | Searching for [[Prototype]] says https://heycam.github.io/webidl/#es-platform-objects |
| 20:31 | <TabAtkins> | Is there some reason you need this information? |
| 20:33 | <JonathanNeal> | Yes, I’m working with a team that did not have an understanding of Window and likewise Window.prototype, so they were swapping out Window.prototype with window. I was explaining that (I hope this is right) Window.prototype should mean iframes inherit from Window.prototype. |
| 20:33 | <JonathanNeal> | And they replied "is there a good resource that explains the difference between Window and window” … and I paused because I did not know of one, and MDN did not have that sort of thing like they did for HTMLDocument, etc. |
| 20:34 | <TabAtkins> | The difference is between instance and class. |
| 20:34 | <TabAtkins> | The "window" object is an instance of the Window class, which has Window.prototype as its prototype. |
| 20:35 | <caitp> | can you actually extend Window.prototype in a meaningful way? like, does window.open-created windows inherit from the original window's prototype? |
| 20:35 | <TabAtkins> | (Iframes, with their own JS environment, will use a *different* Window class than the outer page, so anything you add to the outer page's Window.prototype won't show up in iframes. |
| 20:35 | <TabAtkins> | caitp: Dunno! |
| 20:35 | <TabAtkins> | I'm not sure how window.open()-created windows work, but if they have a fresh JS environment, then they won't. |
| 20:36 | <Ms2ger> | They do |
| 20:36 | <caitp> | well in chrome, apparently not |
| 20:36 | <caitp> | yeah there you go |
| 20:36 | <Ms2ger> | window.open() returns a Window, which is a global object |
| 20:37 | <TabAtkins> | From the new window's global? Or the original? both of you were ambiguous in which part of my phrasing you were responding to. |
| 20:37 | <Ms2ger> | Eh? |
| 20:37 | <caitp> | i'm just saying I don't think extending Window's prototype is really useful in any context, as far as I'm aware |
| 20:37 | <Ms2ger> | s/returns a/returns a new/ |
| 20:38 | <TabAtkins> | "if they ahve a fresh JS environment" or "they they won't [inherit from the original window's prototype]" |
| 20:39 | <Ms2ger> | If you call window.open(), you create a new Window object/global/compartment/realm/JS environment, whatever you want to call it |
| 20:39 | <JonathanNeal> | Right you are, neither iframe or window.open’s window inherited from Window.prototype. |
| 20:39 | <TabAtkins> | Those are different! A Window is an object in a JS environment. |
| 20:39 | <JonathanNeal> | At least, not in Chrome. |
| 20:39 | <TabAtkins> | Also happens to be the global for that environment. |
| 20:40 | <Ms2ger> | Global object and JS environment (as you appear to be using it) are 1:1 |
| 20:40 | <JonathanNeal> | caitp: my initial test would confirm that extending Window.prototype is rather useless, which is not at all what I expected. |
| 20:41 | <Ms2ger> | So as a mathematician, I just take the quotient over the equivalence, and treat them as equal :) |
| 20:41 | <TabAtkins> | Ms2ger: Yeah, it's probably valid to talk about it like you are, but if people are already confused about instances vs classes and the like, being as explicit as possible about environments and where certain classes come from is probably good. |
| 20:42 | <smaug____> | JonathanNeal: extending Window.prototype can be rather useless also because of its special behavior http://heycam.github.io/webidl/#Global |
| 20:42 | <Ms2ger> | smaug____, useless for overriding, not so much for adding |
| 20:42 | <smaug____> | (and I note that better to not test webidl behavior in Chrome ;) ) |
| 20:42 | <smaug____> | Ms2ger: indeed |
| 20:43 | <TabAtkins> | smaug____: Yes, good point. Chrome has been violating WebIDL for a long time regarding whether properties of built-ins are on the prototype or the instances. |
| 20:43 | <JonathanNeal> | smaug____: what a disappointment. That’s a pretty useless class, all right. |
| 20:44 | <Ms2ger> | Yay web compat |
| 20:45 | <caitp> | to be fair, the bindings generation stuff is all python so it's really intimidating for anyone to try and fix it |
| 20:45 | <JonathanNeal> | Does this mean that using HTMLDocument is also fairly useless? |
| 20:46 | <caitp> | not necessarily |
| 20:46 | <caitp> | not sure if DocumentImplementation#createDocument would work |
| 20:46 | <smaug____> | if you create several HTMLDocument object in the same scope, they share the prototype |
| 20:47 | <TabAtkins> | caitp: Nothing to do with programming difficulty in Blink; it's a perf issue. |
| 20:47 | <TabAtkins> | JonathanNeal: HTMLDocuments aren't associated with fresh environments. They're just like any other normal object. |
| 20:47 | <caitp> | Tab I was just taking another opportunity to troll python fans :p |
| 20:47 | <caitp> | don't take it seriously lopl |
| 20:47 | <caitp> | it's friday, oy |
| 20:48 | <TabAtkins> | caitp: Ah, I thought you just had a mistaken impression of what was causing the issue. |
| 20:48 | <TabAtkins> | (Friday is a time for sober reflection and formal dress, not trolling, SIR/MADAM/OTHER.) |
| 20:48 | <caitp> | sober reflection can wait until after the weekend =) |
| 20:49 | <TabAtkins> | Weekend is for drunk reflection. |
| 20:49 | <JonathanNeal> | caitp: when would I be creating a document? Fragments don’t inherit from HTMLDocument either. |
| 20:50 | <caitp> | DocumentImplementation can do it |
| 20:50 | <Ms2ger> | document.implementation.createHTMLDocument() |
| 20:50 | <JonathanNeal> | When would someone need that? |
| 20:51 | <caitp> | er |
| 20:51 | <caitp> | apparently i'm getting the name of the interface wrong |
| 20:51 | <JonathanNeal> | Well, what a crazy thing to learn, Window and HTMLDocument are rather useless in most usecases. |
| 20:52 | <JonathanNeal> | For example, there is no benefit to polyfilling Window.prototype.matchMedia versus window.matchMedia. |
| 20:53 | Ms2ger | never liked polyfills anyway |
| 20:56 | <caitp> | http://stackoverflow.com/questions/7738046/what-for-to-use-document-implementation-createhtmldocument there are some use-cases there if you're interested, I've only ever found it useful for testing though |
| 21:00 | <JonathanNeal> | thanks, caitp. |
| 21:00 | <JonathanNeal> | I need to hang my head low for a while. I had pretty much written things to get old IE to treat Window/HTMLDocument like I expected, but I think I should undo them now because it’s not how it’s supposed to work. |
| 21:05 | <Domenic> | annevk: thoughts on making DOMTokenList constructable? I'd like to write a Blink patch soon-ish but want to get your blessing first. |
| 21:06 | <Domenic> | And preferably Boris's too |
| 21:08 | <JonathanNeal> | Domenic: what would you use it for? |
| 21:09 | <Domenic> | JonathanNeal: creating custom elements that expose tokenized attributes |
| 21:11 | <JonathanNeal> | function TokenList() {} TokenList.prototype = DOMTokenList.prototype ? |
| 21:13 | <JonathanNeal> | Or you could even overwrite the DOMTokenList contructor, I suppose. I had to do something similar with https://github.com/Financial-Times/polyfill-service/blob/master/polyfills/Window.prototype.DOMTokenList/polyfill.js and https://github.com/Financial-Times/polyfill-service/blob/master/polyfills/Element.prototype.classList/polyfill.js |
| 21:20 | <JonathanNeal> | I can’t believe I misunderstood Window/HTMLDocument. Thanks so much for the info, caitp, Ms2ger, TabAtkins. |
| 21:20 | <TabAtkins> | np |
| 21:21 | <Ms2ger> | Np |
| 21:22 | <JonathanNeal> | On the upside, polyfills will be a lot easier to manage, and I can drop all the Window/HTMLDocument.prototype stuff from the folders. |
| 21:40 | <TabAtkins> | Hmm, I'm reading WebIDL back and forth, and I can't see how to define the iteration order for a setlike interface. IDL requires that a setlike does *not* have an explicit iterable declaration, but only the iterable declaration actually asks for prose on ordering. |
| 21:41 | <Domenic> | i think the idea might be it's always insertion order, like ES sets? |
| 21:43 | <TabAtkins> | Yeah, but I have some custom ordering. It's insertion order for the ones you insert yourself, but the UA-added ones are in document order, before the other ones. |
| 21:44 | <TabAtkins> | (Exposing precise UA resolution order isn't really something I want to do - too racy.) |
| 21:45 | <Domenic> | TabAtkins: my guess is that kind of thing wasn't anticipated, so I'd just specify the ordering in the prose anyway? |
| 21:45 | <TabAtkins> | Yeah, that's what I'm doing right now. |
| 21:45 | <Domenic> | JonathanNeal: I was excited about that idea for a second but when you try that you get "TypeError: 'add' called on an object that does not implement interface DOMTokenList." |
| 21:51 | <JonathanNeal> | What?! Oh, what a bummer. It gets all special? |
| 21:51 | <JonathanNeal> | Well, you can take the DOMTokenlist polyfill. That implements to spec, down to method.name and method.length |