/irc-logs / freenode / #whatwg / 2015-03-31 / end

Options:

# Session Start: Tue Mar 31 00:00:00 2015
# Session Ident: #whatwg
# [00:01] <darobin> "Any flash ad that’s being transpiled to HTML5 clientside is more costly than it should be." — wait, you are doing *what* on the client?
# [00:02] <jgraham> Yeah, I mean I understand shumway, but are people really producing new content like that?
# [00:02] <Ms2ger> "You blocked flash? Let me work around that"
# [00:02] <jgraham> I suspect this means that HTML authoring environments are still terrible
# [00:02] <jgraham> Ms2ger: But they could just write HTML in the first place
# [00:02] <tschneidereit> Ms2ger: that's not how we roll, though
# [00:03] <jgraham> anyway, it seems like one message here is "the more third-party code you run, the less likely you are to win at perf"
# [00:03] <tschneidereit> Shumway won't run for ads if you have Flash disabled
# [00:03] <jgraham> And since ads are all third-party code…
# [00:03] <Ms2ger> tschneidereit, no, I mean that the ad would do that itself
# [00:04] <tschneidereit> Ms2ger: oh, ok. Yeah, obviously ads will move to html/js more and more
# [00:04] * Krinkle is now known as Krinkle|detached
# [00:04] <jgraham> tschneidereit: In this case it seems like the ads had been compiled from flash to html or something
# [00:05] <jgraham> Presumably using something shumway-like
# [00:05] * Quits: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [00:05] <sethf> jgraham: doesn't google have something like that? swiffy? thought it was server-side, though
# [00:06] <jgraham> That could be it. But presumably it emits js that runs on the client
# [00:07] <sethf> oh yeah, sure, the js runs on the client
# [00:07] <tschneidereit> jgraham: almost certainly Swiffy, yes. Do you have a URL?
# [00:07] <jgraham> Oh, yeah it says that in the screenshot
# [00:07] <tschneidereit> heh
# [00:08] <jgraham> Search for flash in the document I linked above
# [00:08] * Quits: botie (~i-bot@sideshowbarker.net) (Remote host closed the connection)
# [00:08] * Joins: bradleymeck (~bradleyme@70.114.246.88)
# [00:08] * Joins: botie (~i-bot@sideshowbarker.net)
# [00:11] <jgraham> So I guess a cynical takeaway is that Google is an enabler for bad web perf :)
# [00:13] * Quits: weinig (~weinig@17.244.160.62) (Quit: weinig)
# [00:13] <tantek> wow that google doc is amazing
# [00:14] <tantek> had no idea so much overengineering was going on in webpages. no wonder the silo web keeps getting slower.
# [00:14] <jgraham> I'm not sure it's over-engineering as such
# [00:14] <jgraham> I think that there are two related dev-side problems
# [00:15] <tantek> I think you only get to code messes / overengineering like that by having massive engineering staffs that divide up everything, and everyone has to deliver some code, so it becomes an n-layers mess of inefficient crap
# [00:16] <tantek> or, don't understand this layer? add a layer!
# [00:16] <jgraham> 1) A culture of just throwing random scripts onto a page without much clue what they're doing (e.g. ad scripts, analytics scripts). This unfortunately is lots of the revenue-providing stuff.
# [00:16] <tantek> yes that big time
# [00:17] <jgraham> 2) A culture of favouring high levels of abstraction rather than optimising perf. This is partially because it's historically been needed to use jQuery or whatever to smooth over browser differences, but that's less true now
# [00:18] <jgraham> Also, we haven't given great tools for people to identify jank
# [00:18] * Quits: Ms2ger (~Ms2ger@60.219-242-81.adsl-dyn.isp.belgacom.be) (Quit: Leaving)
# [00:19] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [00:19] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [00:19] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:19] <jgraham> (the wikipedia example is instructive for point 2 because they are using apparently simple jQuery methods in favour of simple DOM manipulations without realising that the jQuery methods bury lots of expensive calls)
# [00:19] <tantek> a lack of "good examples" to copy from is also a problem
# [00:20] <tantek> good *running* examples that is. that you can view source on and figure out "how did they do that?"
# [00:20] <jgraham> With perf it's often more about what you *didn't* do
# [00:20] <jgraham> It's harder to get the idea of "I didn't call any layout-computing functions" from an example
# [00:20] <tantek> if you start with something performant, at least you can measure regressions when stuff gets added and like the doctor says, don't do that.
# [00:21] * Joins: weinig (~weinig@17.244.160.62)
# [00:21] <tantek> also when you have big engineering staffs, you're biased towards adding more crap code, and thus anti-performant by default.
# [00:22] * Quits: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 246 seconds)
# [00:22] <tantek> it becomes hard to cut code for political reasons
# [00:22] <jgraham> I think blaming this on "big engineering staff" is an over-simplification
# [00:22] <tantek> people's managers feelings getting hurt etc.
# [00:22] <jgraham> companies with lots of staff can produce performant code
# [00:22] <tantek> can but rarely do
# [00:22] <gsnedders> Is that not more a problem with too many managers? :)
# [00:23] <jgraham> That seems hugely [citation needed]
# [00:23] <tantek> citation was provided with that google doc - orgs with big-ish engineering staffs. Wikipedia was perhaps the exception.
# [00:24] <jgraham> That's so clearly not valid
# [00:24] <tantek> to provide a counter-point of anecdata, FB has a big engineering staff yet seems to be quite good at web perf, desktop or mobile
# [00:24] <tantek> so yes, it is possible to have a big engineering staff and be performant, it's just rare.
# [00:25] <jgraham> Since "slow and well-known" were presumably the defining features of the sample it seems much more reasonable to assume that well-known sites are produced by larger companies with more engineers
# [00:25] <terinjokes> from what i understand, they have a smallish group dedicated to ensuring the rest of the org is performant on the web
# [00:26] <tantek> jgraham - this is just a specific instance of http://en.wikipedia.org/wiki/Conway%27s_Law
# [00:26] <paul_irish> jgraham: change /pub to /view to get the full comment thread along the side. good discussion in there
# [00:26] <JonathanNeal> In CSS, can I have a variable written only if it has not already been declared? In other words, do CSS variables allow for something like !default in Sass?
# [00:27] <jgraham> tantek: This whole sub-discussion is just a projection of biases about the merits of different organisational structure
# [00:28] <jgraham> paul_irish: Oooh!
# [00:28] <jgraham> paul_irish: Did I already mention this is awesome btw?
# [00:28] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Quit: bradleymeck)
# [00:28] <paul_irish> :) thanks! it was fun to write up
# [00:29] <paul_irish> We're now talking to some folks in adsense. But I didnt want to gate publishing this on resolving those issues.
# [00:29] * Joins: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64)
# [00:29] <paul_irish> one of the big challenges for all ads/analytics is Viewability, which is now in the IAB mandatory guidelines for Ad Platform providers.
# [00:29] <paul_irish> http://www.iab.net/iablog/2014/03/viewability-has-arrived-what-you-need-to-know-to-see-through-this-sea-change.html
# [00:30] <paul_irish> tl;dr: ads need to know if they are at least 50% visible to the user for 1 continuous second.
# [00:30] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [00:30] <jgraham> paul_irish: Not sure I can see the comments
# [00:31] * paul_irish ah. you're right. flipped off commenting to address trolls deleting content. one sec.
# [00:31] <tantek> paul_irish: on that URL, scripts currently forbidden: <script>: 42
# [00:31] <tantek> of course 42
# [00:31] * Joins: bradleymeck (~bradleyme@70.114.246.88)
# [00:32] <paul_irish> turns out that the web platform is totally lacking performant APIs to evaluate those visibility concerns
# [00:32] <paul_irish> which is why you see so many things binding to touch handlers and/or polling
# [00:32] <gsnedders> What's the status of idlharness.js nowadays?
# [00:33] <tantek> paul_irish: do they provide any guidance for how to performantly implement measuring that 50% visible for 1s+? or is this just an unfunded IAB mandate?
# [00:33] <paul_irish> jgraham: https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/view is comment-enabled now.
# [00:33] <jgraham> gsnedders: It works. It occasionally gets patches
# [00:34] <gsnedders> jgraham: are we using it for most things now? last I knew there were concerns over the noisiness of results from it?
# [00:34] <paul_irish> tantek: there is some text around "you need to poll every 100ms for 10+ times to confirm its a continuous second." beyond that, there is no suggestion on how one would acquire those metrics.
# [00:34] <jgraham> paul_irish: THanks
# [00:35] <jgraham> gsnedders: It's being used. I'm not sure what the noise concerns are/were but it's largely stable on gecko
# [00:36] <paul_irish> tantek: http://www.mediaratingcouncil.org/063014%20Viewable%20Ad%20Impression%20Guideline_Final.pdf
# [00:36] <gsnedders> jgraham: just so many fails because of people not using WebIDL for everything
# [00:36] <gsnedders> jgraham: so it being unclear what fails are significant
# [00:36] <gsnedders> jgraham: like, what failures are subtle parts of WebIDL, what failures are fundemental bugs in the implementation of the API
# [00:37] * Joins: gavinc (~gavin@fe9b-4f21-c179-e09a-030d-4002-3420-2062.6rd.ip6.sonic.net)
# [00:38] * Quits: darobin (~darobin@mtl93-18-78-208-93-24.fbx.proxad.net) (Remote host closed the connection)
# [00:39] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Quit: bradleymeck)
# [00:40] <paul_irish> jgraham, tantek: http://www.sfgate.com/ was what kicked off this series. the amount of external script slowing down that site is just mind-blowing. and publishers are the web's bread and butter. :/
# [00:41] <jgraham> gsnedders: Oh, in that sense. Well yes, sometimes browsers don't implement the WebIDL spec correctly and so fail tests. I'm not sure that's a problem for anything other than artifical things like progressing specs
# [00:42] <jgraham> So if you mean "do they get used for CR transitions" then no, I think they are typically ignored
# [00:42] <jsbell> yep; we had that debate for IDB for example since all the fails were in idl tests
# [00:42] <tantek> paul_irish: perhaps it is time for faster independent publishers to displace the inefficient ones.
# [00:42] <jsbell> "It would be nice if..." testharness/report could group errors somehow, e.g. "39 failures because [[Class]] is wrong on your prototypes".
# [00:43] * Quits: plutoniix (~plutoniix@node-10d8.pool-180-180.dynamic.totbb.net) (Quit: จรลี จรลา)
# [00:44] <tantek> paul_irish: going to www.sfgate.com without loading scripts results in empty page content body. so at some point they already killed themselves.
# [00:44] <paul_irish> my point being more that monetizing free content on the web conflicts with delivering a fast (and good) user experience
# [00:44] <JakeA> wanderview: hah you want to make that change now you've implemented it all? :D
# [00:44] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [00:44] <jsbell> wanderview: you around?
# [00:45] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
# [00:47] <tantek> viewing source on sfgate.com...
# [00:47] <tantek> paul_irish: this is hilarious. sfgate is doing the exact *opposite* of the minimum of what you should put in the HTML. they are rendering all the "furniture" (heading, sidebar) nav / boxes statically, and leaving out the article body itself.
# [00:48] <tantek> in ~420k of just the page HTML. Because it's not like adding the article inline would have added much size to 420k of JS, nav, sidebar crap.
# [00:49] <paul_irish> yeah. it's a trainwreck.
# [00:49] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [00:50] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [00:50] * Krinkle|detached is now known as Krinkle
# [00:51] <tantek> because of course you need 33 static copies of <div class="social-links " social-url=".." social-hashId="" social-blurb="> instead of the thing you might actually be sharing.
# [00:51] * Joins: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net)
# [00:51] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [00:51] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [00:52] <tantek> correction: article permalinks are more viewable
# [00:52] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [00:52] <gsnedders> jgraham: I just mean in terms of seeing how interoperable support for things is. "Can I use feature [x] in general and expect it to work?"
# [00:52] <tantek> the home page is the total disaster
# [00:53] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [00:54] * Quits: tschneidereit (~till@2620:101:80fb:224:3559:b40e:9348:f691) (Remote host closed the connection)
# [00:55] * Joins: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635)
# [00:55] <jgraham> gsnedders: Well I wouldn't load interfaces.html for a feature and expect all the failures to mean "this feature doesn't work" without understanding what the tests are
# [00:55] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:56] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 264 seconds)
# [00:56] <jgraham> But I wouldn't recommend doing that with any test
# [00:56] <tantek> paul_irish: e.g. this page shows article text without needing JS: http://www.sfgate.com/news/article/California-drought-Sour-water-a-new-normal-6168768.php
# [01:00] * Quits: aleray (~aleray@91.182.102.197) (Ping timeout: 272 seconds)
# [01:00] <roc> ad visibility detection is a great use-case for async geometry APIs
# [01:00] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [01:01] * Joins: karlcow (~karl@nerval.la-grange.net)
# [01:01] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [01:04] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [01:05] <JakeA> roc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20246 seems like a good idea
# [01:05] <jgraham> karlcow: I don't understand your point
# [01:05] <gsnedders> jgraham: well yes, but it just seems worse than the general case :P
# [01:06] <roc> JakeA: seems like not quite the right thing to me
# [01:06] <karlcow> jgraham: hmm? did I send anything on whatwg list?
# [01:06] <roc> I'll comment in the bug
# [01:06] <jgraham> karlcow: dev.platform
# [01:07] <jgraham> gsnedders: Well perhaps? I mean it's clearer *what*'s being tested here. The tests are rather simple. OTOH some complex tests might need a lot of study to work out if they're edge cases or major parts of the functionality
# [01:07] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Quit: Lost terminal)
# [01:08] * Quits: weinig (~weinig@17.244.160.62) (Quit: weinig)
# [01:08] <gsnedders> jgraham: aye, I guess
# [01:09] <sethf> roc: is there a proposal for an async geometry api?
# [01:09] <roc> not exactly
# [01:09] <sethf> googling didn't find me anything concrete
# [01:09] <roc> there has been some discussion
# [01:09] <roc> F2F
# [01:09] <sethf> i see
# [01:10] <karlcow> I didn't make a point. Or at least I thought so. :) I gave context. It was on dev.platform. Mozilla Brain Parser Activation. Reading the email at first I have read "audit perf" then see the URI, click and then understood. CLICK. Ah it's BLINK. OK. Not what I was expected. it was in the context of Blink rendering engine. Some of these sites behave differently in Firefox.
# [01:10] <karlcow> So if there are other people as brain dead as me, I have context. That's all.
# [01:10] <karlcow> I guess I confused you more.
# [01:11] <karlcow> /expected/expecting/
# [01:11] * Joins: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543)
# [01:13] <jsbell> gsnedders/jgraham: other than Chrome (which I'm intimately familiar with...), at this point how badly do the other browsers tend to fail idlharness tests for nitpicky IDL reasons vs actual feature reasons?
# [01:17] <jgraham> jsbell: Gecko does pretty well I think
# [01:17] <jgraham> We have quite reasonable WebIDL conformance these days, although it's surely not perfect
# [01:17] * Joins: blooberry (Brian@nat/intel/x-mmmhffpzlyvslxyx)
# [01:17] <jsbell> jgraham: yeah, I got IndexedDB/interfaces.html to 100% on gecko
# [01:17] <jgraham> karlcow: Oh, OK
# [01:18] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-uxaqukfaurhvjtiw) (Quit: Connection closed for inactivity)
# [01:18] <jgraham> karlcow: Then my reply probably isn't as useful as I would like :)
# [01:18] <karlcow> heh. Poetry!
# [01:19] * Joins: benwerd (~benwerd@199.87.84.238)
# [01:19] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [01:19] * Joins: benwerd (~benwerd@199.87.84.238)
# [01:20] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [01:25] <gsnedders> jgraham: I thought it depended on which binding API Gecko was using for that API?
# [01:26] * Joins: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net)
# [01:26] <karlcow> ok jgraham I tried to make it more confusing :p ;) replied.
# [01:27] <jgraham> gsnedders: I think the WebIDL bindings are used ~everywhere now, but ask bz or Ms2ger if you actually want to know
# [01:28] * jgraham -> sleep
# [01:29] <gsnedders> jgraham: I could just well be out of touch with what's happened :)
# [01:29] * Joins: scor (~scor@drupal.org/user/52142/view)
# [01:29] <gsnedders> jgraham: I don't exactly pay much attention to "how is Gecko implementing it's DOM bindings?"
# [01:30] * Quits: ambv (~ambv@199.201.64.131) (Ping timeout: 250 seconds)
# [01:39] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [02:00] * Joins: benwerd (~benwerd@199.87.84.238)
# [02:00] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [02:00] * Quits: bnicholson (~bnicholso@corp.mtv2.mozilla.com) (Quit: This computer has gone to sleep)
# [02:02] * Quits: jsbell (jsbell@nat/google/x-naweydyblgxljubr) (Quit: There's no place like home...)
# [02:02] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
# [02:02] * Joins: benwerd (~benwerd@199.87.84.238)
# [02:02] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [02:03] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 250 seconds)
# [02:04] <wanderview> JakeA: which change? lost context
# [02:04] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [02:05] * Quits: marcosc (~marcosc@2001:450:1f:232:2d27:3fd4:617:9543) (Remote host closed the connection)
# [02:06] * Joins: benwerd (~benwerd@199.87.84.238)
# [02:09] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [02:09] * Joins: benwerd (~benwerd@199.87.84.238)
# [02:09] * Quits: jernoble (~jernoble@17.202.46.221) (Remote host closed the connection)
# [02:10] * Joins: marcosc_ (~marcosc@66.207.208.102)
# [02:10] <wanderview> JakeA: oh, if you mean the VARY:* thing... our network stack treats VARY:* as never match, but our Cache implements whats currently in the SW spec
# [02:10] * Joins: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net)
# [02:10] * Quits: jernoble_ (~jernoble@17.202.49.155) (Quit: Textual IRC Client: www.textualapp.com)
# [02:13] <wanderview> I think we should just reject cache.put() if the response has VARY:*
# [02:13] <wanderview> and add/addAll
# [02:21] * Quits: jyasskin (jyasskin@nat/google/x-hppontpcgxmdztsm) (Remote host closed the connection)
# [02:22] * Joins: jyasskin (jyasskin@nat/google/x-xzrbwlielehkttjw)
# [02:24] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [02:26] * Joins: plutoniix (~plutoniix@119.63.87.222)
# [02:30] <gsnedders> wait, does the CSSOM spec still not define element.style.background = "green"?
# [02:30] <gsnedders> i.e., the named property setter (if I'm recalling my WebIDL terminology) on CSSStyleDeclaration?
# [02:32] * Joins: KevinMarks__ (~yaaic@2607:fb90:51f:7cde:4560:5f57:b0b1:d809)
# [02:35] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [02:42] <karlcow> gsnedders: this reminds me of
# [02:42] <karlcow> > The CSSOM spec isn't crystal clear on which behavior is correct, so they might both be considered valid.
# [02:42] <karlcow> https://miketaylr.com/posts/2014/01/when-should-a-stylesheetlist-update.html
# [02:42] <karlcow> not related. :) but CSSOM seems to forget a couple of things
# [02:43] <gsnedders> karlcow: tbf the CSSOM spec was totally unmaintained for such a long while it's not entirely surprising it isn't perfect
# [02:44] <karlcow> https://miketaylr.com/posts/2014/01/yui-set-style-differences.html
# [02:44] <karlcow> :)
# [02:44] <karlcow> gsnedders: yup yup.
# [02:44] <karlcow> part of the funny things.
# [02:45] * Quits: ap_ (~ap@17.114.216.168)
# [02:46] <gsnedders> that involves YUI, I ain't touching that link :)
# [02:49] * Joins: benwerd (~benwerd@199.87.84.238)
# [02:50] <karlcow> In fact, it's about different implementations of setProperty method of CSSStyleDeclaration in different browsers :)
# [02:50] <karlcow> but yeah
# [02:51] <gsnedders> I just have had enough of YUI for my lifetime.
# [02:54] * Quits: benwerd (~benwerd@199.87.84.238) (Ping timeout: 252 seconds)
# [02:55] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:03] * heycam is now known as heycam|away
# [03:07] * Joins: weinig (~weinig@17.244.165.85)
# [03:07] * Quits: weinig (~weinig@17.244.165.85) (Client Quit)
# [03:14] * Quits: othermaciej (~mjs@17.202.48.222) (Quit: othermaciej)
# [03:18] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:22] * Quits: KevinMarks__ (~yaaic@2607:fb90:51f:7cde:4560:5f57:b0b1:d809) (Ping timeout: 256 seconds)
# [03:25] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
# [03:29] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [03:32] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:33] * Joins: othermaciej (~mjs@76.74.153.41)
# [03:33] * Quits: jyasskin (jyasskin@nat/google/x-xzrbwlielehkttjw) (Quit: My computer has gone to sleep. ZZZzzz…)
# [03:34] * Joins: benwerd (~benwerd@199.87.84.238)
# [03:35] * Quits: marcosc_ (~marcosc@66.207.208.102) (Remote host closed the connection)
# [03:36] <MikeSmith> zcorpan: if you could go through http://goo.gl/sJ34Xj and resolve any really old/stale bugs you don't care about keeping open, I'd appreciate it. Anything you would actually still like to see fixed, please do keep it open.
# [03:37] <MikeSmith> zcorpan: for open bugs that we would really like to see fixed, I think eventually we might want to migrate them all to https://github.com/validator/validator/issues But I don't want to do that just yet
# [03:37] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection refused)
# [03:38] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [03:39] * Joins: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d)
# [03:40] * Quits: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d) (Client Quit)
# [03:40] * Joins: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d)
# [03:42] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:46] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:46] * Joins: benwerd (~benwerd@199.87.84.238)
# [03:46] * Quits: annevk (~annevk@213.55.184.211) (Read error: Connection reset by peer)
# [03:49] * heycam|away is now known as heycam
# [03:50] * Quits: yoichio (yoichio@nat/google/x-nhqpkgafuxqvfqij) (Quit: Leaving...)
# [03:50] * Quits: benwerd (~benwerd@199.87.84.238) (Ping timeout: 256 seconds)
# [03:55] * Joins: annevk (~annevk@213.55.184.211)
# [04:08] * Quits: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635) (Ping timeout: 256 seconds)
# [04:15] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
# [04:24] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [04:27] * Joins: karlcow (~karl@nerval.la-grange.net)
# [04:29] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 264 seconds)
# [04:30] * Joins: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net)
# [04:35] * Joins: marcosc (~marcosc@2001:450:1f:232:885e:1704:d6e8:57a6)
# [04:40] * Quits: marcosc (~marcosc@2001:450:1f:232:885e:1704:d6e8:57a6) (Ping timeout: 265 seconds)
# [04:42] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
# [04:47] * Quits: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d) (Ping timeout: 265 seconds)
# [04:48] * Quits: rniwa (~rniwa@17.202.48.231) (Quit: Textual IRC Client: www.textualapp.com)
# [04:49] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
# [04:52] * Joins: ambv (~ambv@199.201.64.2)
# [04:57] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [04:58] * Joins: tripu (~tripu@2001:200:0:8805:5c5b:bd18:71d6:7b64)
# [05:04] * Quits: kochi (~kochi@2401:fa00:4:1000:e5f9:e28e:23e7:3881) (Ping timeout: 265 seconds)
# [05:17] * Joins: kochi (~kochi@2401:fa00:4:1000:2dc6:66ba:37e5:df7f)
# [05:22] * Joins: tantek (~tantek@174.144.81.123)
# [05:27] * Quits: tantek (~tantek@174.144.81.123) (Client Quit)
# [05:34] * Quits: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 32.0/20140902134853])
# [05:36] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [05:41] * Quits: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net) (Quit: eric_carlson)
# [05:42] * heycam is now known as heycam|away
# [05:47] * Joins: marcosc (~marcosc@2001:450:1f:232:b0f4:9ab6:d4a0:d70e)
# [05:52] * Quits: marcosc (~marcosc@2001:450:1f:232:b0f4:9ab6:d4a0:d70e) (Ping timeout: 265 seconds)
# [05:59] * Quits: dwim (~dwim@210.94.41.89) (Read error: Connection reset by peer)
# [05:59] * heycam|away is now known as heycam
# [06:01] * Joins: dwim (~dwim@210.94.41.89)
# [06:02] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Quit: bradleymeck)
# [06:08] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [06:20] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 256 seconds)
# [06:22] * Quits: ambv (~ambv@199.201.64.2) (Quit: sys.exit(0) # app closed)
# [06:23] * Joins: hgl (~hgl@unaffiliated/hgl)
# [06:26] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [06:39] * Joins: ohaibbq (~ohaibbq@2601:9:a80:a8f:53b:5c2e:96e5:c1f2)
# [06:39] * Joins: dlitz (~dwon@goedel.dlitz.net)
# [06:43] * Quits: dmurph (sid42525@gateway/web/irccloud.com/x-knrmffmxuybuieht) (Ping timeout: 272 seconds)
# [06:43] * Quits: slightlyoff (sid1768@gateway/web/irccloud.com/x-zdgzmqahdeazdwdn) (Ping timeout: 272 seconds)
# [06:44] * Joins: dmurph (sid42525@gateway/web/irccloud.com/x-hluhszsiwptinayl)
# [06:44] * Joins: slightlyoff (sid1768@gateway/web/irccloud.com/x-yxcruolxxovailtn)
# [06:44] * Quits: cabanier (sid15093@gateway/web/irccloud.com/x-mqbubqnozrrobsma) (Ping timeout: 272 seconds)
# [06:46] * Joins: cabanier (sid15093@gateway/web/irccloud.com/x-pnmuxmftjpyzfjdb)
# [06:51] * Joins: rniwa (~rniwa@67.164.23.121)
# [07:07] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [07:17] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [07:24] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [07:28] * Quits: rniwa (~rniwa@67.164.23.121) (Quit: Textual IRC Client: www.textualapp.com)
# [07:29] * Quits: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64) (Remote host closed the connection)
# [07:35] * Quits: rektide_ (~rektide@eldergods.com) (Ping timeout: 256 seconds)
# [07:35] * Quits: rektide (~rektide@eldergods.com) (Ping timeout: 256 seconds)
# [07:36] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-ctjblkrenyqnrspm) (Quit: Connection closed for inactivity)
# [07:38] * Quits: yutak (~yutak@2401:fa00:4:1000:dc04:9d34:ea37:eee4) (Ping timeout: 256 seconds)
# [07:50] * Joins: yutak (~yutak@2401:fa00:4:1000:8153:72f3:68fa:67b0)
# [07:52] * Krinkle is now known as Krinkle|detached
# [07:58] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
# [07:59] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [08:02] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [08:18] * heycam is now known as heycam|away
# [08:23] * Quits: jgraham (~jgraham@web91.webfaction.com) (Ping timeout: 252 seconds)
# [08:34] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [08:42] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 248 seconds)
# [08:42] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [08:51] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [08:51] * Quits: ohaibbq (~ohaibbq@2601:9:a80:a8f:53b:5c2e:96e5:c1f2) (Ping timeout: 256 seconds)
# [08:53] * Joins: ohaibbq (~ohaibbq@98.248.65.213)
# [09:04] * Quits: tripu (~tripu@2001:200:0:8805:5c5b:bd18:71d6:7b64) (Quit: Leaving)
# [09:07] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Read error: Connection reset by peer)
# [09:07] * Quits: mpt (~mpt@canonical/mpt) (Read error: Connection reset by peer)
# [09:07] * Joins: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
# [09:07] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
# [09:07] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [09:10] * Joins: mpt (~mpt@2001:67c:1560:a003:c0d8:19bb:7a09:d0b7)
# [09:10] * Quits: mpt (~mpt@2001:67c:1560:a003:c0d8:19bb:7a09:d0b7) (Changing host)
# [09:10] * Joins: mpt (~mpt@canonical/mpt)
# [09:15] * Quits: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net) (Quit: Lingo: www.lingoirc.com)
# [09:15] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 250 seconds)
# [09:20] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [09:27] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Quit: Leaving...)
# [09:29] * Joins: annevk_ (~annevk@213.55.184.211)
# [09:29] * Quits: annevk (~annevk@213.55.184.211) (Read error: Connection reset by peer)
# [09:36] * Joins: capella-s32 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com)
# [09:37] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [09:39] * Quits: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com) (Ping timeout: 252 seconds)
# [09:40] * Quits: capella (~chatzilla@cpe-24-59-162-151.twcny.res.rr.com) (Ping timeout: 252 seconds)
# [09:41] * Joins: capella (~chatzilla@cpe-24-59-162-151.twcny.res.rr.com)
# [09:44] * Joins: darobin (~darobin@159.180.228.142)
# [09:48] * Joins: jochen__ (jochen@nat/google/x-eqwtcrsfdjswsxyo)
# [09:57] * Joins: Ms2ger (~Ms2ger@60.219-242-81.adsl-dyn.isp.belgacom.be)
# [09:58] * Joins: yhirano_ (uid40668@gateway/web/irccloud.com/x-yhsfyrwqllpytypw)
# [10:13] * Joins: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net)
# [10:16] * Joins: jgraham (~jgraham@web91.webfaction.com)
# [10:16] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Read error: Connection reset by peer)
# [10:17] * Joins: zcorpan (~zcorpan@2a00:801:e0:30:7dd5:7145:680f:c21)
# [10:20] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [10:21] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 256 seconds)
# [10:25] * Joins: marcosc (~marcosc@2001:450:1f:232:34b3:912:129d:6672)
# [10:27] * Quits: zcorpan (~zcorpan@2a00:801:e0:30:7dd5:7145:680f:c21) (Ping timeout: 272 seconds)
# [10:30] * Quits: marcosc (~marcosc@2001:450:1f:232:34b3:912:129d:6672) (Ping timeout: 265 seconds)
# [10:31] * Joins: falken (uid20729@gateway/web/irccloud.com/x-hlbmylxyelcouuvf)
# [10:36] * Joins: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
# [10:36] * Quits: jgraham (~jgraham@web91.webfaction.com) (Ping timeout: 264 seconds)
# [10:37] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
# [10:37] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [10:44] * Joins: jgraham (~jgraham@web91.webfaction.com)
# [10:44] * Joins: g4 (~g4@unaffiliated/gormer)
# [10:46] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 265 seconds)
# [10:49] * Joins: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr)
# [10:50] * Joins: wilsonpage (~wilsonpag@27.114.125.91.dyn.plus.net)
# [10:51] * Joins: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
# [10:51] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
# [10:51] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [10:55] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
# [11:00] * Joins: roc (~chatzilla@121-98-104-251.bng1.tvc.orcon.net.nz)
# [11:04] * Quits: annevk_ (~annevk@213.55.184.211) (Quit: Leaving...)
# [11:07] * Joins: annevk (~annevk@77-57-114-240.dclient.hispeed.ch)
# [11:15] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
# [11:26] <mounir> Ms2ger: ping
# [11:26] <Ms2ger> Here
# [11:27] <mounir> Ms2ger: is moving from Foo(DOMString) to Foo(sequence<DOMString>) forward compatible per webidl?
# [11:27] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
# [11:28] <Ms2ger> No
# [11:28] <mounir> interesting
# [11:28] <mounir> would you care to elaborate?
# [11:29] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [11:30] <Ms2ger> Passing a string to a method that takes sequence<DOMString> would throw, I think
# [11:30] <Ms2ger> Oh, no
# [11:31] <Ms2ger> It would be interpreted as a sequence of characters, it seems
# [11:32] <annevk> you'd need to accept either
# [11:32] <mounir> Ms2ger: Foo(DOMString) extended to accept DOMString _or_ sequence<DOMString> would work then?
# [11:33] <Ms2ger> Sure
# [11:35] * Joins: aleray (~aleray@ip-83-101-33-73.customer.schedom-europe.net)
# [11:40] * Quits: aleray (~aleray@ip-83-101-33-73.customer.schedom-europe.net) (Ping timeout: 265 seconds)
# [11:43] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
# [11:44] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 265 seconds)
# [11:46] <annevk> GPHemsley: you around?
# [11:46] <annevk> GPHemsley: I want to outline some stuff that compliments https://mimesniff.spec.whatwg.org/
# [11:47] <annevk> GPHemsley: in particular, we need a place to define how the no-sniff header influences various contexts, such as <script>, <link rel=stylesheet>, etc.
# [11:47] <annevk> GPHemsley: I was thinking of jotting notes down on a wiki page, then getting that implemented, and then filing bugs to standardize it
# [11:56] * Quits: psy_ (~psy@103.6.159.177) (Ping timeout: 250 seconds)
# [12:00] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
# [12:09] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 256 seconds)
# [12:11] * Joins: hgl (~hgl@unaffiliated/hgl)
# [12:12] * Joins: psy_ (~psy@103.6.159.177)
# [12:15] * Joins: zcorpan (~zcorpan@2a00:801:e0:30:d11e:6ea3:6baa:77ab)
# [12:16] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [12:18] * Quits: psy_ (~psy@103.6.159.177) (Ping timeout: 252 seconds)
# [12:18] * Joins: psy_ (~psy@103.6.159.177)
# [12:26] * Quits: plutoniix (~plutoniix@119.63.87.222) (Quit: จรลี จรลา)
# [12:33] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [12:35] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
# [12:38] * Quits: Ms2ger (~Ms2ger@60.219-242-81.adsl-dyn.isp.belgacom.be) (Quit: bbl)
# [12:44] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [12:46] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [12:48] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [12:48] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [12:49] * Joins: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
# [12:49] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
# [12:49] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [12:50] <annevk> jgraham: can web-platform-tests handle the case where I issue a HEAD and it responds with something that includes a body?
# [12:52] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [13:15] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
# [13:15] <jgraham> annevk: Yes
# [13:22] * Joins: frivoal_ (~frivoal@cm-84.208.175.177.getinternet.no)
# [13:23] * Quits: frivoal_ (~frivoal@cm-84.208.175.177.getinternet.no) (Client Quit)
# [13:25] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [13:31] * Quits: Yudai__ (~Yudai@73.170.83.204) (Ping timeout: 255 seconds)
# [13:31] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
# [13:34] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-obnujaoueevmzlfc)
# [13:39] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [13:43] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [13:46] * Joins: newtron (~newtron@75-119-235-26.dsl.teksavvy.com)
# [13:47] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
# [13:47] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 256 seconds)
# [13:50] * Quits: benjamingr (uid23465@gateway/web/irccloud.com/x-afqntjgmlywbxikm) (Quit: Connection closed for inactivity)
# [13:51] * Joins: hgl (~hgl@unaffiliated/hgl)
# [13:55] * Quits: newtron (~newtron@75-119-235-26.dsl.teksavvy.com) (Remote host closed the connection)
# [13:59] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [14:11] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Remote host closed the connection)
# [14:11] * Joins: wnklb (~winklebee@p4FE1563E.dip0.t-ipconnect.de)
# [14:15] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [14:21] * Joins: scor (scor@nat/acquia/x-mxxvumyhdfylcdkc)
# [14:22] * Quits: scor (scor@nat/acquia/x-mxxvumyhdfylcdkc) (Changing host)
# [14:22] * Joins: scor (scor@drupal.org/user/52142/view)
# [14:26] <GPHemsley> annevk: I'm here now, for a moment. But if you want to write stuff on the wiki, I can look at it when I have more time.
# [14:28] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
# [14:39] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [14:40] <annevk> Is there a way to reset a git repo?
# [14:41] <annevk> E.g. currently web-platform-tests suggests I've made some change to "tools" but I've no idea how to undo that
# [14:41] <GPHemsley> git reset --hard
# [14:41] <jgraham> Ah, well tools is a submodule (if you pulled recently)
# [14:41] <jgraham> So it's a bit more compilcated
# [14:41] <annevk> "fatal: Not a git repository: tools/../.git/modules/tools"
# [14:42] <jgraham> Yeah, please rm -r that folder
# [14:42] <jgraham> i.e. .git/modules/tools
# [14:42] <jgraham> Then git submodule update --init --recursive
# [14:44] <zcorpan> fatal: Not a git repository: ../.git/modules/tools
# [14:44] <zcorpan> Unable to find current revision in submodule path 'tools'
# [14:44] <zcorpan> after those instructions
# [14:44] <annevk> yeah
# [14:44] <annevk> same
# [14:45] * Joins: newtron (~newtron@199.71.174.203)
# [14:45] <jgraham> Hmm
# [14:45] <jgraham> git is really properly terrible at deleing subrepos
# [14:45] * Quits: ^esc_ (~esc-ape@178.165.131.93.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
# [14:46] <jgraham> So does .git/modules/tools exist at all?
# [14:46] <zcorpan> no
# [14:46] <zcorpan> html5lib and resources exist in .git/modules/
# [14:47] <annevk> same
# [14:47] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
# [14:47] <zcorpan> now `git fetch upstream` also results in fatal: Not a git repository: tools/../.git/modules/tools :-)
# [14:49] <jgraham> so I would kind of expect git submodule init to fix this
# [14:49] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [14:49] <jgraham> Maybe delete the tools/ directory and everything under .git/modules and git submodule update --init --recursive again?
# [14:50] <annevk> "fatal: Not a git repository: ../.git/modules/resources"
# [14:50] <annevk> "Unable to find current revision in submodule path 'resources'"
# [14:50] <GPHemsley> Make sure .git/config is in the proper state
# [14:50] <annevk> blargh
# [14:50] <jgraham> Yeah remove resources/ too
# [14:51] <annevk> I did
# [14:51] <zcorpan> same result here
# [14:51] <jgraham> So you have no $WPT_ROOT/resources directory and no $WPT_ROOT/tools directory?
# [14:52] <jgraham> and $WPT_ROOT/.git/modules is an empty directory?
# [14:52] <zcorpan> yep. i tried removing the modules directory itself also but no difference
# [14:52] <jgraham> Hmm, well I just did exactly that and it wfm
# [14:52] <annevk> jgraham: yeah works
# [14:53] * Joins: jsx (uid48919@fsf/intern/jsx)
# [14:53] <annevk> jgraham: didn't realize what you meant by resources/ thought you meant .git/modules/resources
# [14:53] <annevk> jgraham: one final question, how do I start the server again?
# [14:53] <zcorpan> [submodule "tools"]
# [14:53] <zcorpan> url = https://github.com/w3c/wpt-tools.git
# [14:53] * Joins: ^esc (~esc-ape@178.165.131.197.wireless.dyn.drei.com)
# [14:53] <zcorpan> GPHemsley: ^
# [14:53] <jgraham> https://pastebin.mozilla.org/8827681
# [14:53] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 272 seconds)
# [14:53] <jgraham> annevk: ./serve
# [14:54] <jgraham> in the root directory
# [14:54] <GPHemsley> zcorpan: If things are in a hybrid state of deletion, you may want to remove that section of the file and reinit the submodules
# [14:54] <zcorpan> ah. ok now it seems to work
# [14:54] <zcorpan> excellento. thx
# [14:55] <GPHemsley> annevk: Any pressing questions you have for me before I leave?
# [14:55] <annevk> GPHemsley: no, thanks
# [14:56] <GPHemsley> OK, then I'll just leave you with the reminder of the existence of https://wiki.whatwg.org/wiki/Contexts
# [14:56] <GPHemsley> Let me know where you need me to look later
# [15:01] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [15:10] * Quits: wilsonpage (~wilsonpag@27.114.125.91.dyn.plus.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [15:11] <annevk> jgraham: see https://github.com/w3c/web-platform-tests/pull/1697 for my test
# [15:11] * Quits: g4 (~g4@unaffiliated/gormer) (Quit: Leaving)
# [15:13] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [15:16] * Joins: zenith_ (~zenith@user3-87-149.wireless.utoronto.ca)
# [15:18] * Quits: falken (uid20729@gateway/web/irccloud.com/x-hlbmylxyelcouuvf) (Quit: Connection closed for inactivity)
# [15:22] * Joins: Ms2ger (~Ms2ger@193.190.253.150)
# [15:23] * Quits: zenith_ (~zenith@user3-87-149.wireless.utoronto.ca) (Ping timeout: 250 seconds)
# [15:26] * Joins: zenith_ (~zenith@user3-87-149.wireless.utoronto.ca)
# [15:31] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [15:37] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
# [15:40] * Joins: hasather (~hasather@vpn-managed.schibsted.no)
# [15:40] <JakeA> annevk: given that fetch/XHR are HTTP APIs, and a response inc. body from a HEAD request is a violation, is it fair or not that the browsers try and do something to error correct?
# [15:40] <JakeA> I can argue it both ways
# [15:41] <annevk> Yes :-)
# [15:42] * Joins: mven (~textual@32.97.110.57)
# [15:42] * Quits: mven (~textual@32.97.110.57) (Excess Flood)
# [15:44] <annevk> JakeA: since even Content-Length means something different arguably throwing away the body is sane
# [15:45] * Joins: zenith__ (~zenith@199-7-157-111.eng.wind.ca)
# [15:45] <annevk> JakeA: what IE does makes no sense btw
# [15:48] * Quits: zenith_ (~zenith@user3-87-149.wireless.utoronto.ca) (Ping timeout: 244 seconds)
# [15:48] * Joins: eric_carlson (~ericc@17.202.49.94)
# [15:48] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [15:58] * Joins: TallTed (~Thud@63.119.36.36)
# [15:59] <wanderview> annevk: is this a general problem or does it sound chrome specific to you? https://code.google.com/p/chromium/issues/detail?id=448427
# [16:00] <wanderview> its unclear to me if "cross origin favicon tainting" is a consequence of the way chrome does content process caching or a general web attack
# [16:00] * halfline is now known as ||
# [16:01] * || is now known as halfline
# [16:02] <annevk> wanderview: I'm not sure what that means
# [16:02] * Joins: eBureau (~Bruno@181.164.77.172)
# [16:02] <annevk> wanderview: not sure why a favicon is different
# [16:03] <wanderview> I'm going to assume its a chrome-specific issue
# [16:03] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
# [16:04] <smaug____> who wants to spec how resize event works
# [16:05] <annevk> smaug____: zcorpan
# [16:05] <smaug____> good
# [16:07] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [16:08] <MikeSmith> what's the best way for a normal person to collect usage data on a particular API?
# [16:08] <MikeSmith> other than by browser-project telemetry I mean
# [16:09] <annevk> MikeSmith: there's not really any other reliable way
# [16:09] <wanderview> annevk: how will the fetch issue solve the HEAD method thing for Cache?
# [16:10] <annevk> wanderview: it won't, that was the point
# [16:10] <JakeA> It won't
# [16:10] <wanderview> oh... "this issue" means the SW issue, not the fetch issue you linked in the first sentence
# [16:10] <wanderview> its morning in america
# [16:10] <annevk> typical wanderview coffee excuse :p
# [16:11] <wanderview> annevk: if only I could use that in the afternoon too...
# [16:11] * wanderview feels slightly dirty for quoting Ronald Reagan.
# [16:12] <JakeA> That was all good fun, been a while since I did some low-level HTTP testing
# [16:17] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Quit: ChatZilla 0.9.91.1 [Firefox 39.0a1/20150329030238])
# [16:18] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
# [16:18] * Quits: wnklb (~winklebee@p4FE1563E.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
# [16:18] * Joins: rektide (~rektide@eldergods.com)
# [16:19] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
# [16:20] <wanderview> JakeA: speaking of which... I remember you did some of that to see what browsers do when the body is truncated by a network error, right?
# [16:21] <wanderview> guess I'm still wondering what to do here: https://github.com/slightlyoff/ServiceWorker/issues/665
# [16:21] <zcorpan> smaug____: http://dev.w3.org/csswg/cssom-view/#resizing-viewports
# [16:22] <zcorpan> smaug____: https://html.spec.whatwg.org/multipage/webappapis.html#run-the-resize-steps
# [16:22] * Joins: winklebee (~winklebee@p4FE1563E.dip0.t-ipconnect.de)
# [16:27] * zecho_ is now known as zecho
# [16:33] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 252 seconds)
# [16:33] <JakeA> wanderview: yeah https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-48612616
# [16:34] * Joins: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp)
# [16:35] * Joins: kruppel (~kruppel@192.161.158.18)
# [16:36] * Joins: karlcow (~karl@nerval.la-grange.net)
# [16:36] * Joins: sarri (~sari@unaffiliated/sarri)
# [16:41] <wanderview> JakeA: yea... it just seems a bit scary to me to potentially have truncated values in Cache
# [16:42] <wanderview> JakeA: I wonder if we should have some kind of strict mode in Cache that rejects if content-length is wrong
# [16:42] <wanderview> rather than make all script authors deal with this condition themslves
# [16:45] <smaug____> zcorpan: that is surprising
# [16:45] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [16:45] <zcorpan> smaug____: what? that it's specced?
# [16:45] <smaug____> the behavior is a bit surprising
# [16:46] <smaug____> I would have expected we spec resize to fire around animation frame callbacks
# [16:46] <smaug____> but ok, perhaps this is fine too
# [16:46] <smaug____> why isn't it just using a task?
# [16:46] <smaug____> to fire the event
# [16:47] * smaug____ hasn't looked at 8.1.4.2 Processing model for ages
# [16:47] <smaug____> very different to how Gecko works :/
# [16:50] <smaug____> wait, I'm misreading it or what.. "An event loop must continually run through the following steps for as long as it exists:" ... "For each fully active Document in docs, run the animation frame callbacks for that Document, passing in now as the timestamp."
# [16:50] <smaug____> I see, that mixes animation frame handling into the event loop
# [16:51] <JakeA> wanderview: If we need a strict mode, shouldn't it go on fetch()?
# [16:52] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Quit: bradleymeck)
# [16:52] <smaug____> so fine (just differently modeled comparing to what I have in mind for animation frame handling and such)
# [16:52] <wanderview> JakeA: well, its Cache that has to decide what to do if the body stream is truncated, no?
# [16:52] <zcorpan> smaug____: it's intended to fire just before animation frame callbacks
# [16:52] <smaug____> but end result should be the same
# [16:53] <zcorpan> smaug____: it was using a task before but we changed it to sync with animation frames since impls do that or want to do that
# [16:53] <wanderview> JakeA: I mean... content uses fetch() can decide what to do if the Response.body stream gives them an error
# [16:53] <JakeA> wanderview: hmm yeah, good point
# [16:53] <wanderview> JakeA: but if there is no way for Cache to surface an error after resolving Cache.put() promise... then it needs some strategy for handling it
# [16:54] * Quits: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving)
# [16:54] <smaug____> zcorpan: some impls do that
# [16:54] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [16:54] <smaug____> but ok
# [16:54] <smaug____> I think this is fine
# [16:55] <zcorpan> smaug____: it's possible that the event loop spec is wrong and should be changed in some way. i think bz had vague concerns about it not matching impls (or at least gecko)
# [16:55] <zcorpan> smaug____: ok
# [16:55] <smaug____> it means that resize is occasionally pending while layout has changed its state already
# [16:55] <zcorpan> another issue here is that the concept of flushing layout is not specced yet
# [16:56] <JakeA> wanderview: wondering if .text() etc should also reject
# [16:57] <wanderview> JakeA: I think it should, yea
# [16:58] <wanderview> JakeA: can it provide the partial body if it rejects? or just say "use the stream version" if you want that behavior
# [17:02] * Joins: wilsonpage (~wilsonpag@27.114.125.91.dyn.plus.net)
# [17:03] <smaug____> zcorpan: shoud resize fire if an iframe is first resized to size foo,bar, then foo+1, bar+1, and then back to foo,bar, before animation frame callbacks are run?
# [17:04] <annevk> GPHemsley: FWIW, the Contexts wiki page is hopelessly out of date with respect to the number of contexts
# [17:08] <JakeA> wanderview: it should reject with an error, it's possible but weird to have the partial as a property of the error. I think that might be too weird though
# [17:09] * Quits: zenith__ (~zenith@199-7-157-111.eng.wind.ca) (Remote host closed the connection)
# [17:09] <wanderview> yea... especially with promise propagation
# [17:10] * Joins: wilsonpa_ (~wilsonpag@116.2.125.91.dyn.plus.net)
# [17:11] * Quits: wilsonpage (~wilsonpag@27.114.125.91.dyn.plus.net) (Ping timeout: 265 seconds)
# [17:13] <Domenic> why does fetch/cache care about the content-length header at all?
# [17:14] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [17:15] <zcorpan> smaug____: how do you interpret the spec for that case? "If doc’s viewport has had its width or height changed ... since the last time these steps were run"
# [17:15] <zcorpan> maybe it should say if the width and height are different, rather than have changed
# [17:16] <JakeA> wanderview: I guess the cache should take the whole body stream, and it's down to stream consumers to decide if they carry on reading or not
# [17:17] <wanderview> JakeA: not sure I understand... what does "take the whole body stream" mean if there is an error while reading Response.body and streaming it to disk?
# [17:17] <JakeA> Domenic: if a request has a content-length, should the stream stop at that content length even if there's more content?
# [17:18] <JakeA> wanderview: I mean if the body stream is > content-length. If there's an error reading response.body it shouldn't go into the cache
# [17:18] <Domenic> JakeA: I would just treat content-length as incidental metadata that in some authors' minds might have some relation to the body length in bytes, or might not
# [17:18] <Domenic> not sure how that squares with XHR though
# [17:18] <wanderview> JakeA: yea... I don't think we can make content-length strict by default... too many broken servers out there
# [17:19] <wanderview> at least, we can never seem to get away with it in FF for other network requests
# [17:19] <JakeA> Domenic: that's fair. Although .text etc may truncate at content-length, that's how browsers seem to behave today
# [17:19] <Domenic> JakeA: hmm I mean that seems OK but unnecessary
# [17:20] * Joins: zenith_ (~zenith@142.150.23.90)
# [17:20] <JakeA> Domenic: I know what you mean, but it's something all browsers do so I guess there's a good reason. Maybe it's ok to break that tradition with fetch()
# [17:21] <Domenic> I dunno, I feel like we need an expert :)
# [17:21] <JakeA> Can't we just make shit up outselves?
# [17:21] <JakeA> Can't we just make up words like "outselves"?
# [17:21] <Domenic> aka "all the web platform"
# [17:22] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [17:23] <Domenic> annevk: @fetchstandard should tweet this question and we'll all RT
# [17:23] <JakeA> What? "Can't we just make shit up ourselves?"
# [17:24] <Domenic> lol
# [17:24] <Domenic> i meant, should content-length have any impact on .json(), but that works too
# [17:24] <Domenic> hmm
# [17:24] <wanderview> JakeA: pretty sure gecko is going to ignore content-length for the short term...
# [17:24] <Domenic> what if the stream ends early before content-length is reached
# [17:24] <wanderview> too many servers send the wrong value when gzip content-encoding is applied
# [17:25] <Domenic> do we error or ignore content-length or...?
# [17:25] <JakeA> Domenic: that tends to be an error
# [17:25] <Domenic> hmm
# [17:25] <Domenic> given the gzip thing i'm not sure i believe you?
# [17:26] <wanderview> I think some browsers with less legacy just return error there
# [17:26] <JakeA> Domenic: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-48612616 - although this research was done by past-Jake and I don't trust that guy
# [17:26] <Domenic> ah that's very nice
# [17:26] <JakeA> Maybe I'd have seen different results with gzipping
# [17:26] <JakeA> I didn't test that
# [17:27] <wanderview> its harder for us because "Firefox used to work, but doesn't in this new release!" when we try to treat content-length strictly
# [17:27] * Quits: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net) (Quit: othermaciej)
# [17:27] <JakeA> wanderview: In my tests, content-length > content caused Firefox to wait until timeout
# [17:28] <JakeA> Maybe that was keep-alive
# [17:28] <wanderview> JakeA: maybe we check in one direction and not the other... probably depends on exactly what server bugs we have to bend to
# [17:31] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [17:32] <wanderview> can we just spec the network to be infallible
# [17:32] <wanderview> and no aborting fetches
# [17:36] <Domenic> yes please
# [17:38] * Joins: othermaciej (~mjs@76.74.153.49)
# [17:41] * Quits: zcorpan (~zcorpan@2a00:801:e0:30:d11e:6ea3:6baa:77ab) (Remote host closed the connection)
# [17:43] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [17:45] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [17:49] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 246 seconds)
# [17:53] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
# [17:53] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [17:54] * Quits: othermaciej (~mjs@76.74.153.49) (Quit: othermaciej)
# [17:59] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Remote host closed the connection)
# [18:05] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
# [18:05] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [18:05] * Krinkle|detached is now known as Krinkle
# [18:13] * Joins: benwerd (~benwerd@199.87.84.238)
# [18:14] * Joins: ap (~ap@17.202.44.214)
# [18:16] * Joins: hasather_ (~hasather@cm-84.210.170.16.getinternet.no)
# [18:16] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [18:17] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Read error: Connection reset by peer)
# [18:17] * Joins: jsbell (jsbell@nat/google/x-ynsmeuclnggijktf)
# [18:17] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [18:17] * Joins: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com)
# [18:18] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
# [18:18] * Joins: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net)
# [18:19] * Quits: hasather (~hasather@vpn-managed.schibsted.no) (Ping timeout: 244 seconds)
# [18:21] * Quits: hasather_ (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 256 seconds)
# [18:22] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
# [18:25] * Joins: plutoniix (~plutoniix@node-11fb.pool-180-180.dynamic.totbb.net)
# [18:26] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [18:27] * Quits: wilsonpa_ (~wilsonpag@116.2.125.91.dyn.plus.net) (Quit: Textual IRC Client: www.textualapp.com)
# [18:27] <annevk> wanderview: we do use Content-Length to some extent
# [18:27] * Quits: bradleymeck (~bradleyme@99-20-94-62.lightspeed.austtx.sbcglobal.net) (Ping timeout: 264 seconds)
# [18:27] <annevk> but I doubt it matters much in an HTTP/2 world
# [18:28] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Remote host closed the connection)
# [18:29] * Joins: Maurice` (copyman@unaffiliated/maurice)
# [18:29] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [18:31] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:31] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [18:31] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [18:32] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:33] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [18:34] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:35] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:37] <annevk> JakeA: your responses to https://github.com/slightlyoff/ServiceWorker/issues/651 don't really seem to take into account OP
# [18:37] <annevk> JakeA: if I stream the body from a response, the SW shutting down once the promise resolves kills the body
# [18:37] <annevk> doesn't*
# [18:38] * Joins: bnicholson (~bnicholso@corp.mtv2.mozilla.com)
# [18:38] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
# [18:39] <JakeA> annevk: ah yes, I got lost in the replies
# [18:40] * Joins: zcorpan (~zcorpan@ip-200.t2.se.opera.com)
# [18:41] * Joins: wilsonpage (~wilsonpag@116.2.125.91.dyn.plus.net)
# [18:42] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [18:43] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [18:44] * Quits: darobin (~darobin@159.180.228.142) (Remote host closed the connection)
# [18:44] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [18:44] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
# [18:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [18:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
# [18:51] * Joins: benwerd (~benwerd@199.87.84.238)
# [18:52] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-xyhitqlwjlgcebhz) (Quit: Connection closed for inactivity)
# [18:53] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [18:56] * Quits: LJWatson (~chatzilla@cpc2-hawk13-2-0-cust240.aztw.cable.virginm.net) (Quit: Carpe diem)
# [18:57] <wanderview> jsbell: hi, were you looking for me yesterday?
# [19:10] * Quits: dshwang (~dshwang@134.134.137.73) (Remote host closed the connection)
# [19:15] <smaug____> zcorpan: back. So I interpret it so that if there was a change after last resize, fire a new resize, even if the current size is the same.
# [19:16] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:16] <smaug____> zcorpan: do you happen to know what blink does currently?
# [19:20] * Quits: zenith_ (~zenith@142.150.23.90) (Read error: Connection reset by peer)
# [19:21] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 256 seconds)
# [19:21] * Joins: zenith_ (~zenith@142.150.23.90)
# [19:22] * Joins: marcosc (~marcosc@2001:450:1f:232:34b3:912:129d:6672)
# [19:27] * Quits: marcosc (~marcosc@2001:450:1f:232:34b3:912:129d:6672) (Ping timeout: 256 seconds)
# [19:27] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:30] * Quits: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr) (Ping timeout: 246 seconds)
# [19:36] * Joins: marcosc (~marcosc@66.207.208.102)
# [19:37] * Quits: kruppel (~kruppel@192.161.158.18) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [19:39] * Quits: zenith_ (~zenith@142.150.23.90) (Remote host closed the connection)
# [19:44] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [19:45] * Joins: zenith_ (~zenith@142.150.23.90)
# [19:46] * Quits: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com) (Quit: Ex-Chat)
# [19:47] * Joins: r2 (~r2@66.94.71.3)
# [19:49] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [19:50] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [19:52] * Joins: ehsan (~ehsan@2001:450:1f:224:e825:c231:ddcb:4231)
# [19:52] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Remote host closed the connection)
# [19:52] * Joins: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net)
# [19:53] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
# [19:55] * Joins: marcosc_ (~marcosc@2001:450:1f:232:f1cc:6503:ef79:d488)
# [19:55] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
# [19:56] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:57] * Quits: wilsonpage (~wilsonpag@116.2.125.91.dyn.plus.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [19:57] * Quits: marcosc (~marcosc@66.207.208.102) (Ping timeout: 252 seconds)
# [19:57] * Quits: marcosc_ (~marcosc@2001:450:1f:232:f1cc:6503:ef79:d488) (Read error: Connection reset by peer)
# [19:58] * Joins: marcosc (~marcosc@66.207.208.102)
# [20:00] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:00] <jsbell> wanderview: yeah, sorry. Wanted to see if your CacheStorage was exposed to windows yet or just for SW contexts
# [20:01] <wanderview> ah... I think I ended up answer on list
# [20:01] <jsbell> wanderview: but you replied on blink-dev :)
# [20:01] <wanderview> yep :-)
# [20:01] <wanderview> thanks
# [20:01] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 264 seconds)
# [20:01] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [20:02] <jgraham> jsbell: Thanks for the heads up
# [20:04] <jsbell> np
# [20:04] * Quits: marcosc (~marcosc@66.207.208.102) (Ping timeout: 256 seconds)
# [20:05] <jsbell> wanderview: also, I just told jgraham (via email), but I revamped the blink tests for cache storage (yesterday) so if you were pulling those, now's a good time to re-grab them
# [20:05] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [20:06] <wanderview> thanks
# [20:06] * Joins: iandevlin (~iandevlin@dslb-092-072-178-168.092.072.pools.vodafone-ip.de)
# [20:06] <wanderview> I don't think we're quite running those yet
# [20:08] <wanderview> I did some temporary hacks in our tree to run them before... but have not tried again in the last few months
# [20:08] * Joins: kruppel (~kruppel@192.161.158.18)
# [20:09] <Ms2ger> So is TabAtkins going to do the geocities look again?
# [20:10] * Joins: bradleymeck (~bradleyme@70.114.246.88)
# [20:10] <jgraham> I was sort of hoping that the upstream tests would be revamped a bit to make dealing with the origin issues a bit easier before I had another go at importing them into wpt
# [20:13] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [20:14] <jsbell> jgraham: once this is out the door I'm hoping to tackle that. the cache ones don't have any actual server references except one php file, at least
# [20:15] * Joins: marcosc (~marcosc@2001:450:1f:232:151c:fd82:9fb5:771b)
# [20:15] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-dcvvzmnninamdaes)
# [20:26] <jgraham> jsbell: Oooh, that seems like something I could import rather quickly then :)
# [20:27] * Quits: r2 (~r2@66.94.71.3) (Quit: Leaving)
# [20:28] * Joins: benwerd (~benwerd@199.87.84.238)
# [20:34] * Joins: othermaciej (~mjs@17.244.163.90)
# [20:36] * Quits: iandevlin (~iandevlin@dslb-092-072-178-168.092.072.pools.vodafone-ip.de) (Quit: Nettalk6 - www.ntalk.de)
# [20:39] * Joins: ambv (~ambv@199.201.64.131)
# [20:42] * Joins: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635)
# [20:45] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [20:47] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [20:51] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 252 seconds)
# [20:53] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
# [20:53] * Joins: benwerd (~benwerd@199.87.84.238)
# [20:55] * Joins: zenith__ (~zenith@142.150.23.82)
# [20:56] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 256 seconds)
# [20:56] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [20:59] * Quits: zenith__ (~zenith@142.150.23.82) (Ping timeout: 244 seconds)
# [21:01] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 244 seconds)
# [21:03] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [21:07] * Joins: aleray (~aleray@ip-83-101-52-152.customer.schedom-europe.net)
# [21:08] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [21:10] * Joins: rniwa (~rniwa@17.202.48.231)
# [21:11] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
# [21:13] * Quits: othermaciej (~mjs@17.244.163.90) (Quit: othermaciej)
# [21:18] * Joins: othermaciej (~mjs@17.244.163.90)
# [21:20] * Joins: thinkxl__ (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
# [21:23] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Ping timeout: 256 seconds)
# [21:23] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [21:26] * Quits: ehsan (~ehsan@2001:450:1f:224:e825:c231:ddcb:4231) (Ping timeout: 256 seconds)
# [21:32] * Joins: zenith_ (~zenith@142.150.23.90)
# [21:33] * Quits: aleray (~aleray@ip-83-101-52-152.customer.schedom-europe.net) (Ping timeout: 252 seconds)
# [21:34] * thinkxl__ is now known as thinkxl
# [21:34] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Changing host)
# [21:34] * Joins: thinkxl (~thinkxl@unaffiliated/thinkxl)
# [21:36] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 252 seconds)
# [21:37] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
# [21:43] * Joins: ehsan (~ehsan@2001:450:1f:224:e825:c231:ddcb:4231)
# [21:46] * Joins: aleray (~aleray@109.128.131.182)
# [21:50] * Quits: thinkxl (~thinkxl@unaffiliated/thinkxl) (Quit: Lost terminal)
# [21:58] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [22:01] * Quits: rego (~rego@66.193.27.77.dynamic.mundo-r.com) (Remote host closed the connection)
# [22:01] * Joins: rego (~rego@66.193.27.77.dynamic.mundo-r.com)
# [22:01] * Quits: nicolastarzia (~nicolasta@201.90.94.104) (Remote host closed the connection)
# [22:02] * Quits: benwerd (~benwerd@199.87.84.238) (Remote host closed the connection)
# [22:05] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [22:06] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 256 seconds)
# [22:06] * Joins: mven (~textual@32.97.110.57)
# [22:06] * Quits: mven (~textual@32.97.110.57) (Excess Flood)
# [22:07] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
# [22:07] * Joins: mven (~textual@32.97.110.57)
# [22:08] * Quits: mven (~textual@32.97.110.57) (Excess Flood)
# [22:10] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [22:10] * Joins: karlcow (~karl@nerval.la-grange.net)
# [22:11] * Quits: dbaron (~dbaron@2620:101:80fb:224:6120:58ca:192e:4635) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [22:12] * Joins: jyasskin (jyasskin@nat/google/x-dminaaufolozthcp)
# [22:12] * Joins: dbaron (~dbaron@2620:101:80fb:232:bcf8:999c:2e9f:546c)
# [22:15] * Quits: zcorpan (~zcorpan@ip-200.t2.se.opera.com) (Remote host closed the connection)
# [22:16] * Joins: zcorpan (~zcorpan@2a00:801:e0:30:d11e:6ea3:6baa:77ab)
# [22:17] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [22:17] * Joins: nicolastarzia (~nicolasta@201.90.94.104)
# [22:19] * Quits: eric_carlson (~ericc@17.202.49.94) (Ping timeout: 256 seconds)
# [22:19] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
# [22:22] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 265 seconds)
# [22:23] * Quits: roc (~chatzilla@121-98-104-251.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
# [22:24] <zcorpan> smaug____: in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3477 i get one resize event in blink, two events in gecko. remove the clientWidth and i get no events in either.
# [22:24] <smaug____> zcorpan: in my test case blink fired event, gecko didn't
# [22:25] <smaug____> zcorpan: https://pastebin.mozilla.org/8827770
# [22:25] <zcorpan> smaug____: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3478 webkit 2 events
# [22:26] * Joins: eBureau (~Bruno@181.164.77.172)
# [22:26] <smaug____> ah, you have layout flush
# [22:26] * Quits: rcombs (~rcombs@rcombs.me) (Read error: Connection reset by peer)
# [22:27] <zcorpan> yeah. different case from what you asked about i suppose :-)
# [22:27] <smaug____> oh, wait, blink fires resize even without any actual resize
# [22:27] * Joins: rcombs (~rcombs@rcombs.me)
# [22:29] <smaug____> zcorpan: so current Gecko fires resize if there is one pending and one does layout flush
# [22:29] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Ping timeout: 248 seconds)
# [22:29] <smaug____> otherwise resize is fired async
# [22:29] <zcorpan> blink seems to fire resize sometimes (?) when loading an iframe
# [22:30] <zcorpan> smaug____: ok
# [22:30] <smaug____> my testcase runs after the iframe has been loaded
# [22:31] <smaug____> and resize should fire before animation frame callbacks
# [22:31] <smaug____> so gecko nor blink follows the current spec
# [22:32] <smaug____> s/so/so not/
# [22:32] <zcorpan> right
# [22:33] <zcorpan> blink fires an event here which is pretty weird http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3479
# [22:33] * Joins: eric_carlson (~ericc@17.202.49.252)
# [22:33] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [22:33] * Joins: jpdevries (~jpdevries@c75-111-13-43.erkacmtk01.ca.dh.suddenlink.net)
# [22:34] <smaug____> does it perhaps just fire pending resize after animation frame callbacks have run?
# [22:36] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Quit: bradleymeck)
# [22:36] * Joins: jernoble (~jernoble@17.202.46.221)
# [22:38] <Domenic> TabAtkins: I am a bit confused by Bikeshed's "Terms defined by this specification" vs. exported dfns. Is there anywhere in the output that lists exported dfns?
# [22:38] <zcorpan> maybe. but there shouldn't be any resize at all in this case (unless it considers a page load to be a resize)
# [22:40] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
# [22:40] <Domenic> TabAtkins: also how should I mark up ES-style "abstract operations" that I want other specs to be able to call? Just <dfn>s? But they are already <h4>s... what's the suggested markup?
# [22:40] <smaug____> zcorpan: sure. But does blink perhaps fire resize always after animation frame callbacks?
# [22:41] * Quits: Ms2ger (~Ms2ger@193.190.253.150) (Quit: nn)
# [22:41] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [22:41] <smaug____> I'm just about to upload a patch to change gecko's behavior to fire resize around animation frames, but would be good to know whether event should fire before or after the callbacks
# [22:44] * Quits: psy_ (~psy@103.6.159.177) (Ping timeout: 250 seconds)
# [22:45] <zcorpan> smaug____: i'm not sure how to test the order
# [22:46] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
# [22:46] <zcorpan> smaug____: i think the html spec's order has some reasoning behind it, that animation frames happen last
# [22:47] <zcorpan> animation frame callbacks
# [22:48] <smaug____> not sure the order matters much
# [22:48] <smaug____> except for interoperability
# [22:50] * smaug____ tries to find where blink dispatches resize
# [22:50] * Quits: othermaciej (~mjs@17.244.163.90) (Quit: othermaciej)
# [22:52] * Joins: othermaciej (~mjs@17.244.163.90)
# [22:53] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [22:54] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [22:56] <zcorpan> smaug____: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/FrameView.cpp&q=enqueueresizeevent&sq=package:chromium&type=cs&l=2102
# [22:58] <smaug____> that doesn't dispatch it, right?
# [22:58] <smaug____> ensureScriptedAnimationController().enqueuePerFrameEvent
# [22:58] <smaug____> no idea what that might do
# [22:58] <smaug____> sounds like something not what the spec says
# [22:59] * Quits: TallTed (~Thud@63.119.36.36)
# [22:59] <zcorpan> it predates the spec changes, so entirely possible it is not at all what the spec says
# [22:59] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [23:00] <zcorpan> i'd try to match the spec unless you find the spec insane
# [23:00] <smaug____> ok
# [23:00] <smaug____> thanks
# [23:00] <smaug____> I don't find it insane
# [23:00] * Joins: psy_ (~psy@103.6.159.177)
# [23:00] <smaug____> it is just not what anyone is doing
# [23:00] <zcorpan> yeah. i'll file a bug on blink to investigate getting closer to the spec
# [23:02] <zcorpan> do you have a mozilla bug for your change?
# [23:02] * Joins: zenith_ (~zenith@142.150.23.90)
# [23:02] <smaug____> zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=1149555
# [23:03] <zcorpan> thx
# [23:04] * Joins: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64)
# [23:09] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 264 seconds)
# [23:17] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [23:18] * Quits: Maurice` (copyman@unaffiliated/maurice)
# [23:19] * Joins: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [23:19] <zcorpan> smaug____: https://code.google.com/p/chromium/issues/detail?id=472247
# [23:21] <caitp-> someone on blink-dev just noticed that idl attributes are found on prototypes now, rather than own properties of instances
# [23:22] <caitp-> is it here to stay this time? :O
# [23:22] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 264 seconds)
# [23:27] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [23:27] <smaug____> caitp-: blink is late getting idl attributes to behave per spec
# [23:28] <caitp-> yeah I know
# [23:29] <smaug____> and ++blink getting this stuff fixed finally :)
# [23:29] <caitp-> i think it's been attempted before
# [23:30] <Domenic> before it was reverted because perf
# [23:31] <Domenic> this time the only thing that can stop it is another MS Exchange/Array.prototype.contains-style debacle once it reaches stable channel
# [23:31] <Domenic> And even then they might just be able to turn it off for one or two properties...
# [23:31] <Domenic> Array.prototype.values, rather
# [23:32] <caitp-> well, won't have to worry about A.p.values until it's actually implemented in v8
# [23:32] <smaug____> Domenic: curious, which properties?
# [23:32] <Domenic> smaug____: I meant, hypothetical ones that cause compat problems. So far none have done so on a large scale...
# [23:33] <Domenic> caitp-: pretty sure it was implemented but had to be backed out because it broke MS Exchange Online? Was that something else?
# [23:33] <zcorpan> w00t! let's hope it sticks this time
# [23:33] <caitp-> Domenic I believe that's what it was
# [23:34] <caitp-> @@iterator is there, but the values alias isn't exposed
# [23:34] <Domenic> yeah
# [23:34] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 252 seconds)
# [23:34] <Domenic> wonder when we're going to feel brave enough to try that again
# [23:34] <smaug____> while fixing this all Gecko had some issues. onmouseenter/leave required special handling
# [23:34] <Domenic> spartan is shipping it i believe
# [23:34] <smaug____> but I guess that ended up to some spec
# [23:34] <smaug____> http://mxr.mozilla.org/mozilla-central/source/dom/webidl/EventHandler.webidl#65
# [23:36] <smaug____> (and of course all the issues related to global )
# [23:36] <zcorpan> https://html.spec.whatwg.org/multipage/webappapis.html#idl-definitions:handler-onmouseenter
# [23:37] <smaug____> good
# [23:37] * Quits: othermaciej (~mjs@17.244.163.90) (Ping timeout: 250 seconds)
# [23:37] * Joins: othermaciej_ (~mjs@17.202.48.222)
# [23:37] <zcorpan> idl attributes on globals is on the instance per spec
# [23:38] <smaug____> right, and it took quite some time to find something compatible-enough-with-the-web
# [23:40] * Joins: benwerd (~benwerd@199.87.84.238)
# [23:40] <caitp-> so how was the perf issue solved?
# [23:41] <caitp-> i don't remember seeing any bugmail about it, so I missed something :>
# [23:41] <smaug____> zcorpan: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/GlobalEventHandlers.idl&q=onmouseenter file:idl&sq=package:chromium&l=73
# [23:43] <zcorpan> smaug____: thx. will file
# [23:44] <caitp-> hmmm, fixme comment in that file does not have a name on it :>
# [23:47] * heycam|away is now known as heycam
# [23:51] * Joins: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d)
# [23:53] * Joins: bradleymeck (~bradleyme@70.114.246.88)
# [23:53] * Quits: dbaron (~dbaron@2620:101:80fb:232:bcf8:999c:2e9f:546c) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:53] * Joins: dbaron (~dbaron@2620:101:80fb:224:9439:c64b:d268:e5f1)
# [23:55] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Read error: Connection reset by peer)
# [23:55] <zcorpan> https://code.google.com/p/chromium/issues/detail?id=472260
# [23:55] <zcorpan> it's probably philipj
# [23:59] * Joins: bradleymeck (~bradleyme@70.114.246.88)
# [23:59] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [23:59] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [23:59] * Quits: bradleymeck (~bradleyme@70.114.246.88) (Client Quit)
# Session Close: Wed Apr 01 00:00:01 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn