/irc-logs / freenode / #whatwg / 2014-04-09 / end

Options:

# Session Start: Wed Apr 09 00:00:00 2014
# Session Ident: #whatwg
# [00:00] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [00:02] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:04] * Joins: nessy (~silviapf@101.164.214.231)
# [00:08] * Joins: ivan\ (~ivan@unaffiliated/ivan/x-000001)
# [00:09] * Joins: ehsan_ (~ehsan@66.207.208.102)
# [00:09] * Quits: ehsan (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
# [00:09] * Quits: plutoniix (~plutoniix@node-1a5x.pool-101-109.dynamic.totbb.net) (Quit: จรลี จรลา)
# [00:10] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Read error: Connection reset by peer)
# [00:11] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [00:12] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: brb)
# [00:13] <Domenic___> what's the context on http://w3cmemes.tumblr.com/image/82128157024 ?
# [00:13] <Hixie> heh
# [00:13] <Hixie> i can guess
# [00:14] <Hixie> the w3c won't agree to not copying the whatwg spec
# [00:14] <Hixie> so mike pointed out to them that they might get forced to consider it if i just relicensed the spec to just not allow it
# [00:15] <Domenic___> heh
# [00:15] <MikeSmith> I pointed out more than that
# [00:15] * Joins: Martijnc (~Martijn@is-aweso.me)
# [00:15] <Hixie> man, the latest memes are a depressing reflection of the w3c
# [00:15] <MikeSmith> but that's the only part what got minuted
# [00:17] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
# [00:20] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [00:20] * ojan_away is now known as ojan
# [00:23] * Joins: othermaciej (~mjs@216.113.168.135)
# [00:25] <Domenic___> s/depressing/fun
# [00:26] <Hixie> depressing, if what you care about is the web
# [00:31] * Quits: nessy (~silviapf@101.164.214.231) (Quit: Leaving.)
# [00:32] * Joins: KevinMarks_ (~KevinMark@199.47.77.72)
# [00:34] <annevk> Hixie: if you run a script, are microtasks run at the end?
# [00:35] <annevk> Hixie: e.g. I do new Worker() and in that worker I have a promise that immediately resolves itself, will that return its value before postMessag() stuff starts happening?
# [00:35] <Hixie> those two questions seem unrelated.
# [00:36] <annevk> Hixie: for service workers we want to do a deterministic "has listener" check at the end of initializing the script ideally before microtasks are run
# [00:36] <Hixie> "has listener" should always return true
# [00:36] <Hixie> that is, things should not depend on whether you have a listener or not
# [00:36] <annevk> Hixie: so yeah, that would change here
# [00:37] <Hixie> having a no-op listener and having no listener is the same thing.
# [00:38] <Hixie> (i'm not trying to avoid your questions, i'm not sure i understand precisely what you mean by the original two questions; they seem different and so if they're meant to be the same, i definitely don't understand them.)
# [00:38] <annevk> Hixie: the specification defines an algorithm for running a script given some fetched content
# [00:38] <Hixie> which spec?
# [00:38] <annevk> Hixie: the HTML spec
# [00:39] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Read error: Connection reset by peer)
# [00:40] <Hixie> you mean the <script> processing algorithm?
# [00:40] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block ?
# [00:40] <Hixie> or http://www.whatwg.org/specs/web-apps/current-work/#create-a-script ?
# [00:41] <Hixie> microtasks run at http://www.whatwg.org/specs/web-apps/current-work/#clean-up-after-running-a-callback if the stack of script settings objects is empty
# [00:41] <Hixie> which is called by http://www.whatwg.org/specs/web-apps/current-work/#jump-to-a-code-entry-point
# [00:41] <Hixie> which is called by http://www.whatwg.org/specs/web-apps/current-work/#create-a-script
# [00:42] <Hixie> which is called by http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block
# [00:42] <Hixie> as well as various other algorithms
# [00:42] <annevk> thanks
# [00:42] <Hixie> they also run after each task
# [00:42] <annevk> so yes
# [00:43] <Hixie> (which is often the same thing)
# [00:45] <Hixie> but seriously, don't do anything based on whether you have a listener ornot
# [00:45] <Hixie> that's a layering violation
# [00:46] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [00:47] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [00:51] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 240 seconds)
# [00:52] <TabAtkins> annevk: Why are you trying to do something different based on the presence of a listener?
# [00:53] <zewt> awooga awooga
# [00:55] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Read error: Connection reset by peer)
# [00:58] * Quits: foxtrotwhiskey (~foxtrotwh@c-98-225-154-188.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
# [00:59] * Joins: ap_ (~ap@17.114.216.196)
# [01:00] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [01:01] * Quits: ehsan_ (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
# [01:01] <TabAtkins> Ah, now I see the reasoning: https://github.com/slightlyoff/ServiceWorker/issues/225
# [01:01] * Joins: ehsan (~ehsan@66.207.208.102)
# [01:01] <TabAtkins> They want to skip the ServiceWorker entirely if there's no listener registered for a given event, since it's guaranteed to fall back to the network stack.
# [01:02] <Hixie> isn't that an implementation detail?
# [01:02] * Quits: ehsan (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
# [01:02] * Joins: ehsan (~ehsan@66.207.208.102)
# [01:02] <hober> it's not if they want to ignore subsequent listener additions
# [01:02] <TabAtkins> Technically, yes. The part that needs some spec language is defining *precisely* when a UA is allowed to assume there's no listener.
# [01:02] <TabAtkins> There's some timing issues.
# [01:03] * Quits: ap (~ap@2620:149:4:304:cc8d:3d6b:bdfe:702d) (Ping timeout: 240 seconds)
# [01:03] * ap_ is now known as ap
# [01:03] <Hixie> i would phrase it differently then
# [01:03] <Hixie> i would say that you fire the events at that time, or some such
# [01:04] <Hixie> not that you don't fire the event if it doesn't have a handler
# [01:04] * Joins: nessy (~silviapf@101.164.214.231)
# [01:04] <Hixie> but this all seems like an implementation detail
# [01:04] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [01:04] <hober> Hixie: look at the code example in https://github.com/slightlyoff/ServiceWorker/issues/225
# [01:04] <TabAtkins> And what hober said - they want to only allow functional listeners to be registered during install/update, not randomly, so that the fact of whether a SW is going to handle a request or not doesn't change in a way that would expose nondeterminism in request dispatch.
# [01:04] <Hixie> i did
# [01:05] <TabAtkins> In other words, they need to know about listener registration during some temporal periods and not others.
# [01:05] <Hixie> i don't really understand what that code snippet is suggesting
# [01:06] <TabAtkins> Imagine that, instead, SWs had to explicitly say "I'm going to handle fetches" (or other kinds of network activity).
# [01:06] <TabAtkins> The list of things to handle could only be updated during an install/update.
# [01:06] <Hixie> that seems like a reasonable api approach
# [01:06] <TabAtkins> And if you didn't explicitly say so, you dont' get sent anything.
# [01:06] <hober> even if you subsequently "change your mind" as in the self.onfetch in that example
# [01:06] <Hixie> better than doing anything based on what listeners are present, certainly
# [01:06] <TabAtkins> They're just trying to reduce boilerplate and reduce the chance of mistakes by making the registration mechanism "add a listener".
# [01:07] * Quits: weinig (~weinig@17.202.49.115) (Ping timeout: 250 seconds)
# [01:07] <TabAtkins> Becasue saying you're going to handle fetches, and then not defining a fetch listener, is stupid.
# [01:07] <Hixie> well then why not just have the logic be "when a listener is added, do X", like MessagePort does?
# [01:07] <TabAtkins> And so is defining a fetch handler, but not declaring that you'll handle fetches.
# [01:07] <TabAtkins> Yeah, I think that's all that needs to be done.
# [01:07] * Joins: weinig (~weinig@17.114.216.40)
# [01:07] <Hixie> that seems better than any weird timing things
# [01:08] * Joins: rniwa (~rniwa@17.202.43.222)
# [01:08] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
# [01:08] <Hixie> i mean, this is why message ports have start()
# [01:09] <Hixie> there's setting onmessage, which is "explained" as being the same as addEventListener() followed by start()
# [01:09] <Hixie> seems better than checking for listeners
# [01:10] <TabAtkins> Yeah, the deal is that there's a defined period where they want to listen for registrations, and no more after that.
# [01:10] <Hixie> sure
# [01:10] <TabAtkins> So you have to nail down the timing correctly, so that it can be documented exactly when listeners stop being paid attention to.
# [01:10] <Hixie> so long as they "explain" it properly with an api that doesn't actually rely on this, that's fine
# [01:11] <TabAtkins> ?
# [01:11] <Hixie> like the message port thing above
# [01:11] <zewt> most cases i've seen where people think they want to detect whether an event listener exists, what they should really be doing is basing it on whether preventDefault was called
# [01:11] <TabAtkins> zewt: Unrelated to this case.
# [01:12] <TabAtkins> You're talking about when people are trying to detect "was this event handled by the system, or did JS get a crack at it?".
# [01:13] <TabAtkins> They're talking about whether to even fire events at a SW, based on whether the SW is set up to listen to them.
# [01:14] <zewt> no, I'm in particular talking about the webglcontextlost WebGL event, where as I recall they wanted to say "if there are any listeners for webglcontextlost, then enable context loss. otherwise they don't support it, so do something different" (not precisely, been too long for the details)
# [01:14] <zewt> oh, for automatic context restoration
# [01:15] <zewt> "if there are any listeners for webglcontextlost, then the client knows about automatic context restoration and we'll do it. otherwise it's older code, so don't automatically restore the context"
# [01:15] <zewt> got changed to "if webglcontextlost is cancelled, enable context restoration"
# [01:16] <zewt> (i'm still getting it wrong, but the details aren't important here anyway)
# [01:17] * Quits: lmclister (~lmclister@192.150.10.210)
# [01:18] * Quits: smaug____ (~chatzilla@cs78246079.pp.htv.fi) (Ping timeout: 240 seconds)
# [01:21] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [01:25] <TabAtkins> Yeah, that makes more sense in that case.
# [01:25] * Quits: nessy (~silviapf@101.164.214.231) (Quit: Leaving.)
# [01:29] * Joins: Dashimon (Dashiva@178-82-40-88.dynamic.hispeed.ch)
# [01:29] * Quits: Dashimon (Dashiva@178-82-40-88.dynamic.hispeed.ch) (Changing host)
# [01:29] * Joins: Dashimon (Dashiva@wikia/Dashiva)
# [01:30] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 252 seconds)
# [01:30] * Dashimon is now known as Dashiva
# [01:47] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [01:50] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [01:52] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 246 seconds)
# [01:52] * Quits: annevk (~annevk@corp-nat.p2p.sfo1.mozilla.com) (Remote host closed the connection)
# [01:53] * Joins: hasather (~hasather@80.91.33.141)
# [01:56] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [01:57] * Quits: ap (~ap@17.114.216.196) (Quit: ap)
# [01:57] * Quits: jernoble_ (~jernoble@17.202.46.221) (Quit: Textual IRC Client: www.textualapp.com)
# [01:57] * Quits: jernoble (~jernoble@17.202.45.163) (Quit: Computer has gone to sleep.)
# [01:57] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [02:00] * Quits: othermaciej (~mjs@216.113.168.135) (Quit: othermaciej)
# [02:01] * Quits: darobin (~darobin@216.113.168.135) (Remote host closed the connection)
# [02:01] * Joins: othermaciej (~mjs@216.113.168.135)
# [02:01] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [02:01] * Joins: darobin (~darobin@216.113.168.135)
# [02:02] * Joins: mven_ (~mven@ip72-193-85-64.lv.lv.cox.net)
# [02:04] * Quits: jeffreyatw (~jeffreyat@173.247.197.10) (Quit: jeffreyatw)
# [02:04] * Quits: othermaciej (~mjs@216.113.168.135) (Client Quit)
# [02:05] * Joins: othermaciej (~mjs@216.113.168.135)
# [02:06] * Quits: darobin (~darobin@216.113.168.135) (Ping timeout: 246 seconds)
# [02:07] * Quits: tantek (~tantek@216.113.168.135) (Quit: tantek)
# [02:07] * Joins: ehsan (~ehsan@66.207.208.102)
# [02:07] * Quits: barnabywalters (~barnabywa@fire-out.ru.is) (Quit: barnabywalters)
# [02:07] * Quits: othermaciej (~mjs@216.113.168.135) (Client Quit)
# [02:13] * Quits: KevinMarks_ (~KevinMark@199.47.77.72) (Ping timeout: 240 seconds)
# [02:14] * Quits: mven_ (~mven@ip72-193-85-64.lv.lv.cox.net) (Remote host closed the connection)
# [02:18] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [02:22] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [02:23] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Remote host closed the connection)
# [02:24] * Joins: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com)
# [02:26] * Quits: weinig (~weinig@17.114.216.40) (Quit: weinig)
# [02:27] * Joins: weinig (~weinig@17.114.216.40)
# [02:27] * Joins: mven_ (~mven@ip72-193-85-64.lv.lv.cox.net)
# [02:34] * Joins: ehsan (~ehsan@66.207.208.102)
# [02:39] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
# [02:40] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [02:42] * Joins: benvie_ (~bbenvie@204.28.118.69)
# [02:44] * Quits: benvie (~bbenvie@204.28.118.69) (Ping timeout: 250 seconds)
# [02:44] * Joins: hasather (~hasather@80.91.33.141)
# [02:48] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [02:48] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
# [02:49] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
# [02:50] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [02:54] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 240 seconds)
# [02:58] * Joins: scor (~scor@drupal.org/user/52142/view)
# [02:59] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [02:59] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [03:03] * Quits: weinig (~weinig@17.114.216.40) (Quit: weinig)
# [03:04] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 240 seconds)
# [03:07] * Joins: SamB_ (~SamB@2001:470:1f07:57:70f4:ac97:7dca:a33a)
# [03:09] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
# [03:09] * Quits: SamB (~SamB@2001:470:1f07:57:64c4:e1e3:42c7:191) (Ping timeout: 246 seconds)
# [03:12] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
# [03:13] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [03:14] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Client Quit)
# [03:18] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:19] * Quits: numerical (~numerical@s-e-c-u-r-e-d.info) (Quit: changing servers)
# [03:23] * Joins: numerical (numerical@s-e-c-u-r-e-d.info)
# [03:25] * Krinkle is now known as Krinkle|detached
# [03:31] * SamB_ is now known as SamB
# [03:35] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [03:35] * Quits: SamB (~SamB@2001:470:1f07:57:70f4:ac97:7dca:a33a) (Read error: Connection reset by peer)
# [03:36] * Joins: bholley (~bholley@98.210.101.88)
# [03:36] * Joins: SamB (~SamB@2001:470:1f07:57:70f4:ac97:7dca:a33a)
# [03:36] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [03:44] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:50] * Joins: hasather (~hasather@80.91.33.141)
# [03:50] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [03:51] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [03:51] * Joins: bholley (~bholley@98.210.101.88)
# [03:53] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [03:54] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [03:55] * Joins: bholley (~bholley@98.210.101.88)
# [03:55] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 246 seconds)
# [03:56] * Quits: plutoniix (~plutoniix@210.213.57.70) (Ping timeout: 240 seconds)
# [03:57] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [03:58] <GPHemsley> Hixie: I'm just now going through the backlog of wiki admin stuff... the non-account request e-mails can be quite entertaining
# [03:59] <GPHemsley> (Subject: "I'm going to sue you") "I'm tired of you controlling everything I do. I'm going to sue you for all your open source, ifc, developer, xmtl bullshit. It is a total invasion of privacy."
# [03:59] <GPHemsley> Oh, wait, I left off the kicker
# [04:00] <GPHemsley> "Sent from my iPhone"
# [04:01] <GPHemsley> I also love the numerous spam product catalogs for traffic cones
# [04:02] <GPHemsley> oh, and apparently html5banners.com will soon be available for auction
# [04:03] * Quits: llkats (~llkats@h-64-236-138-3.aoltw.net) (Ping timeout: 250 seconds)
# [04:05] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [04:07] * Joins: bholley (~bholley@98.210.101.88)
# [04:07] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [04:08] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [04:08] * Joins: scor (~scor@drupal.org/user/52142/view)
# [04:10] * Joins: bholley_ (~bholley@98.210.101.88)
# [04:12] * Quits: bholley (~bholley@98.210.101.88) (Ping timeout: 240 seconds)
# [04:14] * Quits: scor (~scor@drupal.org/user/52142/view) (Ping timeout: 246 seconds)
# [04:18] * Joins: scor (~scor@drupal.org/user/52142/view)
# [04:18] * Quits: mven_ (~mven@ip72-193-85-64.lv.lv.cox.net) (Remote host closed the connection)
# [04:19] * Quits: bholley_ (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [04:21] * Joins: tantek (~tantek@mee0536d0.tmodns.net)
# [04:21] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [04:26] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 240 seconds)
# [04:27] * Quits: KevinMarks (~yaaic@2607:fb90:409:1973:852e:e59b:4c0c:978e) (Ping timeout: 240 seconds)
# [04:27] * Quits: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com) (Remote host closed the connection)
# [04:28] * Joins: seventh (seventh@207-207-24-132.fwd.datafoundry.com)
# [04:30] * Joins: KevinMarks (~yaaic@2607:fb90:409:1973:852e:e59b:4c0c:978e)
# [04:31] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [04:34] * Quits: seventh (seventh@207-207-24-132.fwd.datafoundry.com) (Ping timeout: 240 seconds)
# [04:39] * Joins: seventh (seventh@207-207-17-208.fwd.datafoundry.com)
# [04:43] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Quit: Leaving...)
# [04:47] * Quits: benv (~benv@38.104.194.126) (Quit: Computer has gone to sleep.)
# [04:49] <aretecode> What books do you recommend reading about specifications/standards/schemas?
# [04:51] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [04:55] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 246 seconds)
# [04:58] <Hixie> GPHemsley: sounds like i have better spam filtering than you, i hadn't seen any of those :-)
# [04:58] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 27.0/20140203120101])
# [04:58] <Hixie> aretecode: i haven't seen any especially brilliant ones, i'd mostly recommend reading the specs and joining the mailing lists
# [05:04] <aretecode> Hixie, thanks for your input. Can I buy the specs on paper?
# [05:05] <Hixie> you can buy paper and i think some companies still make printers :-)
# [05:05] <SamB> aretecode: most of them are living nowadays, it seems
# [05:06] <Hixie> yeah most of the good specs these days are maintained, meaning they get bug fixes regularly
# [05:06] <Hixie> like, daily or weekly
# [05:06] <SamB> it's not like buying a TeX manual that you could use for >1/4 century
# [05:06] * Quits: seventh (seventh@207-207-17-208.fwd.datafoundry.com) (Quit: ...)
# [05:07] <SamB> (depending on how interested you are in having all the errata fixed by other than literal copy&paste)
# [05:07] <aretecode> I understand, still, I find it easier to speed read on paper & printing them off is such a hassle.
# [05:08] <SamB> (Yes, Knuth makes patches that you can print out and paste into the manual!)
# [05:09] * Joins: bholley (~bholley@98.210.101.88)
# [05:10] <tantek> aretecode, for some of these specs, by the time you're done printing them, what you've printed out is already obsolete (changes have occured).
# [05:10] <tantek> even more likely for anything "preprinted"
# [05:10] <tantek> like "books"
# [05:12] <aretecode> True, I will just have to read these online - thank you :-)
# [05:13] * Quits: dfreedm (sid7859@gateway/web/irccloud.com/x-xmqxryntnsrwhxsg) (Read error: Connection reset by peer)
# [05:13] * Joins: dfreedm (sid7859@gateway/web/irccloud.com/x-hwisnuwgpyeigzwk)
# [05:14] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-hhvdqchoykhvklbx) (Read error: Connection reset by peer)
# [05:14] <GPHemsley> If you wait long enough, they'll probably stabilize eventually
# [05:14] <GPHemsley> And then you could print them
# [05:14] * Joins: JonathanNeal (sid5831@gateway/web/irccloud.com/x-itlbaipfabgprsmz)
# [05:18] <Hixie> HTML is pretty stable, but i doubt it'll be unchanging before it's obsolete
# [05:18] <Hixie> and it'll probably have a wave of desperate changes just after being obsolete :-)
# [05:19] * Quits: tantek (~tantek@mee0536d0.tmodns.net) (Quit: tantek)
# [05:20] <zewt> if you want stuff on paper, buy a kindle
# [05:20] * Quits: KevinMarks (~yaaic@2607:fb90:409:1973:852e:e59b:4c0c:978e) (Ping timeout: 240 seconds)
# [05:21] * Joins: KevinMarks (~yaaic@2607:fb90:114:3af5:9c8f:9e70:8f4e:8104)
# [05:24] * Joins: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com)
# [05:31] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [05:32] * Quits: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com) (Ping timeout: 240 seconds)
# [05:33] * Quits: KevinMarks (~yaaic@2607:fb90:114:3af5:9c8f:9e70:8f4e:8104) (Ping timeout: 240 seconds)
# [05:52] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [05:54] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
# [05:56] * Quits: bholley (~bholley@98.210.101.88) (Read error: Connection reset by peer)
# [05:56] * Joins: bholley_ (~bholley@98.210.101.88)
# [05:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
# [06:02] * Joins: hasather (~hasather@80.91.33.141)
# [06:02] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [06:05] * Quits: bholley_ (~bholley@98.210.101.88) (Read error: Connection reset by peer)
# [06:05] * Joins: bholley (~bholley@98.210.101.88)
# [06:06] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [06:23] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [06:27] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 240 seconds)
# [06:28] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [06:29] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [06:31] * Joins: ambv (~ambv@64.254.253.205)
# [06:32] * Quits: ambv (~ambv@64.254.253.205) (Read error: Connection reset by peer)
# [06:33] * Joins: ambv (~ambv@69.63.185.56)
# [06:34] * Quits: ambv (~ambv@69.63.185.56) (Client Quit)
# [06:40] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [06:50] * Joins: bholley (~bholley@98.210.101.88)
# [06:51] * Quits: bholley (~bholley@98.210.101.88) (Read error: Connection reset by peer)
# [06:51] * Joins: bholley_ (~bholley@98.210.101.88)
# [06:55] * Joins: sicking (~sicking@c-98-210-154-157.hsd1.ca.comcast.net)
# [06:58] * Quits: bholley_ (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [07:01] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [07:01] * Joins: jeffreyatw (~jeffreyat@199-188-192-206.PUBLIC.monkeybrains.net)
# [07:13] * Joins: zdobersek (~zan@tsn85-159-237-3.dyn.nltelcom.net)
# [07:20] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [07:31] * Krinkle|detached is now known as Krinkle
# [07:32] * Krinkle is now known as Krinkle|detached
# [07:32] * Joins: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [07:33] * Quits: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Read error: Connection reset by peer)
# [07:38] * Joins: niloy (~niloy@110.224.128.50)
# [07:41] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [07:56] * Quits: jeffreyatw (~jeffreyat@199-188-192-206.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [08:00] * Joins: darobin (~darobin@66.201.52.99)
# [08:06] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-vkmcpfeiwmlyhadg)
# [08:12] * Joins: Ducki (~Ducki@137.116.197.171)
# [08:14] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:14] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [08:23] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [08:25] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [08:27] * Quits: sicking (~sicking@c-98-210-154-157.hsd1.ca.comcast.net) (Quit: sicking)
# [08:28] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 240 seconds)
# [08:28] * Joins: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com)
# [08:33] * Quits: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com) (Ping timeout: 240 seconds)
# [08:33] * Joins: Smylers (~smylers@host86-147-24-198.range86-147.btcentralplus.com)
# [08:34] * Quits: Smylers (~smylers@host86-147-24-198.range86-147.btcentralplus.com) (Client Quit)
# [08:35] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [08:38] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Read error: Operation timed out)
# [08:43] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [08:45] * Quits: niloy (~niloy@110.224.128.50) (Ping timeout: 250 seconds)
# [08:49] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
# [08:49] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [08:51] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
# [08:53] * Joins: kochi2 (~kochi@2401:fa00:4:1000:26be:5ff:fe03:db82)
# [08:53] * Quits: kochi2 (~kochi@2401:fa00:4:1000:26be:5ff:fe03:db82) (Client Quit)
# [08:53] * heycam|away|away is now known as heycam|away
# [08:54] * Joins: kochi2 (~kochi@2401:fa00:4:1000:26be:5ff:fe03:db82)
# [08:54] * Quits: kochi2 (~kochi@2401:fa00:4:1000:26be:5ff:fe03:db82) (Remote host closed the connection)
# [08:59] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [08:59] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [09:04] * Joins: hasather (~hasather@80.91.33.141)
# [09:05] * Quits: Guest88419 (~Areks@rs.gridnine.com) (Read error: Connection reset by peer)
# [09:06] * Joins: Guest88419 (~Areks@rs.gridnine.com)
# [09:08] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
# [09:12] * Joins: niloy (~niloy@110.224.128.93)
# [09:28] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [09:44] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
# [09:50] * Joins: hasather (~hasather@80.91.33.141)
# [10:02] * Joins: Smylers (~smylers@94.116.146.144)
# [10:06] * Quits: Smylers (~smylers@94.116.146.144) (Ping timeout: 240 seconds)
# [10:11] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [10:12] * Joins: sankha93 (~sankha93@fsf/emeritus/sankha93)
# [10:14] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 240 seconds)
# [10:15] * Joins: Smylers (~smylers@81.143.60.194)
# [10:27] * Joins: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com)
# [10:31] * Quits: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com) (Ping timeout: 240 seconds)
# [10:33] * Guest88419 is now known as Areks
# [10:33] * Areks is now known as lAreksl
# [10:33] * lAreksl is now known as Areks
# [10:48] * Joins: toyoshiAw (~toyoshim@yuri.twintail.org)
# [10:49] * toyoshiAw is now known as toyoshim
# [10:58] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
# [11:00] * Joins: plutoniix (~plutoniix@210.213.57.70)
# [11:12] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
# [11:36] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [11:47] * Joins: mrwick (~mrwick@94.107.244.58)
# [11:50] * toyoshim is now known as toyoshiAw
# [11:55] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [12:14] * Joins: adactio (~adactio@212.42.170.181)
# [12:23] * Joins: smaug____ (~chatzilla@cs78246079.pp.htv.fi)
# [12:51] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
# [12:53] <jgraham> gsnedders: r+
# [12:57] * Quits: SimonSapin (~simon@hako.exyr.org) (Quit: WeeChat 0.3.8)
# [13:00] * Joins: SimonSapin (~simon@hako.exyr.org)
# [13:03] * Joins: a-ja (~Instantbi@70.230.146.231)
# [13:09] * Quits: smaug____ (~chatzilla@cs78246079.pp.htv.fi) (Ping timeout: 240 seconds)
# [13:11] * Joins: espadrine` (~ttyl@AMontsouris-158-1-18-194.w92-128.abo.wanadoo.fr)
# [13:15] * Quits: espadrine (~ttyl@AMontsouris-158-1-94-132.w90-2.abo.wanadoo.fr) (Ping timeout: 264 seconds)
# [13:21] * Quits: scrollback1 (scrollback@conference/jsconf/x-aitbolfimyscgkzo) (Remote host closed the connection)
# [13:22] * Joins: 16WAAA99V (scrollback@conference/jsconf/x-cpsvtbayypemmxqw)
# [13:25] * Joins: espadrine_ (~ttyl@AMontsouris-158-1-16-93.w92-128.abo.wanadoo.fr)
# [13:28] * Quits: espadrine` (~ttyl@AMontsouris-158-1-18-194.w92-128.abo.wanadoo.fr) (Ping timeout: 240 seconds)
# [13:29] * Quits: 16WAAA99V (scrollback@conference/jsconf/x-cpsvtbayypemmxqw) (Remote host closed the connection)
# [13:31] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [13:32] * Joins: hasather (~hasather@80.91.33.141)
# [13:35] * Joins: Lachy (~Lachy@213.166.174.2)
# [13:36] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [13:37] * Joins: 17SAABL6J (scrollback@conference/jsconf/x-dvdqpwwnjsqglkyb)
# [13:41] * Joins: hasather (~hasather@80.91.33.141)
# [13:44] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
# [13:51] * Joins: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net)
# [13:56] * Parts: a-ja (~Instantbi@70.230.146.231)
# [14:00] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: Textual IRC Client: www.textualapp.com)
# [14:02] * Quits: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net) (Remote host closed the connection)
# [14:02] * Joins: shannonmoeller (~shannonmo@nat.sierrabravo.net)
# [14:09] * Joins: nessy (~silviapf@101.164.214.231)
# [14:14] * Joins: newbie (~Areks@rs.gridnine.com)
# [14:14] * newbie is now known as Guest25890
# [14:14] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:20] * Joins: Areks (~Areks@rs.gridnine.com)
# [14:20] * Joins: foxtrotwhiskey (~foxtrotwh@192-63-2457.unisys.com)
# [14:23] * Quits: Guest25890 (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:24] * Joins: richt (~richt@83.218.67.123)
# [14:26] * Joins: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com)
# [14:27] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [14:29] * Joins: newbie53 (~Areks@rs.gridnine.com)
# [14:29] * Quits: adactio (~adactio@212.42.170.181) (Ping timeout: 246 seconds)
# [14:31] * Quits: enryptd_fractal (~enryptd_f@24-177-124-44.dhcp.mdsn.wi.charter.com) (Ping timeout: 246 seconds)
# [14:32] * Joins: scor (scor@nat/acquia/x-xggltddwbsurrrle)
# [14:32] * Quits: scor (scor@nat/acquia/x-xggltddwbsurrrle) (Changing host)
# [14:32] * Joins: scor (scor@drupal.org/user/52142/view)
# [14:32] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:37] * Joins: Areks (~Areks@rs.gridnine.com)
# [14:40] * Quits: newbie53 (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:45] * Joins: newbie13 (~Areks@rs.gridnine.com)
# [14:48] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:48] * Joins: tj_vantoll (~Adium@2601:4:1400:5f5:4c0f:738d:a4b5:4f07)
# [14:50] * Quits: nessy (~silviapf@101.164.214.231) (Quit: Leaving.)
# [14:52] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [14:53] * Joins: Areks (~Areks@rs.gridnine.com)
# [14:55] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [14:56] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
# [14:56] * Quits: newbie13 (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [14:57] * Quits: shannonmoeller (~shannonmo@nat.sierrabravo.net) (Remote host closed the connection)
# [14:57] * Joins: shannonmoeller (~shannonmo@nat.sierrabravo.net)
# [14:59] * Quits: ahf (ahf@irssi/staff/ahf) (Remote host closed the connection)
# [15:01] * Joins: ahf (ahf@irssi/staff/ahf)
# [15:01] * Joins: newbie57 (~Areks@rs.gridnine.com)
# [15:03] * Joins: prosana (~julian@xdsl-85-197-29-155.netcologne.de)
# [15:04] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [15:05] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [15:05] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Client Quit)
# [15:09] * Joins: Areks (~Areks@rs.gridnine.com)
# [15:12] * Quits: newbie57 (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [15:17] * Joins: TallTed (~Thud@63.119.36.36)
# [15:18] * Joins: bholley (~bholley@98.210.101.88)
# [15:18] * Joins: newbie (~Areks@rs.gridnine.com)
# [15:19] * newbie is now known as Guest85241
# [15:20] * Joins: Ms2ger (~Ms2ger@211.199-242-81.adsl-dyn.isp.belgacom.be)
# [15:21] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [15:22] * Joins: newtron (~newtron@199.71.174.203)
# [15:26] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [15:26] * Joins: Areks (~Areks@rs.gridnine.com)
# [15:29] * Quits: Guest85241 (~Areks@rs.gridnine.com) (Ping timeout: 260 seconds)
# [15:31] * Joins: rafaelrinaldi (~textual@B12E84DD.dynamic.spo.dsl.tesa.net.br)
# [15:35] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [15:36] * Quits: niloy (~niloy@110.224.128.93) (Ping timeout: 246 seconds)
# [15:45] <Ms2ger> "The problem is that the CSS Working Group doesn't follow the W3C Process for maintaining specifications."
# [15:45] * Ms2ger giggles
# [15:46] <jgraham> :-o
# [15:47] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-wrneksjqnefmnuwp)
# [15:49] * heycam|away is now known as heycam|away|away
# [15:50] * Quits: eric_carlson (~eric@17.202.43.125) (Read error: Connection reset by peer)
# [15:50] * Joins: eric_carlson (~eric@17.202.43.125)
# [15:50] * heycam|away|away is now known as heycam|away
# [15:52] * Joins: hober2 (~ted@unaffiliated/hober)
# [15:52] * Quits: lerc (~quassel@121-74-228-250.telstraclear.net) (Quit: No Ping reply in 180 seconds.)
# [15:52] * Joins: lerc (~quassel@121-74-228-250.telstraclear.net)
# [15:54] * Quits: hober (~ted@unaffiliated/hober) (Remote host closed the connection)
# [15:57] * Quits: rego (~rego@192.193.27.77.dynamic.mundo-r.com) (Remote host closed the connection)
# [15:57] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
# [15:59] * Joins: bholley (~bholley@98.210.101.88)
# [15:59] * Joins: rego (~rego@192.193.27.77.dynamic.mundo-r.com)
# [15:59] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [16:00] * Joins: hasather (~hasather@80.91.33.141)
# [16:04] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
# [16:04] * Joins: manus (500e4f9b@gateway/web/freenode/ip.80.14.79.155)
# [16:05] * heycam|away is now known as heycam|away|away
# [16:06] * Joins: hasather (~hasather@80.91.33.141)
# [16:06] * heycam|away|away is now known as heycam|away
# [16:08] * Joins: enryptd_fractal (~enryptd_f@66-188-99-174.static.ftbg.wi.charter.com)
# [16:10] * Quits: zdobersek (~zan@tsn85-159-237-3.dyn.nltelcom.net) (Quit: Leaving.)
# [16:19] * Joins: plutoniix (~plutoniix@node-olg.pool-101-108.dynamic.totbb.net)
# [16:24] * beowulf_ is now known as beowulf
# [16:27] * Joins: smaug____ (~chatzilla@cs78246079.pp.htv.fi)
# [16:44] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [16:45] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [16:48] * Quits: ryuone (~ryuone@133.242.55.223) (Quit: Tiarra 0.1: SIGTERM received; exit)
# [16:53] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [16:53] * espadrine_ is now known as espadrine
# [16:55] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
# [16:57] * Joins: Lachy (~Lachy@213.166.174.2)
# [17:00] * Quits: foxtrotwhiskey (~foxtrotwh@192-63-2457.unisys.com) (Ping timeout: 246 seconds)
# [17:01] * Joins: foxtrotwhiskey (~foxtrotwh@192-63-201129.unisys.com)
# [17:02] * Joins: ryuone (~ryuone@133.242.55.223)
# [17:10] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Read error: Connection reset by peer)
# [17:10] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [17:14] * Quits: richt (~richt@83.218.67.123) (Remote host closed the connection)
# [17:19] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
# [17:20] * Joins: zdobersek (~zan@109.201.154.201)
# [17:21] * Domenic___ is now known as Domenic_
# [17:22] * Quits: shannonmoeller (~shannonmo@nat.sierrabravo.net) (Quit: Leaving...)
# [17:22] <galineau> 'Not following the W3C process' kind of sounds like a feature to me.
# [17:22] <dglazkov> good morning, Whatwg!
# [17:23] * Quits: darobin (~darobin@66.201.52.99) (Remote host closed the connection)
# [17:23] <galineau> good morning to you too, Monsieur Glazkov
# [17:25] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [17:25] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 240 seconds)
# [17:32] <Ms2ger> galineau, well, you know there's one person who'd disagree :)
# [17:33] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [17:33] <dglazkov> good morning, galineau and Ms2ger!
# [17:33] <galineau> Ms2ger: only one? OMG I've never been this close to consensus before
# [17:33] <Ms2ger> Ha
# [17:34] <Ms2ger> One person in particular
# [17:35] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [17:35] * Joins: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net)
# [17:40] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [17:40] * Joins: hasather (~hasather@80.91.33.141)
# [17:43] * Joins: darobin (~darobin@216.113.168.135)
# [17:43] * Quits: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net) (Quit: Computer has gone to sleep.)
# [17:44] * Quits: mrwick (~mrwick@94.107.244.58) (Quit: leaving)
# [17:44] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [17:45] * Joins: lmclister (~lmclister@192.150.10.210)
# [17:48] * heycam|away is now known as heycam|away|away
# [17:49] * Joins: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net)
# [17:49] * Quits: rafaelrinaldi (~textual@B12E84DD.dynamic.spo.dsl.tesa.net.br) (Quit: My Mac Mini has gone to sleep. ZZZzzz…)
# [17:51] * Joins: tantek (~tantek@172.56.39.125)
# [17:54] * Joins: jsbell (jsbell@nat/google/x-kuthljtjpfmreqpd)
# [17:54] * Joins: mpt (~mpt@canonical/mpt)
# [17:55] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
# [18:09] * Joins: Maurice` (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [18:12] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:14] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
# [18:15] * Quits: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net) (Quit: Computer has gone to sleep.)
# [18:18] * Quits: SimonSapin (~simon@hako.exyr.org) (Quit: WeeChat 0.3.8)
# [18:18] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
# [18:19] * Joins: llkats (~llkats@206.169.83.230)
# [18:19] * Quits: llkats (~llkats@206.169.83.230) (Client Quit)
# [18:20] * Joins: tantek-ipod (~tantek@172.56.39.125)
# [18:21] * Quits: tantek (~tantek@172.56.39.125) (Ping timeout: 240 seconds)
# [18:21] * tantek-ipod is now known as tantek
# [18:21] <MikeSmith> who says "The problem is that the CSS Working Group doesn't follow the W3C Process for maintaining specifications"
# [18:21] <MikeSmith> don't make me have to go and read www-style
# [18:23] <MikeSmith> nm
# [18:23] <MikeSmith> I should have guessed
# [18:23] * abinader is now known as abinader|afk
# [18:25] * Quits: tantek (~tantek@172.56.39.125) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [18:25] * Joins: SimonSapin (~simon@shinhako.exyr.org)
# [18:27] * Quits: tj_vantoll (~Adium@2601:4:1400:5f5:4c0f:738d:a4b5:4f07) (Quit: Leaving.)
# [18:28] * hober2 is now known as hober
# [18:28] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 250 seconds)
# [18:29] * Joins: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso)
# [18:31] * Joins: jeffreyatw (~jeffreyat@199-188-192-206.PUBLIC.monkeybrains.net)
# [18:31] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 250 seconds)
# [18:32] * Quits: foxtrotwhiskey (~foxtrotwh@192-63-201129.unisys.com) (Ping timeout: 246 seconds)
# [18:33] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
# [18:38] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
# [18:39] * Joins: rafaelrinaldi (~textual@B12E84DD.dynamic.spo.dsl.tesa.net.br)
# [18:39] * Joins: tantek (~tantek@172.56.39.125)
# [18:40] * Joins: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net)
# [18:41] * Joins: hasather (~hasather@80.91.33.141)
# [18:44] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
# [18:45] * Quits: jernoble (~jernoble@mobile-166-137-185-198.mycingular.net) (Ping timeout: 246 seconds)
# [18:45] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 240 seconds)
# [18:47] * Joins: ap (~ap@2620:149:4:304:4095:d17e:3bfc:ffb1)
# [18:48] * Joins: jernoble (~jernoble@216.113.168.135)
# [18:50] * Quits: benvie_ (~bbenvie@204.28.118.69) (Ping timeout: 240 seconds)
# [18:52] <TabAtkins> Yeah, that argument from Björn is totally valid.
# [18:52] <TabAtkins> The errata for CSS2 is a disgrace. :/
# [18:53] <TabAtkins> galineau: Urg, you're gonna break my name-autocompletion memory with a nick like that.
# [18:53] <TabAtkins> Hixie: I remembered that I was supposed to ping you when I'd written this spec: http://dev.w3.org/csswg/css-scoping/#scoping-mechanisms
# [18:53] <TabAtkins> So you can point <style scoped> to it.
# [18:53] * Joins: benvie (~bbenvie@204.28.118.69)
# [18:55] * Quits: zdobersek (~zan@109.201.154.201) (Quit: Leaving.)
# [18:57] <tantek> isn't the errata for CSS2 called "CSS2.1" ?
# [18:57] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [18:58] <SimonSapin> fwiw, I call "CSS2" all of 2.0, 2.1, and any future 2.x
# [19:02] * Joins: shannonmoeller (~shannonmo@nat.sierrabravo.net)
# [19:02] * Quits: shannonmoeller (~shannonmo@nat.sierrabravo.net) (Client Quit)
# [19:03] <tantek> SimonSapin - if you'd worked on CSS2 (or tried to implement it), you would have no desire to refer to anything as CSS2 except in a legacy / dismissive manner
# [19:06] * Joins: IZh (~IZh@83.220.236.97)
# [19:06] <SimonSapin> tantek: that’s not incompatible with what I just said
# [19:06] <Ms2ger> Ha
# [19:09] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [19:11] <tantek> SimonSapin, Y U NO LIKE CSS2.1?
# [19:12] * Quits: bholley (~bholley@98.210.101.88) (Quit: Textual IRC Client: www.textualapp.com)
# [19:13] * Quits: manus (500e4f9b@gateway/web/freenode/ip.80.14.79.155) (Quit: Page closed)
# [19:14] * Quits: IZh (~IZh@83.220.236.97) (Ping timeout: 240 seconds)
# [19:15] * Joins: annevk (~annevk@84-72-161-84.dclient.hispeed.ch)
# [19:16] <TabAtkins> tantek: Because it's full of wrong things that are only corrected in the errata that nobody ever reads.
# [19:16] <tantek> so the 2.1 errata is in a sad state, is that what's being asserted?
# [19:16] <Ms2ger> s/2.1//
# [19:17] <tantek> heh
# [19:17] <Ms2ger> Nobody ever bothers with errata in the csswg
# [19:17] <annevk> What was the thing you said about mailing lists again tantek?
# [19:18] * Joins: bholley (~bholley@98.210.101.88)
# [19:18] <tantek> on a long enough timeline, open mailing lists turn into support forums
# [19:18] <hober> annevk: http://w3cmemes.tumblr.com/post/27939749113/the-conversation-in-whatwg-whenever-tanteks
# [19:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [19:19] <annevk> Ah too bad, does not entirely feel how I think about errata
# [19:19] <annevk> s/feel/match/
# [19:19] <tantek> I'm not much of a fan of errata either - the "nobody checks errata" problem makes errata not every useful in practice even if they do exist and are updated.
# [19:20] <tantek> I'm much more in favor of the "luke-warm spec" model - "finished" specs continue being updated inline with any errata to their feature set
# [19:22] <Domenic_> sounds like a living standard
# [19:23] <jgraham> Lukewarm makes it sound like a zombie standard
# [19:23] * Joins: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net)
# [19:23] * Quits: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net) (Client Quit)
# [19:23] * Joins: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net)
# [19:24] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
# [19:25] <Domenic_> i guess the distinction tantek is making is "no new features"?
# [19:26] <tantek> jgraham, are zombies warm?
# [19:26] * Joins: rniwa (~rniwa@67.164.23.121)
# [19:26] <rniwa> annevk: yt?
# [19:26] <annevk> rniwa: yeah
# [19:26] * Joins: Smylers (~smylers@host86-147-24-198.range86-147.btcentralplus.com)
# [19:26] <rniwa> annevk: do you remember why we couldn't make querySelectorAll return Elements?
# [19:26] <tantek> Domenic, yes, specific (frozen) feature sets are useful to various folks.
# [19:27] <hober> rniwa: Elements didn't exist yet
# [19:27] <rniwa> annevk: I know we could replace all static NodeList with Array or make it inherit from Array
# [19:27] <annevk> rniwa: we might be able to, it didn't seem worth the hassle of finding out
# [19:27] <rniwa> hober: I know.
# [19:27] <annevk> rniwa: interesting
# [19:27] <Ms2ger> tantek, I'm unconvinced
# [19:27] <rniwa> annevk, hober: It seems like querySelectorAll should simply return a JS Array (or Elements when it's introduced)
# [19:27] <annevk> rniwa: given .queryAll() I didn't really see the need to find out
# [19:28] <Hixie> TabAtkins: sweet, thanks
# [19:28] <rniwa> annevk: well, it kind of sucks to force authors to use new function just because of that.
# [19:28] <annevk> rniwa: I'd be okay with supporting that in the specification if you implement it
# [19:28] <annevk> rniwa: yeah I guess, the new functions also do other things authors asked for
# [19:28] <annevk> rniwa: e.g. jQuery selector parsing compat
# [19:29] <rniwa> annevk: you mean queryAll?
# [19:29] <rniwa> annevk: right, because it supports relative selector.
# [19:29] <annevk> rniwa: yes and yes
# [19:29] <rniwa> annevk: but it kind of sucks that we have to block the work to make querySelectorAll's results usable until we can implement the relative selector
# [19:29] <rniwa> annevk: because the latter requires a substantial amount of work
# [19:30] <tantek> Ms2ger, clearly you're not various folks ;)
# [19:30] <annevk> rniwa: as I said, I'd be happy to back a WebKit change with a spec change
# [19:30] <annevk> rniwa: you might want to ping the list and copy bz and arv_
# [19:30] <jgraham> tantek: I imagine zombies follow Newton's law of cooling
# [19:30] <rniwa> annevk: I guess the only risk is that someone might calling item() on the result :/
# [19:30] <rniwa> arv_: ^
# [19:30] <annevk> rniwa: yeah
# [19:30] <rniwa> bzed: are you bz?
# [19:30] * Domenic_ shakes fist at item()
# [19:30] <annevk> bzed != bz
# [19:31] <rniwa> annevk: thanks.
# [19:31] <tantek> jgraham maybe warm blooded vs. cold blooded (mammals vs reptiles) could be another analogy
# [19:31] <TabAtkins> rniwa: What's so hard about relative selectors? Absolutizing them is a simple algo.
# [19:31] * Joins: ehsan (~ehsan@66.207.208.102)
# [19:31] <rniwa> annevk: another risk is that WebKit has historically supported stupid namedItem :(
# [19:31] <annevk> Domenic_: item() laughs at you
# [19:31] <rniwa> TabAtkins: I'm not saying it's hard. It requires a lot of work.
# [19:31] <annevk> rniwa: that hasn't been refactored?
# [19:32] <tantek> then again, even mammals don't typically spontaneously grow never-before-seen limbs (features)
# [19:32] <rniwa> annevk: you mean namedItem?
# [19:32] <rniwa> annevk: not in WebKit
# [19:32] <rniwa> annevk: it has been in Blink.
# [19:32] <annevk> TabAtkins: proper Elements support also requires a lot of work
# [19:32] <rniwa> annevk: (I think)
# [19:32] <annevk> rniwa: ait
# [19:32] <rniwa> annevk: yeah...
# [19:32] <annevk> But going with Array for now seems safe
# [19:32] <rniwa> annevk: we might just do Array first and then add Elements later.
# [19:32] <TabAtkins> All right. Not really sure how (you just do a quick check on the selector, then maybe prepend :scope), but whatever.
# [19:32] <TabAtkins> annevk: Yeah, I'd believe that.
# [19:33] <tantek> living things typically have a static total feature set (gene sequence)
# [19:33] <Domenic_> that's interesting. having queryAll return an Array and then upgrading it to Elements later might be a backward-compat change
# [19:33] <tantek> living things that grow new things here and there that were outside that feature set are typically the result of cancers
# [19:33] <TabAtkins> It's actually correct to just do a string search on the selector (assuming we never define a ::scope pseudo-element).
# [19:34] <tantek> so perhaps "living spec" would make more sense to apply to static feature set but inline updated errata specs
# [19:34] <Domenic_> this is actually really good. it means queryAll could get implemented much faster.
# [19:35] <rniwa> tantek: it would be nice to have snapshots of living standards with errata.
# [19:35] <TabAtkins> tantek: And "cancerous spec" to ones like HTML?
# [19:35] <TabAtkins> "mutagenic"
# [19:35] <rniwa> tantek: i always get surprised by how much things have changed whenever i look at living standards :(
# [19:35] <tantek> and a spec that grows new features beyond its base feature set would make more sense labled a "cancerous spec"
# [19:36] <rniwa> Domenic_: not so fast in WebKit but yeah... at least we can unblock it from having implemented Elements.
# [19:36] <tantek> rniwa - ah yes, you're one of the "various folks" I mentioned then
# [19:37] <Domenic_> rniwa: is implementing relativize absolute selector that much work? feels like pull-request material...
# [19:37] * Quits: decotii (~decotii@hq.croscon.com) (Quit: Leaving)
# [19:38] <annevk> Domenic_: note that rniwa and I were discussing returning an Array from querySelectorAll, not queryAll, though the latter seems ok too
# [19:39] <tantek> rniwa - that sort of "living spec" model is what I'm seeing if I can push W3C to do.
# [19:39] <tantek> since errata are pretty broken (in many ways)
# [19:39] <rniwa> tantek: yeah, that'll be nice.
# [19:39] <rniwa> tantek: in fact, that's how we release software products, right?
# [19:39] <tantek> right
# [19:39] <rniwa> tantek: we have trunk and then we branch for each release
# [19:39] <tantek> lots of lessons to be reapplied
# [19:39] <rniwa> tantek: "errata's" being merged into each branch
# [19:39] <annevk> tantek: as humans grow, they're able to do more things, until they die, not sure the feature set is necessarily static
# [19:40] <tantek> precisely rniwa
# [19:40] <annevk> However, I don't object to branching, if we can find more people working in this space first...
# [19:40] <rniwa> annevk: if you consider the feature set as the physical characteristics of a person, then it doesn't change much over the course of a human life
# [19:40] <rniwa> tantek: if you do consider it as his/her knowledge, then it does.
# [19:40] <annevk> It's not like we have many editors to go around fixing the platform bugs
# [19:40] <tantek> annevk - they're able to do more things (applications) with the same genetics/physical expression (features)
# [19:40] <rniwa> annevk: THAT (scarcity of good editors) is the biggest problem we have :(
# [19:41] <rniwa> annevk: I'd rather have you and other good spec. editors writing actual specs and participating in discussions
# [19:41] <rniwa> annevk: than doing branches and merging fixes :(
# [19:41] <rniwa> annevk: because the latter is more of a tedious work...
# [19:41] <Ms2ger> rniwa, tell webapps
# [19:41] <tantek> so all you "master editors" have taken an apprentice right? ;)
# [19:41] <rniwa> Ms2ger: tomorrow!
# [19:42] <Domenic_> for smaller specs branching/tagging meaningful versions is pretty easy i think
# [19:42] <Domenic_> for html it seems infeasible
# [19:42] <Domenic_> but for e.g. fullscreen probably fine
# [19:42] <tantek> rniwa are you coming to the webapps f2f tomorrow?
# [19:42] <tantek> (cue Annie soundtrack)
# [19:42] <tantek> annevk: http://en.wikipedia.org/wiki/List_of_human_anatomical_features ;)
# [19:43] <annevk> Domenic_: seems like a chore, maintaining Fullscreen currently takes a couple hours every other week, that would make it worse
# [19:43] <annevk> tantek: ok ok, maybe my argument is that I don't really buy the analogy :p
# [19:43] <annevk> tantek: mostly, if someone could solve the resources problem, we can look at it again
# [19:43] <tantek> annevk ok that's fair ;)
# [19:44] <tantek> annevk, the resources to do spec branching/tagging don't have to be as capable as those editing trunk.
# [19:44] <tantek> I'll let you draw your own conclusions where there are such resources ;)
# [19:45] * Quits: aklein_ (sid4454@gateway/web/irccloud.com/x-aotuekccpcwxzucf)
# [19:45] * Joins: aklein (sid4454@gateway/web/irccloud.com/x-qdqdlpfpstgicqdl)
# [19:47] * Quits: jernoble (~jernoble@216.113.168.135) (Quit: Computer has gone to sleep.)
# [19:48] * Joins: Areks_home (~Areks@128-72-103-77.broadband.corbina.ru)
# [19:48] <aklein> Hixie: I'm curious about the script "entry settings object" (http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#entry-settings-object); in particular I'm interested under what circumstances you'd expect there to be no entry settings object
# [19:49] * Quits: benvie (~bbenvie@204.28.118.69) (Ping timeout: 240 seconds)
# [19:49] <aklein> also, from a higher level, I'm wondering if the new ES6 tasks stuff breaks some expectation of HTML that the latter (HTML, that is) is always the actor calling into script
# [19:50] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
# [19:50] <aklein> Domenic_: you might also be interested in my higher level concern, above
# [19:51] * Domenic_ starts listening
# [19:51] <arv_> rniwa, annevk: Having querySelectorAll return an Array sounds good to me. We'll be happy to follow if you make this change in WebKit.
# [19:51] <Domenic_> O_O
# [19:51] <aklein> Domenic_: in trying to make V8 run Promise callbacks itself, we ended up in a position where Blink didn't have enough information about the page context
# [19:52] <aklein> Domenic_: https://code.google.com/p/chromium/issues/detail?id=360891 is the bug, if you're interested; the use of Object.observe could be replaced with a Promises example
# [19:53] <annevk> aklein: you want to talk to bz probably
# [19:53] <aklein> annevk: I definitely want someone from Mozilla, yeah, as I suspect the entry settings object goes back a long way
# [19:53] <aklein> its behavior is pretty surprising
# [19:53] <Domenic_> yeah these sound like similar concerns to ones bz was voicing
# [19:54] <Domenic_> ES6 *does* define the Realm in which these functions are called
# [19:54] <aklein> ah, where/when was bz voicing these concerns?
# [19:54] <Domenic_> namely, the same realm they were created in
# [19:54] <Domenic_> presumably "script settings object" could be a property of the realm
# [19:54] <aklein> sure, that's how all functions work
# [19:54] <rniwa> that's some super hairy stuff :(
# [19:54] <aklein> the distinction is between the "entry" settings object and any old settings object
# [19:55] <annevk> aklein: he posted some examples to es-discuss I believe
# [19:55] <aklein> annevk: ok, will go look
# [19:55] <annevk> aklein: about what promises doesn't define at the moment
# [19:55] <Domenic_> aklein: I'm not sure I understand that distinction
# [19:55] * Joins: zdobersek (~zan@109.201.152.241)
# [19:55] <Hixie> aklein: when no script is running
# [19:55] * abinader|afk is now known as abinader
# [19:56] <Domenic_> aklein: my understanding is that window.location.href in that callback should refer to the window.location.href for wherever the function was created
# [19:56] <aklein> Domenic_: nope, it's much crazier than that
# [19:56] <Domenic_> so if you got the function from another iframe it would affect the other iframe
# [19:56] <aklein> Domenic_: it actually depends not on where the function that's calling window.location.href lives
# [19:56] * Joins: estellevw (~estellewy@surveymonkey-3.border1.pao001.pnap.net)
# [19:57] <aklein> but instead on which document had the event or script tag in it
# [19:57] <Domenic_> aklein: ah ok, this is one of those crazy web-compat things where the straightforward answer is not compatible
# [19:57] <rniwa> aklein: please be sure to add that to ES6/W3C test suite.
# [19:57] <Domenic_> it is starting to come back to me now
# [19:57] <aklein> Hixie: so you'd be surprised if there was script running but there was no entry settings object?
# [19:58] * Joins: jernoble (~jernoble@216.113.168.135)
# [19:58] * rniwa feels that "those crazy web-compat things" come up way too often in anything related to ES5/ES6
# [19:58] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [19:58] * tyoshino____ is now known as tyoshino
# [19:58] <aklein> rniwa: there are already incompatibilities between Blink and Gecko :(
# [19:58] <rniwa> aklein: I'm sure there are plenty of them
# [19:58] <aklein> rniwa: I mean in this particular case of Location
# [19:59] <aklein> and "entry" settings
# [19:59] <aklein> rniwa: you don't happen to know how JSC handles this notion, by any chance?
# [19:59] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Changing host)
# [19:59] * Joins: diffalot (~diffalot@unaffiliated/papyromancer)
# [19:59] <rniwa> aklein: definitely not, sorry :(
# [19:59] <annevk> aklein: http://esdiscuss.org/topic/specification-styles#content-11 is the specific email I was thinking about
# [19:59] <rniwa> aklein: you might want to check with weinig or ggaren on #webkit?
# [20:00] <annevk> aklein: a script running without a settings object would go horribly wrong for a number of APIs
# [20:00] <aklein> annevk: it certainly goes horribly wrong in chrome :)
# [20:00] <annevk> aklein: all APIs that deal with URLs for instance
# [20:01] <annevk> (except for new URL, funnily enough)
# [20:01] <Hixie> aklein: there should definitely be a script settings entry whatsit if a script is running
# [20:01] <Hixie> aklein: any time code executes, it has to go through http://www.whatwg.org/specs/web-apps/current-work/#jump-to-a-code-entry-point to execute
# [20:02] <Hixie> aklein: that first calls http://www.whatwg.org/specs/web-apps/current-work/#prepare-to-run-a-callback which pushes a script settings object onto the stack of script settings objects
# [20:04] <Hixie> aklein: actually, there's one other way script can run, which is callbacks run by WebIDL; WebIDL pushes the script settings objects onto the stack manually. See WebIDL 4.8.
# [20:04] <Hixie> heycam|away|away: looks like webidl hasn't been updated to the new terminology regarding script settings objects btw
# [20:07] * Quits: rniwa (~rniwa@67.164.23.121) (Quit: rniwa)
# [20:09] <aklein> annevk: excellent, that is exactly the case, I'll study bz's post
# [20:10] <aklein> Hixie: unfortunately https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues also calls into script and doesn't use the HTML hook
# [20:10] <annevk> aklein: might be worth posting that tidbit to es-discuss; both Allen and Domenic_ were surprised ES didn't match reality
# [20:10] <aklein> (for obvious reasons, but still)
# [20:10] <annevk> aklein: and I'm not sure they quite followed what bz went on about
# [20:11] <annevk> aklein: seems like ES should expose some hooks (one of the other hooks it still needs is for a configurable this object)
# [20:12] * Quits: rafaelrinaldi (~textual@B12E84DD.dynamic.spo.dsl.tesa.net.br) (Quit: My Mac Mini has gone to sleep. ZZZzzz…)
# [20:12] <aklein> I'm constantly amused that the way specs are segmented leads implementations to be broken in exactly the same way as the specs they implement
# [20:13] <aklein> in this case, it's V8 caring not at all about tagging things as "entry" settings objects
# [20:13] <hober> conway's law + murphy's law?
# [20:13] <aklein> indeed
# [20:14] * Quits: jeremyj (~jeremyj@c-24-4-202-10.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [20:14] <aklein> Hixie: the thread annevk linked to (http://esdiscuss.org/topic/specification-styles#content-11) might be interesting to you too...
# [20:16] * Joins: IZh (~IZh@0897578511.static.corbina.ru)
# [20:20] * Quits: jernoble (~jernoble@216.113.168.135) (Quit: Textual IRC Client: www.textualapp.com)
# [20:20] * Joins: rafaelrinaldi (~textual@B12E84DD.dynamic.spo.dsl.tesa.net.br)
# [20:22] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
# [20:23] * Quits: jeffreyatw (~jeffreyat@199-188-192-206.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
# [20:26] * Joins: benv (~benv@38.104.194.126)
# [20:26] <galineau> TabAtkins: there is another sylvaing in #whatwg
# [20:27] <hober> galineau: then use sgalineau so i can still s<TAB>
# [20:27] <TabAtkins> Yus.
# [20:27] <TabAtkins> STAB
# [20:28] <galineau> TabAtkins: Stab Atkins!
# [20:28] <TabAtkins> Stab Bat-Skins is my halloween name.
# [20:28] <annevk> Hixie: what if we created a custom addEventListener for service workers that did something similar to what onmessage does in the port API? See https://github.com/slightlyoff/ServiceWorker/issues/225 for context
# [20:28] <annevk> JakeA: ^
# [20:29] * Parts: galineau (sid26595@gateway/web/irccloud.com/x-tuciqkrufkxjhyli)
# [20:29] * Joins: galineau (sid26595@gateway/web/irccloud.com/x-tuciqkrufkxjhyli)
# [20:30] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [20:30] * galineau is now known as sgalineau
# [20:31] <sgalineau> RESOLVED
# [20:31] * sgalineau renamed himself. Must be Last Call!
# [20:33] <Hixie> aklein: sounds like a bug in ES
# [20:34] <Hixie> annevk: any particular reason we're using events here rather than just having a dedicated callback mechanism with one callback per "event"? that would make it unambiguous that it had different semantics.
# [20:35] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 246 seconds)
# [20:36] * Joins: othermaciej (~mjs@17.245.31.40)
# [20:38] * Joins: rniwa (~rniwa@17.202.43.222)
# [20:38] <JakeA> Hixie: you can importScripts 3rd party services which may want a say too
# [20:38] <Hixie> ah
# [20:39] <Hixie> so what happens if two event handlers do contradictory things?
# [20:39] <JakeA> With fetch in particular, you're responding to a thing that happened and potentially making it do something other then the default, events seem to fit
# [20:40] <Hixie> *shrug*
# [20:40] * Krinkle|detached is now known as Krinkle
# [20:40] <JakeA> Hixie: handing the request (respondWith) is an implicit prevent Default and stopImmediatePropogation
# [20:40] <Hixie> uh
# [20:40] <JakeA> Ugh, my phone made that really difficult to type
# [20:41] <Hixie> this sounds less and less like true DOM events
# [20:41] * Joins: benvie (~bbenvie@corp-nat.p2p.sfo1.mozilla.com)
# [20:42] * Joins: hasather (~hasather@80.91.33.141)
# [20:42] <Hixie> i think if you find yourself having to adjust how the API works both in registration and in handling, you might be better off just making a new API, personally
# [20:43] <Hixie> (this isn't a bad thing)
# [20:44] * Quits: Smylers (~smylers@host86-147-24-198.range86-147.btcentralplus.com) (Ping timeout: 240 seconds)
# [20:45] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [20:47] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 240 seconds)
# [20:47] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
# [20:48] * Quits: prosana (~julian@xdsl-85-197-29-155.netcologne.de) (Ping timeout: 240 seconds)
# [20:49] * Joins: prosana (~julian@xdsl-84-44-194-184.netcologne.de)
# [20:51] * Quits: fredy (~fredy@2001:648:2ffc:1225:a800:ff:fe12:113e) (Excess Flood)
# [20:53] * Joins: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr)
# [20:53] * Joins: jernoble (~jernoble@216.113.168.135)
# [20:57] <annevk> JakeA: that could actually be nice
# [20:57] <annevk> JakeA: we could have callbacks that have a promise as return value and such
# [20:59] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
# [20:59] * Joins: satazor (~satazor@12.60.103.87.rev.vodafone.pt)
# [21:00] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Ping timeout: 250 seconds)
# [21:05] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [21:06] * Quits: jernoble (~jernoble@216.113.168.135) (Quit: Computer has gone to sleep.)
# [21:07] * Quits: estellevw (~estellewy@surveymonkey-3.border1.pao001.pnap.net) (Quit: estellevw)
# [21:10] <JakeA> annevk: well, app.get(urlRe, callback) will be the first library I build
# [21:11] <JakeA> annevk: but I want a catch-all to do the usual get-it-from-the-cache-if-its-there bit
# [21:11] * Quits: satazor (~satazor@12.60.103.87.rev.vodafone.pt) (Read error: Connection reset by peer)
# [21:11] * Joins: hasather (~hasather@80.91.33.141)
# [21:12] <annevk> JakeA: I mean that instead of event.respondWith() and waitUntil(), you'd have self.add("fetch", function() { return promise })
# [21:12] <JakeA> Hixie: annevk: It feel really similar to an event. Eg, I can observe click, I can also prevent the default and do something else. Fetch is like that, but the alternative response is passed to event.respondWith, which also calls event.preventDefault & event.stopImmediatePropogation
# [21:12] <annevk> or self.listen() / self.observe()
# [21:12] <JakeA> I'm not against it
# [21:12] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [21:13] <JakeA> But is it different enough to warrant it?
# [21:14] <JakeA> I can see us having an API in future where there's a url match. Might be a useful optimisation, but mostly useful for third party code
# [21:14] <annevk> I don't see the current system matching events much
# [21:15] <annevk> We want register side effects, we want to return promises
# [21:15] <JakeA> It tells you about a thing that happened at a time when you can override default behaviour. Do we have DOM APIs that do that that aren't events?
# [21:16] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
# [21:16] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 276 seconds)
# [21:16] <annevk> .sort()
# [21:16] <JakeA> array.sort()?
# [21:17] <JakeA> That starts a sort, it doesn't listen for one
# [21:17] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: Textual IRC Client: www.textualapp.com)
# [21:17] <annevk> The callback is called and allows overriding behavior
# [21:18] <othermaciej> callbacks with a promise as a return value? why would you want that?
# [21:18] <JakeA> othermaciej: Well, that's exactly how .then() is
# [21:18] <annevk> othermaciej: current API is onfetch = function(e) { e.respondWith(promise) }
# [21:19] <othermaciej> I probably lack sufficient context but who is the ultimate consumer of the promise?
# [21:19] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [21:19] <othermaciej> is there another layer of API that returns it?
# [21:19] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [21:20] <othermaciej> I agree that calling an event method with a promise in an event handler seems dodgy
# [21:20] <annevk> othermaciej: the browser consumes it and extracts a response object
# [21:20] <JakeA> annevk: I see what you mean, but .sort triggers the event, and once it's complete, it doesn't happen again
# [21:21] <othermaciej> the idea of returning a promise that the browser itself is supposed to use seems weird to me, but probably due to lack of understanding
# [21:22] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 240 seconds)
# [21:22] <annevk> JakeA: it seems we're not really using any bit from the event API and hacking around where it does not meet our needs
# [21:22] <annevk> JakeA: it's not entirely clear what it buys us
# [21:23] <othermaciej> I would expect the straightforward way to do it would be that a fetch callback gets some object that it can report to when (asynchronously) done
# [21:23] <JakeA> othermaciej: When the browser makes a resource request, imagine it's creating a promise for the response. If the response fails, it does something else (eg, an image with an x). You get to provide that promise.
# [21:23] <annevk> othermaciej: so the idea is that a response is an async value
# [21:23] <othermaciej> but I guess if the async fetch it would do already naturally returns a promise, then it’s convenient
# [21:23] <annevk> othermaciej: so we don't have to load the entire thing into memory
# [21:24] <annevk> othermaciej: so yes, if you do a fetch in the worker it'll return a promise, which you would then give to the browser
# [21:24] <othermaciej> sure, I assume you do potentially-asynchronous I/O in response to a fetch request
# [21:25] <JakeA> othermaciej: we looked at respondWith(fetch(url)) vs fetch(url).then(respondWith) - the latter gets really messy fast
# [21:25] <othermaciej> I am just not sure what the promise adds other than extra levels of indirection
# [21:25] <annevk> othermaciej: right, so it seems kind of natural that you have dofetchrequest(callback) and callback returns a promise that handles the request et al
# [21:25] <annevk> othermaciej: what else would you do?
# [21:26] <othermaciej> I don’t know what respondWith is in that example
# [21:26] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [21:26] <annevk> othermaciej: you might want to read up a bit on https://github.com/slightlyoff/ServiceWorker/
# [21:26] <othermaciej> annevk: I’m obviously not “thinking with promises” yet because you seem to expect that statement to be completely intuititvely obvious and it’s not to me
# [21:26] <JakeA> othermaciej: In ServiceWorker's onfetch event, it's the mechanism to hijack the request and respond with something else
# [21:27] <annevk> othermaciej: yeah sorry
# [21:27] <JakeA> actually, it should be respondWith(fetch(url)) vs fetch(url).then(respondWith, respondWith)
# [21:27] <annevk> othermaciej: I wish I could explain in person
# [21:28] <JakeA> othermaciej: Providing a promise allows you to synchronously state your intention to handle the request but handle it in an async way
# [21:28] <othermaciej> annevk: where is the viewable form of the spec in that?
# [21:28] <SamB> ... so is there special magic that the browser does when it consumes a primitive promise in the return value of this failure callback?
# [21:28] <SamB> like, never actually building the promised value?
# [21:29] <JakeA> I'm not sure I get what you mean
# [21:29] <annevk> othermaciej: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html is some of it I suppose
# [21:29] <annevk> othermaciej: but I recommend reading https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md first
# [21:29] <JakeA> SamB: It waits for the promise to resolve, if it rejects it's a network error. If it resolves with not-a-response, networkerror
# [21:30] <othermaciej> that seems to have large chunks of missing and/or misformatted content so I assumed it was not the right thing
# [21:31] <othermaciej> ok, looking at the example of the use of onfetch
# [21:31] * Joins: Smylers (~smylers@host86-159-65-72.range86-159.btcentralplus.com)
# [21:31] <othermaciej> I would have thought the natural thing would be that you can call e.respondWith at any later time, so if your actual fetch is asynchronous, you end up calling it outside the scope of the fetch callback
# [21:31] <othermaciej> but I assume there’s some reason that is not good enough, or something
# [21:32] <othermaciej> it also seems a bit weird to use an event listener for this, because there can only be one response
# [21:32] <othermaciej> if there are 10 listeners registered, which one wins?
# [21:33] <JakeA> othermaciej: Providing a promise allows you to synchronously state your intention to handle the request but handle it in an async way
# [21:33] <othermaciej> does respondsWith implicitly prevent further event dispatch?
# [21:33] <JakeA> yes
# [21:33] <JakeA> preventDefault and stopImmediatePropogation
# [21:33] * Joins: sicking (~sicking@guest-nat.p2p.sfo1.mozilla.com)
# [21:34] <othermaciej> I see
# [21:34] <JakeA> If you allow e.respondWith to be called at a later time, you get that race condition you mention
# [21:34] <othermaciej> this seems pretty hard to understand for the uninitiated
# [21:35] <othermaciej> it almost seems better to have a single callback, since otherwise you have a strong dependency on registration order, so your callbacks have to coordinate anyway
# [21:35] <JakeA> We need to allow third party imports
# [21:36] <JakeA> Order matters, just as it does with click events
# [21:36] <othermaciej> if you do that, there’s no need to synchronously indicate intent to reply, and the whole thing becomes a lot simpler
# [21:36] <JakeA> Yep, it makes it simpler with event listeners in general
# [21:37] <othermaciej> is capture supported?
# [21:37] <JakeA> No
# [21:38] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
# [21:39] <JakeA> I'm open to the idea of this being not-an-event-listener (should be discussed on github), but we must support multiple "listeners"
# [21:39] <othermaciej> I would say I’ll review it when there’s a spec, but by then it will probably be too late to five feedback
# [21:39] <othermaciej> *give
# [21:39] * Quits: othermaciej (~mjs@17.245.31.40) (Quit: othermaciej)
# [21:40] <JakeA> There's a ts file with the API if you want to give feedback earlier. It needs updating from the most recent f2f but it's pretty solid
# [21:40] <JakeA> Oh, they're gone
# [21:40] * Joins: othermaciej (~mjs@17.245.31.40)
# [21:44] <annevk> JakeA: what is gone?
# [21:46] * Quits: prosana (~julian@xdsl-84-44-194-184.netcologne.de) (Ping timeout: 240 seconds)
# [21:46] <JakeA> othermaciej: There's a ts file with the API if you want to give feedback earlier. It needs updating from the most recent f2f but it's pretty solid
# [21:46] <JakeA> annevk: othermaciej vanished for a moment
# [21:49] <Domenic_> returning a promise is attractive FWIW
# [21:53] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Quit: jeffreyatw)
# [21:54] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
# [21:56] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [21:59] <annevk> We should consider adding http://www.nohello.com/ to the topic, although it happens rarely enough I suppose
# [22:00] <annevk> Domenic_: yes, the current API is ugly
# [22:00] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [22:03] * Joins: estellevw (~estellewy@173-228-112-232.dsl.dynamic.sonic.net)
# [22:03] * Joins: KenjiBX (KenjiBX@nat/google/x-zmpkixqzdqrepsif)
# [22:05] * Quits: aretecode (~aretecode@98.126.165.186) (Remote host closed the connection)
# [22:06] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [22:07] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [22:08] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [22:08] * Joins: jernoble (~jernoble@17.202.45.163)
# [22:09] * Joins: aretecode (~aretecode@98.126.165.186)
# [22:18] <JakeA> Domenic_: although we'd have to treat some return values as "unhandled", probably just undefined
# [22:18] <JakeA> Domenic_: returning an actual response object should work
# [22:18] * Krinkle is now known as Krinkle|detached
# [22:22] <Domenic_> JakeA: just Promise.resolve() the return value
# [22:24] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
# [22:24] * Quits: Areks_home (~Areks@128-72-103-77.broadband.corbina.ru) (Ping timeout: 240 seconds)
# [22:26] * Quits: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) (Ping timeout: 240 seconds)
# [22:26] * Quits: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso) (Remote host closed the connection)
# [22:27] * Joins: bholley (~bholley@98.210.101.88)
# [22:27] * Joins: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso)
# [22:27] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 250 seconds)
# [22:28] * Joins: fredy (~fredy@2001:648:2ffc:1225:a800:ff:fe12:113e)
# [22:29] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [22:30] * Quits: sicking (~sicking@guest-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [22:32] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [22:32] <JakeA> Domenic_: hmm, feels nicer not to require that of the developer
# [22:33] <Domenic_> JakeA: that's what I meant; the implementation should Promise.resolve() the return value
# [22:33] <Domenic_> JakeA: step 8 onward of https://github.com/whatwg/streams#constructor-start-pull-cancel-
# [22:34] <JakeA> Domenic_: but that gets racey if you have multiple "listeners"
# [22:34] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [22:34] <Domenic_> JakeA: how so more racey than e.waitUntil?
# [22:34] <JakeA> Something needs to be a sync signal of "nahhh, I'm not handling this"
# [22:34] <Domenic_> oh gross
# [22:34] <Domenic_> so the function has both sync and async behavior
# [22:34] <JakeA> Domenic_: onfetch doesn't have waituntil
# [22:34] * Quits: benv (~benv@38.104.194.126) (Quit: Computer has gone to sleep.)
# [22:35] <JakeA> Domenic_: depends how you think of it. You synchronously provide a promise, but that promise represents an async value
# [22:36] <JakeA> Eg, you can't asynchronously provide a value to .then(), you need to return the response synchronously
# [22:41] <JakeA> But yeah, undefined becomes "not handling" in the onfetch case. I guess this is why respondWith is a better intent
# [22:41] * Joins: arunranga (~otherarun@208.82.13.98)
# [22:41] * Joins: Smylers1 (~smylers@host86-147-44-245.range86-147.btcentralplus.com)
# [22:42] * Joins: nephyrin` (~neph@corp.mtv2.mozilla.com)
# [22:42] * Quits: nephyrin (~neph@corp.mtv2.mozilla.com) (Read error: Connection reset by peer)
# [22:42] * Quits: Smylers (~smylers@host86-159-65-72.range86-159.btcentralplus.com) (Ping timeout: 240 seconds)
# [22:42] <Domenic_> I guess I still prefer promise.then(respondWith) but I'll take your word for it that it's ugly.
# [22:42] <Domenic_> I can already see that it's ugly for error-handling
# [22:44] * Quits: nephyrin` (~neph@corp.mtv2.mozilla.com) (Client Quit)
# [22:45] * Joins: jeffreyatw_ (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
# [22:47] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Ping timeout: 276 seconds)
# [22:47] * jeffreyatw_ is now known as jeffreyatw
# [22:50] <JakeA> Domenic_: and racing
# [22:51] * Quits: KenjiBX (KenjiBX@nat/google/x-zmpkixqzdqrepsif) (Remote host closed the connection)
# [22:51] <JakeA> Domenic_: eg two handlers
# [22:52] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [22:53] * Joins: nephyrin (~neph@corp.mtv2.mozilla.com)
# [22:54] * Quits: Workshiva (~Dashiva@74.125.121.65) (Quit: leaving)
# [22:54] * Quits: Smylers1 (~smylers@host86-147-44-245.range86-147.btcentralplus.com) (Ping timeout: 252 seconds)
# [22:55] * Joins: Smylers (~smylers@host81-132-242-144.range81-132.btcentralplus.com)
# [22:55] * Quits: eatsomeatso (~eatsomeat@gateway/tor-sasl/eatsomeatso) (Quit: eatsomeatso)
# [22:56] * Joins: benv (~benv@38.104.194.126)
# [22:58] * Quits: TallTed (~Thud@63.119.36.36)
# [23:04] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
# [23:05] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Ping timeout: 250 seconds)
# [23:06] * Joins: KevinMarks (~yaaic@2607:fb90:115:76c8:a6ed:379f:eea7:7e3d)
# [23:07] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [23:07] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
# [23:08] * Joins: sicking (~sicking@guest-nat.p2p.sfo1.mozilla.com)
# [23:09] * Quits: bholley (~bholley@98.210.101.88) (Quit: Textual IRC Client: www.textualapp.com)
# [23:10] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [23:10] * Quits: Maurice` (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [23:16] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
# [23:19] * Quits: IZh (~IZh@0897578511.static.corbina.ru) (Quit: liteIRC for Android)
# [23:19] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [23:21] <slightlyoff> sorry for not being available (was in TC39 meetings). othermaciej: happy to answer questions about fetch events
# [23:21] <slightlyoff> Domenic_: it's super ugly
# [23:21] <slightlyoff> Domenic_: the control inversion also doesn't work well with the need to get out of the way early
# [23:25] <slightlyoff> Domenic_: the bigger issue is that ".then(resolveOtherThing)" still misses some way of saying "i've got this, keep me alive until I'm done"
# [23:25] <slightlyoff> Domenic_: so even if you refactored this into 2 apis, you'd still need the moral equivalent of waitUntil() for deciding to "own" the transaction
# [23:25] <slightlyoff> Domenic_: this is something that's also going to be required when we rework IDB
# [23:26] <Domenic_> slightlyoff: hmm interesting stuff
# [23:26] <Domenic_> having two use cases will help refine
# [23:27] <slightlyoff> Domenic_: agreed.
# [23:32] * Quits: KevinMarks (~yaaic@2607:fb90:115:76c8:a6ed:379f:eea7:7e3d) (Ping timeout: 240 seconds)
# [23:35] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
# [23:37] * Krinkle|detached is now known as Krinkle
# [23:40] * Joins: KevinMarks (~yaaic@2607:fb90:115:76c8:a6ed:379f:eea7:7e3d)
# [23:41] * Joins: full_vlad (~full_vlad@p5.eregie.pub.ro)
# [23:41] <full_vlad> hi all!
# [23:42] <full_vlad> Can anyone help me with this problem? https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/sBCw0_jfLhI
# [23:44] * Quits: ehsan (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
# [23:45] * Joins: ehsan_ (~ehsan@66.207.208.102)
# [23:45] <full_vlad> it involves running a content script in all frames from a webpage
# [23:46] * Quits: arunranga (~otherarun@208.82.13.98) (Quit: arunranga)
# [23:47] * Quits: enryptd_fractal (~enryptd_f@66-188-99-174.static.ftbg.wi.charter.com) (Remote host closed the connection)
# [23:49] * Quits: Smylers (~smylers@host81-132-242-144.range81-132.btcentralplus.com) (Quit: Leaving.)
# [23:49] * Joins: scor (~scor@drupal.org/user/52142/view)
# [23:51] <TabAtkins> This channel probably isn't helpful for Chrome Extensions questions.
# [23:52] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete
# [23:52] <SamB> full_vlad: they haven't even begun to standardize content scripts, so they'll not be of much help I'm afraid :-P
# [23:55] <full_vlad> what I found so far is this:
# [23:55] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [23:55] <JakeA> Domenic_: Sanity check: In cases where we provide promise equivalents to events, the promise should resolve after the event right? (https://code.google.com/p/chromium/issues/detail?id=343630#c10)
# [23:55] <full_vlad> the extension runs well on Facebook, Twitter, old google chat (GTalk)
# [23:56] <full_vlad> it doesn't run on Hangouts
# [23:56] <Domenic_> JakeA: I agree with your reasoning. I also think requestAutocomplete is *perfect* for promises
# [23:58] <full_vlad> but when I change the tabs it works, it just doesn't work on refresh
# [23:59] <full_vlad> The Google Plus page (with Hangouts) has many iframes in it, so the content script has to run in its specific iframe (the one with the chat). If i run the privly.run() function inside that specific iframe manually it works
# [23:59] <JakeA> Domenic_: Yeah, adding promises was always the intention. They just wanted out the door before they were available. Although that availability window turned out to be like a week or something
# [23:59] <SamB> full_vlad: again, we don't really know about that stuff here!
# [23:59] <full_vlad> Facebook and Twitter implement their chat box in the top frame, so I think that's the difference
# [23:59] <full_vlad> ok, sorry
# Session Close: Thu Apr 10 00:00:00 2014

The end :)