| 00:32 | <terinjokes> | TabAtkins: is there a format for editor notes? |
| 00:32 | <terinjokes> | in bikeshed? |
| 00:32 | <TabAtkins> | What do you mean by that? |
| 00:33 | <terinjokes> | i guess some sort of warning/note that explains something inline during the drafts |
| 00:33 | <TabAtkins> | Yeah, if you want them visible, just start a paragraph with "Note:" |
| 00:34 | <TabAtkins> | I wasn't sure if you meant notes just to yourself (use HTML comments) or not. |
| 00:34 | <TabAtkins> | There's Note: for informative notes, Issue: for issues that you want to track (they're also collected into an index at the end of the spec), and Advisement: for things you want to draw special implementor attention to. |
| 00:35 | <TabAtkins> | Plus <details class=why> if you want to embed a longer explanation in, but don't want it to distract the casual reader. |
| 00:36 | <terinjokes> | ah nice, get an arrow ;) |
| 01:09 | <caitp> | why is dev.w3.org down what happened ;-; |
| 01:09 | <tantek> | caitp I believe you're looking for irc://irc.w3.org:6665/sysreq |
| 01:10 | <tantek> | although I don't seem to be able to connect to that either |
| 01:10 | <caitp> | power must have gone out in a little closet in boston |
| 01:10 | <tantek> | um "It's not just you! http://www.w3.org looks down from here. " |
| 01:11 | <tantek> | http://downforeveryoneorjustme.com/http://www.w3.org/ |
| 01:13 | <tripu> | We're aware of that, caitp, tantek |
| 01:13 | <tripu> | I just noticed |
| 01:13 | tripu | is asking his colleagues |
| 01:13 | <tantek> | hello tripu, I just noticed myself |
| 01:17 | <tantek> | tripu - btw who is "we"? are you w3c staff? sorry I don't recognize your handle. |
| 01:18 | <tripu> | tantek: Antonio Olmo Titos here -- I joined W3C's systems team a month ago |
| 01:18 | tantek | waits to see if https://twitter.com/w3c will tweet something. |
| 01:18 | tripu | should have introduced himself earlier in this channel... |
| 01:19 | <terinjokes> | naturally, while I was refreshing a page |
| 01:51 | <tripu> | caitp, tantek: W3C's web pages and IRC server are running again |
| 01:53 | <tantek> | thanks tripu |
| 04:20 | <zcorpan> | Sample: file was only made constructable in the spec relatively recently |
| 07:37 | <zcorpan_> | what are people's thoughts on adding JSON5 to the web platform? or replacing JSON with JSON5? (iirc browsers already deviate from strict JSON a bit) |
| 07:38 | <foolip> | are the differences interoperably implemented and what are they? |
| 07:38 | <Ms2ger> | They do? |
| 07:38 | <foolip> | I'm guessing things around single/double quotes and comments? |
| 07:39 | <zcorpan_> | Ms2ger: at least at the time it was implemented in presto we had to make a few violations because other browsers were even more lax and content depended on it. not sure what the situation is like today |
| 07:39 | <Ms2ger> | Interesting |
| 07:41 | <zcorpan_> | foolip: i don't know about JSON5 interop |
| 07:41 | <zcorpan_> | foolip: http://json5.org says the new features are optional which seems problematic |
| 07:43 | <zcorpan_> | unquoted keys seems nice if we're going to have it in attributes |
| 08:01 | <foolip> | zcorpan_: oh I had no idea JSON5 was a real thing, I thought it was code for "JSON with error handling for browsers" |
| 08:02 | <zcorpan_> | foolip: yeah we should trademark the 5 :-) |
| 08:03 | <zcorpan_> | although i guess we don't use the 5 so much anymore |
| 08:13 | <foolip> | Is Web* still cool? |
| 08:16 | <odinho> | lol |
| 08:17 | <zcorpan_> | foolip: naw, just the relevant name without fluff is the new black |
| 09:47 | <annevk> | hard to turn that into a buzzword |
| 10:28 | <jgraham> | Disappointed we haven't managed to use "web" and "5" together. Like WebURL5 |
| 10:43 | <Ms2ger> | jgraham, sounds like a Chrome component |
| 10:49 | <annevk> | WTFURL2 |
| 10:54 | <jgraham> | WTFW3C^N |
| 11:03 | <smaug____> | URL5.1, obviously |
| 11:03 | <Domenic> | SJON5 is not a real thing |
| 11:03 | <Domenic> | some people made some parsers. it has no real adoption. |
| 11:04 | <jgraham> | That's how most technologies start out |
| 11:34 | <foolip> | jgraham, zcorpan_, do you have recommendations for test bisect tools that are able to parse HTML, JS and CSS sufficiently to not spend time trying bisect steps that will obviously fail, i.e. things like omitting </style>, </script> or cutting JS such that it's a syntax error? |
| 11:35 | <foolip> | test minimizer I should say perhaps |
| 11:35 | <jgraham> | foolip: I don't know that exists |
| 11:36 | <foolip> | in your long QA experience, is this something that sounds good in theory but in practice it's fast enough to just try manually? |
| 11:36 | <jgraham> | There's a tool for pure js at Opera |
| 11:36 | <jgraham> | "it depends" |
| 11:37 | <zcorpan_> | foolip: for crashers or in general? |
| 11:37 | <jgraham> | The tools are helpful, but unless the failure mode is very obvious it can be difficult to write a correct pass condition |
| 11:37 | <Ms2ger> | Our security people might have something, but I don't know if they share |
| 11:37 | <foolip> | in general, just reducing a test case, whether or not the reduced test case is pass or fail would be up to the layer invoking the script |
| 11:38 | <zcorpan_> | foolip: i'm not aware of such scripts but there might be something out there |
| 11:38 | <jgraham> | Right, generally you need to know if it passed or failed in order to decide which reduction to try next |
| 11:39 | <zcorpan_> | i always did it manually or used devtools to find the problem, or a combination |
| 11:40 | <jgraham> | Anyway, I am aware of syntax-unaware tools, and language-specific tools, but nothing that can deal with all of HTML+CSS+JS in an intelligent way |
| 11:40 | <foolip> | yeah, it seems like that's what we all do :) |
| 11:41 | <foolip> | ok, I guess that might make a fun side project then, but since it doesn't exist people probably don't really need it that badly |
| 11:41 | <foolip> | (I'm reading a book called Why Programs Fail and the example used is from the old Gecko BugAThon, but the test case reducer used is completely generic.) |
| 11:41 | <jgraham> | Lithium? |
| 11:42 | <annevk> | Does JSON5 allow comments and single quotes? |
| 11:42 | <zcorpan_> | annevk: yeah |
| 11:42 | <foolip> | jgraham: the tool in the book is ddmin: https://www.st.cs.uni-saarland.de/whyprogramsfail/code/dd/ddmin.py |
| 11:42 | <annevk> | Actually just allowing comments is probably enough to win |
| 11:42 | <annevk> | I never understood why TC39 did not just add that |
| 11:43 | <annevk> | And now they have this weird mentality of not being able to make a forward compatible change |
| 11:44 | <jgraham> | foolip: Oh, wow that's very simple |
| 11:44 | <jgraham> | foolip: Lithium is http://www.squarefree.com/2007/09/15/introducing-lithium-a-testcase-reduction-tool/ |
| 11:44 | <foolip> | Yeah, that looks like it's trying to improve upon ddmin |
| 11:45 | <foolip> | but any non-language-aware tools seems like it's going to waste too much time on stupid things |
| 11:46 | <jgraham> | It's not too bad |
| 11:46 | <jgraham> | There's also reducio at Opera for js, if the QA server is still running |
| 11:51 | <foolip> | jgraham: found it, and it looks like you wrote a Reductor, "Testcase reduction tool optimised for HTML files", but that seems to have gone poof |
| 11:51 | <foolip> | was that any good? |
| 11:55 | <jgraham> | foolip: I don't think it was |
| 11:55 | <jgraham> | I don't think it really got used |
| 12:03 | <zcorpan_> | can someone run http://jsperf.com/animated-box-using-left/2 in different browsers and see if you reproduce my results? (requestAnimationFrame gets better score than setTimeout only in Safari) |
| 12:04 | <odinho> | I used Reductio not too long ago. A year I think :P |
| 12:05 | <odinho> | Reducio, always write that wrong |
| 12:11 | <Ms2ger> | Sounds like a spell |
| 12:15 | <tobie> | annevk: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr |
| 12:24 | <odinho> | Ms2ger: It's supposed to be ;) |
| 13:11 | <annevk> | tobie: ta |
| 13:12 | <annevk> | tobie: bit sad |
| 13:57 | <wanderview> | JakeA: do we have any restrictions or expectations on URL schemes that can be put in Cache? |
| 13:58 | <caitp> | kAllowedSchemeRegexp = /s$/; |
| 13:59 | <wanderview> | I know ServiceWorkers scripts themselves are required to be https, but I thought Cache worked http as well... and I guess I'm asking how well do we need to support things like ftp:, file:, etc |
| 13:59 | <caitp> | it was a joke, I have no idea |
| 14:00 | <wanderview> | :-) |
| 14:01 | <wanderview> | mainly the ignoreSearch query param is problematic if I have to fully parse all URL schemes to implement it... I'm inclined to make ignoreSearch work for http/https and a no-op in other URL schemes... at least in the first version |
| 14:02 | <JakeA> | wanderview: let's say http & https only |
| 14:02 | <caitp> | isn't it only an issue for weird schemes like data ? |
| 14:02 | <JakeA> | wanderview: those are the schemes serviceworker gets fetch events for |
| 14:02 | <caitp> | maybe ldap-ish stuff too |
| 14:03 | <JakeA> | wanderview: and while caches can be used independent of serviceworker, it's a good starting point that we can expand on later |
| 14:03 | <wanderview> | JakeA: should the spec be updated to say http/https only? or just an implementation detail to start? |
| 14:03 | <wanderview> | I can write an issue |
| 14:04 | <JakeA> | wanderview: An issue would be great :D |
| 14:04 | <wanderview> | JakeA: thanks... will do... and sorry for the problem on this :-\ |
| 14:04 | <caitp> | in my opinion which nobody asked for, it makes sense for URLs which are actually locations of resources, where search queries make sense |
| 14:04 | <caitp> | which probably includes most custom schemes, if custom schemes are supported |
| 14:06 | <JakeA> | wanderview: I feel guilty with how off-the-ball I've been with this stuff the past week or so. Especially as right now I'm using SVG path animations to make it looking like Mumm Ra the Ever Living is using his magic powers to control many documents at once. |
| 14:06 | <wanderview> | caitp: the custom schemes are the problem for me... as we allow js scheme implementations which in turn requires parsing URLs on the main thread :-( |
| 14:06 | <wanderview> | JakeA: that sounds like an awesome talk! |
| 14:07 | <caitp> | yeah, that is a bit of a pickle for SW isn't it |
| 14:08 | <JakeA> | caitp: although the cache can be used from window. But applying .match semantics to non-http resources is problematic |
| 14:09 | <caitp> | well anyways, it's not like there isn't a bit of a precedent for mixing work between main thread and (at least non-SW) worker threads |
| 14:10 | <caitp> | if the api doesn't have to be synchronous it can probably be worked around |
| 14:10 | <caitp> | but i'm just blabbing, haven't even read the cache stuff =) back to work~ |
| 14:11 | <JakeA> | caitp: confused about the sync vs async stuff… I don't think we have a problem there |
| 14:11 | <JakeA> | ahh I see |
| 14:11 | <wanderview> | caitp: it can be worked around, yes... but it pains me to jump threads just to parse a string :-( |
| 14:11 | <JakeA> | missed that comment |
| 14:11 | <caitp> | well if you're jumping between a worker thread and main thread, you're going to have some issues with sync |
| 14:15 | <annevk> | JakeA: Cache can't do http |
| 14:15 | <annevk> | JakeA: that would violate MIX |
| 14:16 | <wanderview> | annevk: you mean because SW script is https only, all resources placed in Cache from SW must be https? |
| 14:16 | <zcorpan_> | apparently json5 didn't have anything optional for implementers |
| 14:17 | <JakeA> | annevk: I don't see why cache can't be used from http pages, just like idb |
| 14:20 | <JakeA> | annevk: if a serviceworker-controlled page contains an http img, and I respondWith(event.default()), what happens? |
| 14:20 | <JakeA> | Weird if that fails. Also weird if respondWith(fetch(event.request)) fails |
| 14:21 | <JakeA> | If it doesn't fail, I don't see why I can't put it in a cache |
| 14:25 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/440 |
| 14:25 | <wanderview> | JakeA: I'm going to internally propose this limitation for gecko implementation even if we don't add it to the spec |
| 14:26 | <JakeA> | worksforme |
| 14:28 | <wanderview> | thanks |
| 14:44 | <annevk> | wanderview: yeah |
| 14:45 | <annevk> | JakeA: fetch() would definitely fail |
| 14:45 | <annevk> | JakeA: can't allow MIX |
| 14:45 | <JakeA> | annevk: even no-cors? |
| 14:45 | <annevk> | correct |
| 14:46 | <annevk> | JakeA: this isn't already the case in Chrome? I'd think Mike West would see to that |
| 14:47 | <annevk> | JakeA: also, I wouldn't mind restricting Cache to TLS as well, otherwise we'll get weird service worker polyfills |
| 14:47 | <annevk> | JakeA: non-TLS polyfills that is |
| 14:48 | <JakeA> | annevk: there was a discussion at http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0049.html |
| 14:49 | <JakeA> | annevk: then you'll just get cache polyfills based on idb |
| 14:49 | <annevk> | if that were the case we would've seen one by now I think |
| 14:49 | <JakeA> | we used one in our I/O talk |
| 15:27 | <annevk> | wanderview: we should really fix our URL parser :-( |
| 15:28 | <wanderview> | annevk: yes... its ridiculous |
| 15:30 | <JakeA> | Y'know, once you clear away all the events from indexeddb, it's not too bad |
| 15:32 | <JakeA> | Switch them out for promises, some kind of async iterator for cursors, use a promise to define the lifetime of a transaction… |
| 15:32 | <JakeA> | Dunno if that can be done on top of the current API though |
| 15:35 | <Domenic> | transactions are the tricky bit |
| 15:36 | <Domenic> | I believe the node-LevelDB folks when they say a batch API is good enough for 99% of use cases |
| 15:36 | <Domenic> | I also now understand how slightlyoff says that is not the best primitive, especially when dealing with other related mutexes in the system. |
| 15:37 | <JakeA> | Yeh |
| 15:47 | <terinjokes> | hello, non San Franciscians |
| 17:29 | <Hixie_> | TabAtkins: should :enabled match :link? Your feedback would be very useful on https://www.w3.org/Bugs/Public/show_bug.cgi?id=26622 |
| 17:30 | <Ms2ger> | Hixie_, fwiw, it might only be abinader who's implemented that so far :) |
| 17:30 | <Hixie_> | in chrome, you mean? |
| 17:30 | <abinader> | Hixie_: yes |
| 17:31 | <Hixie_> | ah, excellent, you are here :-) |
| 17:31 | <Hixie_> | abinader: sorry to flip flop the spec on you like this. If you think there's a good reason why we should get the other browsers to change rather than reverting Chrome (and the spec), please do comment on that bug. |
| 17:32 | <Hixie_> | abinader: (or let me know here) |
| 17:32 | <abinader> | Hixie_: currently Blink, WebKit and Servo have this implemented |
| 17:32 | <Hixie_> | webkit as well? |
| 17:32 | <abinader> | yeah |
| 17:32 | <Hixie_> | is that not in the nightlies yet? |
| 17:33 | <Hixie_> | oh, i have a pending update |
| 17:33 | Hixie_ | applies |
| 17:33 | <abinader> | lemme just have a double check |
| 17:34 | <Ms2ger> | Hixie_, and Servo :) |
| 17:34 | <Hixie_> | ah, yes, webkit does do this too now |
| 17:34 | <Hixie_> | Ms2ger: servo has 0% market share. so it's not exactly on my radar. |
| 17:34 | <Hixie_> | no offense :-) |
| 17:35 | Ms2ger | is offended |
| 17:35 | <Ms2ger> | It's a pretty recent change everywhere, I think |
| 17:35 | <Hixie_> | clearly, since i had to update my nightly :-) |
| 17:38 | <Hixie_> | abinader: did you have a particular motivation for this change other than it being what the spec says? |
| 17:39 | <Hixie_> | gah, i hate changing the spec on people like this |
| 17:39 | <Hixie_> | but on the other hand, it's a change to the platform and i hate doing that to web devs too |
| 17:40 | <abinader> | Hixie_: nope, no particular reason |
| 17:41 | <abinader> | Hixie_: but wouldn't it be reasonable to anchors, areas & links w/o an href to become disabled, then? |
| 17:41 | <abinader> | if that is what's missing |
| 17:42 | <Hixie_> | well, those just aren't links |
| 17:42 | <Hixie_> | i think we could imagine a world where we have <a href="..." disabled> |
| 17:42 | <Hixie_> | especially for links that are basically just hooks for javascript to change the display |
| 17:43 | <Hixie_> | but i haven't seen much demand for that, if any |
| 17:43 | <abinader> | indeed |
| 17:43 | <Domenic_> | I have tried to do that and been disappointed when it doesn't work |
| 17:43 | <Domenic_> | so, um, i demand it |
| 17:44 | <Domenic_> | it's useful for things where the designer wants it to look like a button but it navigates to a different URL so you use an <a>. But then you are sad that your CSS [disabled] style doesn't work. And then you have to change your CSS to [disabled], .disabled and you have to use class="disabled" and change your JS and stuff |
| 17:44 | <Domenic_> | I have lived this |
| 17:51 | <JakeA> | annevk: If I have a url object & set .search to "", the href has "?" at the end. Is there any way to prevent this? |
| 17:51 | <Ms2ger> | .search = null? |
| 17:51 | <annevk> | no |
| 17:51 | <Ms2ger> | No |
| 17:51 | <annevk> | setting to the empty string should do it |
| 17:52 | <JakeA> | ah yes |
| 17:52 | <annevk> | see step 2 of setting http://url.spec.whatwg.org/#dom-url-search |
| 17:53 | <JakeA> | annevk: yeah, I see it now, I was looking at just the serializer & thought the same as Ms2ger |
| 17:53 | <JakeA> | Chrome does it wrong, will file a bug |
| 17:54 | <wanderview> | JakeA: annevk: setting .search to "" should leave the # ref section intact, right? |
| 17:54 | <annevk> | yes |
| 17:54 | <JakeA> | yeah |
| 17:54 | <wanderview> | k |
| 17:55 | <annevk> | it manipulates the query component, nothing else |
| 17:55 | <wanderview> | k |
| 17:57 | <Hixie_> | Domenic_: what was the reason for disabling the link? |
| 18:12 | <Domenic_> | Hixie_: it wasn't applicable in the current state of the UI, for some reason... maybe some stuff had to be filled out first before they could move on the next page or something |
| 18:15 | <Hixie_> | Domenic_: if it's just a link (something you can open in a new tab, for example), it's not clear how that would work |
| 18:15 | <Hixie_> | Domenic_: i guess maybe you could have a link to a preview page that involves information the user has to offer, or something |
| 18:16 | <Domenic_> | yes, it wasn't a security disabled, just a "don't do this right now, it doesn't make sense" disabled |
| 18:19 | <Hixie_> | yeah |
| 18:20 | <Hixie_> | Domenic_: well, if you think we should keep that door open, comment on the bug saying you want :enabled to keep applying, i guess :-) |
| 19:02 | <TabAtkins> | Btw, I don't have an opinion on that bug, and am happy to edit in whatever direction is necessary. |
| 19:09 | <wanderview> | JakeA: can you explain what the purpose of this is in BatchCacheOperations 3.3.5.1? "If any of the values in addedRequests matches requestResponse[0], then: Throw an "InvalidStateError" exception." |
| 19:10 | <wanderview> | oh... is it saying if we delete one of the requests we just added in a single batch operation? |
| 19:10 | <wanderview> | then thats illegal? |
| 19:11 | <JakeA> | wanderview: yep! |
| 19:11 | <JakeA> | Felt like the right thing to do |
| 19:11 | <wanderview> | JakeA: and it leaves the batch operation partially applied? |
| 19:11 | <JakeA> | wanderview: nah, it should abort the transition & revery |
| 19:11 | <JakeA> | revert* |
| 19:12 | <wanderview> | JakeA: is that covered by running the steps "atomically"? |
| 19:12 | <wanderview> | in spec-speak |
| 19:12 | <JakeA> | transaction* |
| 19:12 | <JakeA> | wanderview: it's intended to, although it probably should be more specific |
| 19:13 | <wanderview> | JakeA: so this can only happen in the addAll() case currently |
| 19:13 | <wanderview> | right? |
| 19:13 | <JakeA> | yeah |
| 19:13 | <wanderview> | k |
| 19:14 | <wanderview> | thanks |
| 19:14 | <JakeA> | np |
| 19:14 | <wanderview> | JakeA: is there a definition of "match" in that case? I assume it should be doing something similar to [[QueryCache]] logic |
| 19:15 | <JakeA> | wanderview: yeah, it should. Hmm, the spec is a little patchy here. |
| 19:15 | <wanderview> | k, I'll write an issue |
| 19:15 | <JakeA> | Cheers |
| 19:15 | <JakeA> | Sorry about htat |
| 19:16 | <JakeA> | that* |
| 19:16 | <wanderview> | JakeA: also, why only the first element in the response array? |
| 19:16 | <JakeA> | gah, can't type tonight |
| 19:16 | <wanderview> | np |
| 19:16 | <JakeA> | wanderview: yeah, that's wrong, it should be checking all the items added so far |
| 19:17 | <wanderview> | JakeA: should it be inside the deletion loop? so as we delete each item we first check to see if it matches? |
| 19:19 | <JakeA> | wanderview: yeah, that works |
| 19:19 | <wanderview> | great, thanks |
| 19:19 | <wanderview> | https://github.com/slightlyoff/ServiceWorker/issues/444 |
| 19:19 | <caitp> | are you trying to add more confusing syntax that is totally bonkers compared to other languages with similar syntax domenic |
| 19:20 | <JakeA> | wanderview: I was working on an idb polyfill earlier & I just did the check up-front, but I was only implementing multi-put, so for every item about to be put, check items earlier in the array, if there's a match, reject |
| 19:21 | <wanderview> | ah |
| 19:22 | <JakeA> | "about to be put", I mean "every item in the to-put array", I did the check before putting any items |
| 19:22 | <wanderview> | I guess that would work for addAll also |
| 19:25 | <caitp> | because it looks like you're saying `<context>::<token>(<...args>)` is a syntax sugar for `<token>.call(<context>, <...args>)`, but that's not how it feels to cplusplusy people imo |
| 19:44 | <annevk> | TabAtkins: could you reply to bz on the closest() / matches() thread? Would be nice to move on. Or should I prepare some examples first so we can judge better? |
| 19:44 | <TabAtkins> | Yeah, sorry, I'm only half-in due to a head-cold. I was trying to think of some examples, but if you have some for either way, that would be helpful. |
| 19:46 | <Hixie_> | can anyone think of a part of the web platform that compares two URLs for common path segments? |
| 19:46 | <Hixie_> | cookies have something similar |
| 19:46 | <Hixie_> | but not on URLs |
| 19:47 | <Hixie_> | document.domain has something similar for hosts |
| 19:47 | <TabAtkins> | Hixie_: CSS's :local-link() pseudo. |
| 19:48 | <Hixie_> | is that specced anywhere? i can't find it in selectors |
| 19:50 | <TabAtkins> | Sorry, it got punted: http://dev.w3.org/csswg/selectors/deferred-for-level-5 |
| 19:50 | <TabAtkins> | (Because we weren't sure on what the right semantic was for comparing path segments.) |
| 19:51 | <TabAtkins> | The issue at the bottom really captures the problem. |
| 19:51 | <Hixie_> | heh |
| 19:53 | <Hixie_> | well i guess i'll just have to spec my own algorithm then |
| 19:53 | <Hixie_> | bummer |
| 19:55 | <TabAtkins> | The algorithm itself isn't the problem, it's figuring out the defaults. If you can do that, we can match. |
| 19:55 | <TabAtkins> | What is your context here? |
| 20:17 | <Hixie_> | TabAtkins: FALLBACK in manifests has to only work in a subpath of the manifest's path |
| 20:17 | <Hixie_> | TabAtkins: it's similar, but probably not identical enough |
| 20:17 | <TabAtkins> | Mm, yeah, probably. |
| 20:17 | <Hixie_> | anyway it's not a big deal, i was just hoping there might be something i could point to instead of having to do the work myself :-) |
| 21:05 | <wanderview> | JakeA: ServiceWorkers should now be allowed over http on localhost in FF nightly: https://hg.mozilla.org/mozilla-central/rev/cea25477ad0f |
| 21:06 | <JakeA> | wanderview: just saw the ticket, excellent! |
| 21:06 | <wanderview> | oh yea.. forgot you reported that one :-) |
| 23:41 | <othermaciej> | annevk: is there a canonical test suite for the URL standard, specifically for the parsing algorithm? |
| 23:41 | <othermaciej> | one of my planned hobby projects is to implement its parsing rules, but I might need to start by making a test suite |