Options:
- # Session Start: Thu May 08 00:00:00 2014
- # Session Ident: #whatwg
- # [00:01] * Quits: jbv (~circuser-@206.217.86.228) (Remote host closed the connection)
- # [00:04] * Quits: othermaciej (~mjs@17.114.219.231) (Quit: othermaciej)
- # [00:04] * Quits: smaug____ (~chatzilla@cs78246079.pp.htv.fi) (Ping timeout: 265 seconds)
- # [00:09] <MikeSmith> Hixie: "that was due to some DB maintenance earlier, shouldn't be an ongoing thing", I'm told
- # [00:09] <MikeSmith> as far as the 504s earlier today
- # [00:10] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [00:11] * Quits: annevk (~annevk@207.218.72.65) (Remote host closed the connection)
- # [00:12] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
- # [00:13] <zewt> is there somebody specific i can hate for the tcp thing where I randomly have to sit around and twiddle my thumbs for a couple minutes unless I figure out how to set SO_REUSEADDR
- # [00:14] <Hixie> MikeSmith: k
- # [00:14] <Hixie> zewt: oh man, the unix sockets api.
- # [00:14] <Hixie> what a pain.
- # [00:14] <zewt> well it's the kernel socket layer causing the problem, not the api itself
- # [00:15] <zewt> but yeah, heh
- # [00:15] <Hixie> in other twiddling news, i twiddled the spec style sheet again
- # [00:15] <Hixie> hope y'all don't lose your collective minds again :-P
- # [00:17] * Joins: nessy (~silviapf@101.164.214.231)
- # [00:19] <Hixie> man, @scope is simultaneously awesome in its coolness and power, and frightening in its implications on the cascade
- # [00:19] <Hixie> i hope we've staffed up the support lines for more specificity/cascade confusion. :-)
- # [00:19] <Hixie> TabAtkins: ^
- # [00:19] <TabAtkins> Yeah, we might drop it.
- # [00:19] <TabAtkins> The cascade implications are confusing.
- # [00:19] <TabAtkins> And the optimizations we might want to do to scoped styles are less good if they're overused.
- # [00:20] <TabAtkins> Just doing nesting is probably better.
- # [00:20] <zewt> what's confusing, when you can open the inspector and see the css rules applying to an element and their order?
- # [00:23] <Hixie> TabAtkins: is @global something anyone cares about, or should i just drop that?
- # [00:24] <SamB> Hixie: well, define "cares about"
- # [00:25] <Hixie> that anyone will implement
- # [00:25] <SamB> because I'd kind of prefer were required NOT to implement that, personally ...
- # [00:26] <SamB> +it
- # [00:26] <Hixie> k well nobody seems to have championed it so i guess i'll drop it
- # [00:28] * Quits: jonathanmarvens (~jonathanm@199.47.79.34) (Remote host closed the connection)
- # [00:34] * Joins: mark06 (~freenode@unaffiliated/renatosilva)
- # [00:36] * Parts: mark06 (~freenode@unaffiliated/renatosilva)
- # [00:38] <zewt> remind me what @global is?
- # [00:38] <zewt> escape from @scope?
- # [00:38] <SamB> zewt: that's the thing I don't want to exist, certainly
- # [00:39] * Quits: kangil (~kangil@210.94.41.89) (Remote host closed the connection)
- # [00:39] <SamB> zewt: or from <style scoped>, no?
- # [00:39] * Quits: nicholasserra (~Adium@cpe-24-93-244-49.neo.res.rr.com) (Quit: Leaving.)
- # [00:39] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 29.0/20140428110119])
- # [00:40] <zewt> i don't know what the use cases are, but it seems nice to be able to know for sure that if you insert a DOM tree inside a scoped stylesheet, it's not capable of breaking out of that and affecting other things (intentionally or not)
- # [00:40] <SamB> zewt: actually I think it'
- # [00:40] <zewt> but i'm assuming i know what we're talking about when I probably don't
- # [00:40] <SamB> er, that is, it's still possible to get out of the box, I think
- # [00:41] * Joins: annevk (~annevk@2.31.25.182)
- # [00:41] <SamB> possibly you'd need a particular attribute along with the <style scoped>
- # [00:41] * Joins: kangil (~kangil@210.94.41.89)
- # [00:41] <zewt> font-face, etc. are still scoped, right? (i remember some suggestions for font-face to not be scoped, which seemed like a terrible idea)
- # [00:41] <SamB> Hixie: hmm, so what is supposed to happen if a <style> without <scoped> appears in the body anyway?
- # [00:41] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
- # [00:42] <SamB> zewt: you mean @font-face ?
- # [00:42] <zewt> yeah
- # [00:42] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
- # [00:42] <Hixie> zewt: yeah, it was the escape mechanism
- # [00:42] <Hixie> SamB: same as if it's in the head
- # [00:43] <SamB> presumably instead of making that not-scoped, browsers should just, you know, hash-cons them ...
- # [00:43] <Hixie> SamB: (but it's invalid)
- # [00:43] <Hixie> @font-face and company aren't scoped, which seems terrible to me
- # [00:43] * Quits: espadrine` (~ttyl@AMontsouris-158-1-27-195.w92-128.abo.wanadoo.fr) (Ping timeout: 276 seconds)
- # [00:43] <Hixie> same with counter styles, etc
- # [00:43] * Quits: marcosc (~marcosc@66.207.208.102) (Remote host closed the connection)
- # [00:43] <SamB> Hixie: Ah. It seems like the spec very carefully doesn't actually SAY that it should act that way.
- # [00:43] <zewt> yuck, they definitely need to be scoped
- # [00:44] <Hixie> SamB: really?
- # [00:44] <SamB> hmm, well, that's what I remember thinking anyway
- # [00:44] <SamB> my memory is terrible though
- # [00:44] <Hixie> heh
- # [00:44] * Hixie just uses the spec as his memory :-)
- # [00:46] * Joins: othermaciej (~mjs@17.114.219.231)
- # [00:46] <zewt> do you remember why they were made non-scoped? (wondering if there's any point to filing a bug to reopen that conversation)
- # [00:46] <SamB> I think it would be better to ban them in scopes for now ...
- # [00:46] <zewt> i guess i could find out for myself, i think i was in that thread
- # [00:46] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Ping timeout: 240 seconds)
- # [00:47] <zewt> they should just be scoped like anything else
- # [00:47] <SamB> (if it's because it's too hard to implement them scoped properly)
- # [00:47] <Hixie> zewt: it turns out to not be obvious what it means to scope them
- # [00:48] <SamB> so, um, ban them until it becomes obvious?
- # [00:48] <zewt> it seems obvious from the author's perspective, anyway, though my mental picture of what scoping stylesheets actually means could be wrong
- # [00:49] <Hixie> zewt: like, suppose that an element has the font-family 'foo', and that there's a @font-family rule that sets 'foo'. Now suppose there's a scoped section that introduces a new font called 'foo'. An element in that section has 'font: inherit'. What font should it use?
- # [00:49] <SamB> it is reasonably easy to find out what authors would expect: ban it for now and wait for them to show what they wanted to use it for but can't
- # [00:49] <Hixie> SamB: yeah, maybe. dunno. not my spec, not my problem. :-)
- # [00:49] <SamB> Hixie: so it's a dynamic/lexical scope issue?
- # [00:49] <Hixie> it's a cascade/inheritance issue
- # [00:50] <SamB> oh right
- # [00:50] <SamB> didn't read far enough
- # [00:50] <SamB> I was thinking "one of the outer rules references a name that's rebound in the scope, and applies to one of the inner elements"
- # [00:51] <zewt> seems like if you're <div><style scoped>xxx</style>yyy</div><div>zzz</div>, yyy should act exactly as though the @scoped attribute wasn't present, and zzz should act as if the <style scoped> node doesn't even exist
- # [00:51] <SamB> Hixie: I'd go with inherit the font actually used outside
- # [00:52] * Joins: weinig (~weinig@17.114.216.47)
- # [00:52] * Quits: plutoniix (~plutoniix@node-lob.pool-101-108.dynamic.totbb.net) (Ping timeout: 240 seconds)
- # [00:53] * Joins: plutoniix (~plutoniix@node-lob.pool-101-108.dynamic.totbb.net)
- # [00:54] <zewt> afk
- # [00:56] * Joins: espadrine` (~ttyl@AMontsouris-158-1-55-200.w92-128.abo.wanadoo.fr)
- # [00:56] <Hixie> SamB: the issue you raise is another one, yeah
- # [00:56] <Hixie> font-family is currently just a bunch of strings, so to make it work as y'all are describing it would need to change to a much more elaborate model
- # [00:57] <Hixie> which has huge performance implications
- # [00:57] <Hixie> which isn't good for something as core to web rendering as "picking a font"
- # [00:57] <Hixie> in other news, https://critic.hoppipolla.co.uk/static-resource/seal-of-approval-left.png is awesome.
- # [00:58] <SamB> Hixie: couldn't it just be a list of pointers to font-faces ?
- # [00:58] * Quits: othermaciej (~mjs@17.114.219.231) (Quit: othermaciej)
- # [00:58] <SamB> but IMO plain ban putting it in @scoped/<style scoped> rather than doing something stupid with it
- # [00:59] <Hixie> if it's a list of pointers, then taking getComputedStyle() and sticking it back into style="" would actually chnage the style.
- # [00:59] <Hixie> anyway this isn't my spec so i dunno
- # [01:00] <SamB> Hixie: oh right
- # [01:06] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:6c0b:3530:9c07:548)
- # [01:10] * Joins: othermaciej (~mjs@17.114.219.231)
- # [01:15] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Quit: Gone to save the world!)
- # [01:15] <zewt> Hixie: not sure how it's any worse than css selectors, though
- # [01:16] <zewt> where you're doing much more complicated lookups
- # [01:17] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [01:17] <zewt> i mean, if it's hard to implement a stack of scoped font-face values efficiently, i'd think a stack of scoped css rules would be far worse
- # [01:23] * Quits: nessy (~silviapf@101.164.214.231) (Quit: Leaving.)
- # [01:25] * Joins: morbidlyobese (~morbidlyo@gateway/tor-sasl/morbidlyobese)
- # [01:28] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
- # [01:28] * Joins: nessy (~silviapf@101.164.214.231)
- # [01:30] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [01:33] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 240 seconds)
- # [01:41] * Quits: annevk (~annevk@2.31.25.182) (Remote host closed the connection)
- # [01:45] * Quits: mven_ (~textual@169.241.49.240) (Ping timeout: 258 seconds)
- # [01:46] * Quits: lmcliste_ (~lmclister@192.150.10.210)
- # [01:46] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Remote host closed the connection)
- # [01:52] * Joins: KevinMarks (~yaaic@2607:fb90:2208:b67c:51a5:1a43:4290:a3f8)
- # [01:57] * Quits: othermaciej (~mjs@17.114.219.231) (Quit: othermaciej)
- # [01:57] * Quits: weinig (~weinig@17.114.216.47) (Quit: weinig)
- # [01:59] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [02:00] * Joins: nicholasserra (~Adium@cpe-24-93-244-49.neo.res.rr.com)
- # [02:00] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Remote host closed the connection)
- # [02:01] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [02:02] * Quits: ap (~ap@2620:149:4:304:d549:5595:872:aaa7) (Quit: ap)
- # [02:03] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Read error: Connection reset by peer)
- # [02:03] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [02:03] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Remote host closed the connection)
- # [02:06] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [02:09] * Joins: seventh (seventh@31.6.13.194)
- # [02:11] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [02:19] * Joins: foxtrotwhiskey (~foxtrotwh@c-98-225-154-188.hsd1.pa.comcast.net)
- # [02:19] * Quits: foxtrotwhiskey (~foxtrotwh@c-98-225-154-188.hsd1.pa.comcast.net) (Client Quit)
- # [02:19] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [02:23] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
- # [02:26] * Quits: jsbell (jsbell@nat/google/x-elkztvnyqewxtacw) (Remote host closed the connection)
- # [02:30] * Quits: nicholasserra (~Adium@cpe-24-93-244-49.neo.res.rr.com) (Quit: Leaving.)
- # [02:31] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Quit: jeffreyatw)
- # [02:38] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
- # [02:38] * Quits: nessy (~silviapf@101.164.214.231) (Quit: Leaving.)
- # [02:40] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
- # [02:43] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Quit: TuRnaD0)
- # [02:46] * Quits: ehsan (~ehsan@66.207.208.102) (Quit: Leaving...)
- # [02:49] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net) (Remote host closed the connection)
- # [02:57] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
- # [02:57] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [02:57] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:6c0b:3530:9c07:548) (Remote host closed the connection)
- # [03:01] * Joins: rxgx (uid22483@gateway/web/irccloud.com/x-ntikeeibodqaortn)
- # [03:02] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 250 seconds)
- # [03:10] * Quits: diffalot (~diffalot@unaffiliated/papyromancer) (Read error: Connection reset by peer)
- # [03:11] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
- # [03:11] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [03:12] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 276 seconds)
- # [03:12] * Joins: Goplat (~goplat@reactos/developer/Goplat)
- # [03:18] * Joins: mven_ (~textual@ip68-104-38-84.lv.lv.cox.net)
- # [03:20] * Quits: mven_ (~textual@ip68-104-38-84.lv.lv.cox.net) (Client Quit)
- # [03:20] * Joins: mven_ (~textual@ip68-104-38-84.lv.lv.cox.net)
- # [03:36] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
- # [03:36] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [03:39] * Quits: jochen__ (jochen@nat/google/x-ayzqkxxnhktoelke) (Read error: Operation timed out)
- # [03:39] * Quits: estellevw (~estellevw@209.49.73.82) (Ping timeout: 240 seconds)
- # [03:41] * Joins: jochen__ (jochen@nat/google/x-flsltuhrjxlhwtpe)
- # [03:46] <MikeSmith> cabanier: so I reckon if I keep helping with preparation for this 2dcontext LCWD it's likely to end up costing me a full day of time I'd rather have spent working on other things that I actually care about
- # [03:48] * Joins: estellevw (~estellevw@209.49.73.82)
- # [03:51] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [03:56] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 252 seconds)
- # [04:01] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [04:04] <cabanier> MikeSmith: sorry...
- # [04:08] * Joins: weinig (~weinig@98.234.191.242)
- # [04:11] * Quits: weinig (~weinig@98.234.191.242) (Client Quit)
- # [04:26] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:6c0b:3530:9c07:548)
- # [04:28] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
- # [04:30] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
- # [04:35] * Quits: seventh (seventh@31.6.13.194) (Ping timeout: 240 seconds)
- # [04:45] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [04:50] * Joins: markkes (~markkes@62.207.90.201)
- # [04:50] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 250 seconds)
- # [04:52] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
- # [04:57] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
- # [05:04] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [05:11] * Quits: estellevw (~estellevw@209.49.73.82) (Quit: Snuggling with the puppies)
- # [05:17] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Ping timeout: 265 seconds)
- # [05:22] * Quits: plutoniix (~plutoniix@node-lob.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
- # [05:25] * Quits: morbidlyobese (~morbidlyo@gateway/tor-sasl/morbidlyobese) (Write error: Connection reset by peer)
- # [05:27] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
- # [05:29] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
- # [05:32] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [05:36] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [05:36] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
- # [05:39] * Joins: weinig (~weinig@98.234.191.242)
- # [05:40] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [05:40] * Quits: weinig (~weinig@98.234.191.242) (Client Quit)
- # [05:44] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
- # [05:45] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 255 seconds)
- # [05:45] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
- # [05:46] * Quits: benv (~benv@38.104.194.126) (Quit: Computer has gone to sleep.)
- # [05:50] * Quits: rxgx (uid22483@gateway/web/irccloud.com/x-ntikeeibodqaortn) (Quit: Connection closed for inactivity)
- # [05:51] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 245 seconds)
- # [05:53] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [05:57] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
- # [05:57] * Joins: morbidlyobese (~morbidlyo@gateway/tor-sasl/morbidlyobese)
- # [05:58] * Joins: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net)
- # [05:58] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
- # [06:03] * Joins: weinig (~weinig@98.234.191.242)
- # [06:04] * Joins: plutoniix (~plutoniix@node-11fz.pool-180-180.dynamic.totbb.net)
- # [06:04] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Ping timeout: 252 seconds)
- # [06:15] * Joins: IZh (~IZh@83.220.236.173)
- # [06:18] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
- # [06:27] * Joins: a-ja (~Instantbi@70.230.148.198)
- # [06:31] * Quits: KevinMarks (~yaaic@2607:fb90:2208:b67c:51a5:1a43:4290:a3f8) (Ping timeout: 240 seconds)
- # [06:32] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [06:33] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
- # [06:34] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [06:34] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [06:37] * Quits: karlcow (~karl@nerval.la-grange.net) (Client Quit)
- # [06:37] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [06:37] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [06:38] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 240 seconds)
- # [06:40] * Quits: weinig (~weinig@98.234.191.242) (Quit: weinig)
- # [06:41] * Joins: jeffreyatw (~jeffreyat@199-188-192-248.PUBLIC.monkeybrains.net)
- # [06:50] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
- # [06:52] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
- # [06:55] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 252 seconds)
- # [07:02] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Remote host closed the connection)
- # [07:03] * Joins: lmclister (~lmclister@192.150.10.210)
- # [07:05] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:6c0b:3530:9c07:548) (Remote host closed the connection)
- # [07:07] * Quits: mven_ (~textual@ip68-104-38-84.lv.lv.cox.net) (Read error: Connection reset by peer)
- # [07:07] * Joins: mven__ (~textual@ip68-104-38-84.lv.lv.cox.net)
- # [07:12] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [07:14] * Quits: 7F1AAJXST (scrollback@conference/jsconf/x-fvxugcugqpyeitab) (Remote host closed the connection)
- # [07:14] * Joins: 64MAAKH6I (scrollback@conference/jsconf/x-utbvskkwhrforkja)
- # [07:24] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
- # [07:26] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 264 seconds)
- # [07:26] * jdaggett_ is now known as jdaggett
- # [07:28] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [07:30] * Quits: lmclister (~lmclister@192.150.10.210)
- # [07:33] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 252 seconds)
- # [07:33] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [07:37] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [07:41] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
- # [07:42] * Quits: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net) (Quit: Snuggling with the puppies)
- # [07:42] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
- # [07:43] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [07:43] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
- # [07:48] * Joins: zdobersek (~zan@109.201.154.169)
- # [07:50] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:81ed:da09:8f81:486c)
- # [07:52] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
- # [07:52] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:81ed:da09:8f81:486c) (Remote host closed the connection)
- # [07:55] * Quits: jeffreyatw (~jeffreyat@199-188-192-248.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
- # [07:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
- # [08:03] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [08:06] * Joins: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net)
- # [08:09] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:d5a:16a7:ed46:5852)
- # [08:11] * Quits: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net) (Quit: estellevw)
- # [08:11] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:d5a:16a7:ed46:5852) (Remote host closed the connection)
- # [08:22] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
- # [08:22] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 240 seconds)
- # [08:22] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [08:23] * Joins: niloy (~niloy@106.221.194.255)
- # [08:25] * Joins: Ducki (~Ducki@137.116.197.171)
- # [08:26] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 240 seconds)
- # [08:30] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [08:34] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [08:38] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [08:39] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Read error: Connection reset by peer)
- # [08:39] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [08:48] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
- # [08:48] * Joins: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk)
- # [08:51] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [08:51] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 240 seconds)
- # [08:56] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
- # [08:56] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [08:57] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Quit: TuRnaD0)
- # [08:58] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
- # [09:15] * Joins: markkes (~markkes@62.207.90.201)
- # [09:16] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [09:18] * Joins: Ms2ger (~Ms2ger@91.182.58.217)
- # [09:21] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 264 seconds)
- # [09:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [09:39] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [09:41] * Quits: IZh (~IZh@83.220.236.173) (Read error: Connection reset by peer)
- # [09:52] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [09:55] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 252 seconds)
- # [09:57] * Joins: Kolombiken (~Adium@gateway.creuna.se)
- # [10:01] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
- # [10:11] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [10:12] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:95d1:6a72:345f:c6ab)
- # [10:15] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 240 seconds)
- # [10:16] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:95d1:6a72:345f:c6ab) (Ping timeout: 240 seconds)
- # [10:27] * Parts: a-ja (~Instantbi@70.230.148.198)
- # [10:32] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
- # [10:32] * Quits: Ms2ger (~Ms2ger@91.182.58.217) (Ping timeout: 255 seconds)
- # [10:35] * Joins: xiinotulp (~plutoniix@node-18rc.pool-101-109.dynamic.totbb.net)
- # [10:36] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [10:36] * Joins: hsivonen (~hsivonen@fsf/member/hsivonen)
- # [10:37] <hsivonen> oh the annoyance of running irssi and bugzilla on the same host an a naive bugzilla installation being so prone to DoS
- # [10:38] * Quits: plutoniix (~plutoniix@node-11fz.pool-180-180.dynamic.totbb.net) (Ping timeout: 250 seconds)
- # [10:40] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [10:44] * Joins: Ms2ger (~Ms2ger@vpnc191.ugent.be)
- # [10:50] * Joins: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
- # [10:53] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [10:55] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 245 seconds)
- # [10:56] * xiinotulp is now known as plutoniix
- # [11:00] * Joins: IZh (~IZh@213.33.220.118)
- # [11:02] <zcorpan> woah https://www.w3.org/Bugs/Public/show_bug.cgi?id=25478#c15
- # [11:02] <zcorpan> MikeSmith: are you ok?
- # [11:05] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [11:07] <MikeSmith> zcorpan: yeah. sorry about that comment
- # [11:09] <zcorpan> if you refuse to implement the change in v.nu that seems like a useful data point, but it was a bit hidden behind the rage :-P
- # [11:09] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Ping timeout: 252 seconds)
- # [11:11] <zcorpan> what happened with http://static.guim.co.uk/sys-images/Guardian/About/General/2011/7/14/1310661708437/LulzSec-logo-001.jpg ? :-)
- # [11:18] <MikeSmith> zcorpan: point taken :)
- # [11:20] <MikeSmith> zcorpan: I was experimenting with trying out my alternate "rage persona"
- # [11:20] <zcorpan> MikeSmith: ok, that's cool
- # [11:20] <zcorpan> i'm not complaining i was just surprised
- # [11:21] <MikeSmith> but I think we can agree the experiment failed
- # [11:23] <tobie> darobin not being around, would appreciate review/comments for my pull request adding MapClass support to the WebIDL parser: https://github.com/darobin/webidl2.js/pull/10. Anyone?
- # [11:24] * Joins: annevk (~annevk@207.218.72.65)
- # [11:25] <MikeSmith> tobie: I can look at it in 4 hours or so, if nobody gets to it first. On my mobile now
- # [11:26] <tobie> ^ ty MikeSmith
- # [11:26] * Joins: Lachy (~Lachy@213.166.174.2)
- # [11:31] <annevk> mathiasbynens: not sure APIs for encodings are suitable for base64
- # [11:36] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [11:38] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-fpfxlxpcuenwfrbz)
- # [11:41] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [11:41] * Quits: Ms2ger (~Ms2ger@vpnc191.ugent.be) (Ping timeout: 255 seconds)
- # [11:43] <JonathanNeal> Hello!
- # [11:46] <mathiasbynens> annevk: i meant separate APIs
- # [11:47] <mathiasbynens> one like atob/btoa for base64{en,de}coding ASCII or octets in “binary strings”
- # [11:47] <mathiasbynens> and then something like TextEncoder to turn any plain Unicode string into such “binary strings”
- # [11:47] <mathiasbynens> or does that not make sense?
- # [12:00] <annevk> mathiasbynens: does
- # [12:01] <annevk> mathiasbynens: well, TextEncoder is scalar values to bytes
- # [12:02] <mathiasbynens> annevk: did you see http://esdiscuss.org/topic/native-base64-utility-methods?
- # [12:02] <annevk> mathiasbynens: yes
- # [12:02] * Joins: satazor_ (~satazor@bl16-83-211.dsl.telepac.pt)
- # [12:03] <mathiasbynens> the counter-argument there seems to be that base64('any string') should work
- # [12:03] <mathiasbynens> but if you encode the string first, atob/btoa seem sufficient
- # [12:03] <annevk> atob and btoa are not going anywhere
- # [12:04] <annevk> mathiasbynens: I don't understand "(but it requires ArrayBuffer / Uint8Array)"
- # [12:06] <mathiasbynens> annevk: good point, that’s not an issue at all (i didn’t realize these things were now defined in the ES draft rather than a separate document)
- # [12:06] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Ping timeout: 258 seconds)
- # [12:09] * Joins: smaug____ (~chatzilla@cs78246079.pp.htv.fi)
- # [12:14] <MikeSmith> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24382#c22 is interesting
- # [12:28] <tobie> MikeSmith: yeah, that lets broadcasters easily add targeted HTML overlays and the like. Good thing I don't watch TV.
- # [12:35] * Joins: davve (~user@83.218.67.123)
- # [12:37] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [12:39] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
- # [12:41] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
- # [12:41] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [12:44] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 276 seconds)
- # [12:48] * Joins: hober2 (~ted@unaffiliated/hober)
- # [12:49] * Joins: nephyrin` (~neph@corp.mtv2.mozilla.com)
- # [12:50] * Joins: hendry_ (~hendry@sg.webconverger.com)
- # [12:50] * Joins: Philip`_ (~philip@compass.zaynar.co.uk)
- # [12:51] * Joins: edsu_ (~edsu@li144-162.members.linode.com)
- # [12:51] * Quits: edsu_ (~edsu@li144-162.members.linode.com) (Changing host)
- # [12:51] * Joins: edsu_ (~edsu@pdpc/supporter/active/edsu)
- # [12:53] * Joins: ambv_ (~ambv@206.108.217.134)
- # [12:55] * Joins: Ms2ger (~Ms2ger@nata241.ugent.be)
- # [12:55] * Quits: Philip` (~philip@compass.zaynar.co.uk) (Ping timeout: 252 seconds)
- # [12:55] * Quits: hendry (~hendry@sg.webconverger.com) (Ping timeout: 252 seconds)
- # [12:55] * Quits: ambv (~ambv@206.108.217.134) (Ping timeout: 252 seconds)
- # [12:55] * Quits: edsu (~edsu@pdpc/supporter/active/edsu) (Ping timeout: 252 seconds)
- # [12:55] * Quits: hober (~ted@unaffiliated/hober) (Ping timeout: 252 seconds)
- # [12:55] * Quits: nephyrin (~neph@corp.mtv2.mozilla.com) (Ping timeout: 252 seconds)
- # [12:57] * Quits: tav (~tav`@host109-154-0-7.range109-154.btcentralplus.com) (Quit: tav)
- # [13:02] * Joins: MutantMahesh (75f1720a@gateway/web/freenode/ip.117.241.114.10)
- # [13:02] * Quits: MutantMahesh (75f1720a@gateway/web/freenode/ip.117.241.114.10) (Changing host)
- # [13:02] * Joins: MutantMahesh (75f1720a@unaffiliated/msankhala)
- # [13:02] * Quits: MutantMahesh (75f1720a@unaffiliated/msankhala) (Changing host)
- # [13:02] * Joins: MutantMahesh (75f1720a@gateway/web/freenode/ip.117.241.114.10)
- # [13:03] * Joins: paul_irish_ (~paul_iris@ve.hsh6wjwx.vesrv.com)
- # [13:12] * Quits: ricea (~ricea@2401:fa00:4:1000:b6b5:2fff:feca:47f8) (Quit: Leaving.)
- # [13:15] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:2004:64cb:45d8:64d2)
- # [13:15] * Joins: Ms2ger` (~Ms2ger@nata241.ugent.be)
- # [13:16] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:2004:64cb:45d8:64d2) (Remote host closed the connection)
- # [13:23] * Quits: Ms2ger (~Ms2ger@nata241.ugent.be) (*.net *.split)
- # [13:23] * Quits: paul_irish (~paul_iris@ve.hsh6wjwx.vesrv.com) (*.net *.split)
- # [13:23] * Quits: webben (~benjamin@198.61.227.102) (*.net *.split)
- # [13:23] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-comlzhbznraoyjcf) (*.net *.split)
- # [13:33] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
- # [13:33] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [13:35] * Quits: satazor_ (~satazor@bl16-83-211.dsl.telepac.pt) (Remote host closed the connection)
- # [13:38] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [13:38] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 276 seconds)
- # [13:40] * Quits: smaug____ (~chatzilla@cs78246079.pp.htv.fi) (Ping timeout: 252 seconds)
- # [13:42] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [13:43] * Quits: Ms2ger` (~Ms2ger@nata241.ugent.be) (Ping timeout: 252 seconds)
- # [13:43] * Joins: Kolombiken (~Adium@94.137.124.2)
- # [13:43] * Quits: Kolombiken (~Adium@94.137.124.2) (Remote host closed the connection)
- # [13:43] * Joins: Kolombiken (~Adium@gateway.creuna.se)
- # [13:48] * Joins: webben (~benjamin@198.61.227.102)
- # [13:48] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-comlzhbznraoyjcf)
- # [13:52] * Quits: Gege (gege@future.deferred.io) (Remote host closed the connection)
- # [13:54] * Joins: satazor (~satazor@bl16-83-211.dsl.telepac.pt)
- # [13:57] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [14:04] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-qfrafjcdfdgqqpto) (*.net *.split)
- # [14:04] * Quits: dglazkov (sid4270@gateway/web/irccloud.com/x-nugwvcamhzsdxsbq) (*.net *.split)
- # [14:04] * Quits: cfq (sid18398@gateway/web/irccloud.com/x-tguujwjqdgdymnxi) (*.net *.split)
- # [14:04] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-eigunnnddotemzkd) (*.net *.split)
- # [14:07] * Joins: Ms2ger` (~Ms2ger@vpnj146.ugent.be)
- # [14:11] * Quits: satazor (~satazor@bl16-83-211.dsl.telepac.pt) (Remote host closed the connection)
- # [14:18] * Joins: morrita_ (uid16889@gateway/web/irccloud.com/x-qfrafjcdfdgqqpto)
- # [14:18] * Joins: dglazkov (sid4270@gateway/web/irccloud.com/x-nugwvcamhzsdxsbq)
- # [14:18] * Joins: cfq (sid18398@gateway/web/irccloud.com/x-tguujwjqdgdymnxi)
- # [14:18] * Joins: JonathanNeal (sid5831@gateway/web/irccloud.com/x-eigunnnddotemzkd)
- # [14:26] * Joins: Gege (gege@future.deferred.io)
- # [14:28] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
- # [14:28] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Read error: Connection reset by peer)
- # [14:28] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [14:32] * Quits: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod) (Ping timeout: 265 seconds)
- # [14:34] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
- # [14:38] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [14:43] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [14:58] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 240 seconds)
- # [15:06] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
- # [15:06] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-fpfxlxpcuenwfrbz) (Quit: Connection closed for inactivity)
- # [15:08] * Joins: cheron (~cheron@unaffiliated/cheron)
- # [15:12] <zcorpan> Hixie: would it be worthwhile to set up a hook for regenning the spec and committing in svn whenever my `source` changes?
- # [15:17] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
- # [15:21] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Ping timeout: 240 seconds)
- # [15:26] * Quits: MutantMahesh (75f1720a@gateway/web/freenode/ip.117.241.114.10) (Ping timeout: 240 seconds)
- # [15:29] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
- # [15:29] * Joins: weinig (~weinig@98.234.191.242)
- # [15:34] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-wpebppzsvcrpfujb)
- # [15:37] * Joins: newtron_ (~newtron@199.71.174.203)
- # [15:39] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [15:40] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
- # [15:43] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [15:44] * Joins: satazor (~satazor@bl16-83-211.dsl.telepac.pt)
- # [15:47] * Joins: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt)
- # [15:47] * Joins: jonathanmarvens (~jonathanm@2601:6:7700:929:d41a:2191:bd5a:534)
- # [15:48] * Quits: satazor (~satazor@bl16-83-211.dsl.telepac.pt) (Ping timeout: 240 seconds)
- # [15:49] * Quits: jonathanmarvens (~jonathanm@2601:6:7700:929:d41a:2191:bd5a:534) (Read error: Connection reset by peer)
- # [15:49] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Ping timeout: 250 seconds)
- # [15:51] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
- # [15:51] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
- # [15:51] <annevk> Where did zcorpan go?
- # [15:54] * Quits: jst (~quassel@198.199.94.175) (Ping timeout: 252 seconds)
- # [15:54] * Joins: TallTed (~Thud@63.119.36.36)
- # [15:55] <annevk> Domenic_: what was the proper way to talk again about an initial property value in ECMAScript
- # [15:56] <annevk> Domenic_: e.g. you want to invoke the Event() constructor, but not one overwritten by a page
- # [15:57] * Quits: niloy (~niloy@106.221.194.255) (Ping timeout: 255 seconds)
- # [16:01] * Quits: zdobersek (~zan@109.201.154.169) (Quit: Leaving.)
- # [16:04] * Joins: MutantMahesh (b4d7bfb6@gateway/web/freenode/ip.180.215.191.182)
- # [16:04] * Quits: MutantMahesh (b4d7bfb6@gateway/web/freenode/ip.180.215.191.182) (Changing host)
- # [16:04] * Joins: MutantMahesh (b4d7bfb6@unaffiliated/msankhala)
- # [16:04] * Quits: MutantMahesh (b4d7bfb6@unaffiliated/msankhala) (Changing host)
- # [16:04] * Joins: MutantMahesh (b4d7bfb6@gateway/web/freenode/ip.180.215.191.182)
- # [16:07] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
- # [16:10] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [16:13] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
- # [16:16] * Quits: MutantMahesh (b4d7bfb6@gateway/web/freenode/ip.180.215.191.182) (Quit: Page closed)
- # [16:22] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
- # [16:23] * Joins: jst (~quassel@198.199.94.175)
- # [16:28] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 255 seconds)
- # [16:30] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [16:30] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
- # [16:32] * Quits: morbidlyobese (~morbidlyo@gateway/tor-sasl/morbidlyobese) (Quit: morbidlyobese)
- # [16:34] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
- # [16:36] * Quits: weinig (~weinig@98.234.191.242) (Quit: weinig)
- # [16:36] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 258 seconds)
- # [16:39] * Joins: BigBangUDR (~Thunderbi@123.239.72.121)
- # [16:39] <Domenic_> annevk: well, the "proper" (Allen-style) way is to define a per-realm %Event% intrinsic and refer to that instead. But I think "using the initial value of the Event constructor for this realm [or top-level browsing context]" seems good.
- # [16:39] * Joins: smaug____ (~chatzilla@cs78246079.pp.htv.fi)
- # [16:40] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
- # [16:40] <Domenic_> The intrinsics approach is kind of nice for implementers, I would imagine, as it gives them a clear list of things that need to be saved away for use later.
- # [16:40] <annevk> heh, one day once IDL is maintained we should just make it have a good <dfn> for that
- # [16:40] <Domenic_> I'll add it to the jsidl issue just so I don't forget it...
- # [16:41] * Quits: BigBangUDR (~Thunderbi@123.239.72.121) (Client Quit)
- # [16:43] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [16:45] * Quits: CvP (~CvP@27.147.198.50) (Disconnected by services)
- # [16:45] * Joins: xCG (~CvP@27.147.199.131)
- # [16:46] * xCG is now known as CvP
- # [16:49] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
- # [16:52] <annevk> Domenic_: cool
- # [16:57] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
- # [16:58] * Joins: tav (~tav`@host109-154-0-7.range109-154.btcentralplus.com)
- # [17:03] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
- # [17:07] * Quits: mven__ (~textual@ip68-104-38-84.lv.lv.cox.net) (Ping timeout: 250 seconds)
- # [17:08] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 276 seconds)
- # [17:09] * Quits: annevk (~annevk@207.218.72.65) (Remote host closed the connection)
- # [17:10] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
- # [17:11] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
- # [17:12] * Joins: mpt (~mpt@nat/canonical/x-xyhftwsfgdvfgdbo)
- # [17:12] * Quits: mpt (~mpt@nat/canonical/x-xyhftwsfgdvfgdbo) (Changing host)
- # [17:12] * Joins: mpt (~mpt@canonical/mpt)
- # [17:13] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
- # [17:15] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
- # [17:15] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [17:17] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
- # [17:20] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
- # [17:21] * Joins: arunranga (~otherarun@static-71-249-129-230.nycmny.east.verizon.net)
- # [17:21] * Joins: Jarrod_ (~Jarrod_@pdpc/supporter/active/jarrod)
- # [17:21] * Quits: Ms2ger` (~Ms2ger@vpnj146.ugent.be) (Ping timeout: 276 seconds)
- # [17:22] <JonathanNeal> Any movement happening on query and queryAll? http://dom.spec.whatwg.org/#dom-parentnode-query
- # [17:23] <Domenic_> Implementations need to support ES6 subclassing first
- # [17:23] <Domenic_> BUT I think they could just return arrays for now
- # [17:24] <Domenic_> Also: https://github.com/barberboy/dom-elements
- # [17:25] <arunranga> Hi Domenic_ :) In your opinion, in lieu of AbortableProgressPromise for operations like move, what should be used? http://w3c.github.io/filesystem-api/Overview.html#the-directory-interface
- # [17:26] <Domenic_> arunranga: just Promise seems fine...
- # [17:26] <arunranga> That’s what I thought.
- # [17:26] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
- # [17:27] <JonathanNeal> Domenic_: what do you mean by subclassing? Are you referring to the live-ness of query/All?
- # [17:27] <zewt> mathiasbynens: there was discussion already for using TextEncoder/TextDecoder for base64 on the list, seems like the right thing to do
- # [17:27] <Domenic_> JonathanNeal: no, not at all. I mean support for subclassing implementation-provided classes. In particular, ES6 Symbol.create support is necessary.
- # [17:28] <arunranga> Next question, and sorry if I’ve missed past communication about this, but is https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm the new-and-better/more recent flavor of https://github.com/whatwg/streams ?
- # [17:28] <JonathanNeal> Domenic_: wow, no idea what those are. Things to learn.
- # [17:29] <Domenic_> It's in my blog post queue... Symbol.create and the subclassable built-ins it enables are my favorite thing, but it needs more publicity.
- # [17:29] <Domenic_> arunranga: nope, other way around.
- # [17:29] <arunranga> Domenic_ ahh, ok. The “date” on the editor’s draft at the w3.org URL is probably just auto-updated then.
- # [17:30] <Domenic_> arunranga: oh interesting
- # [17:30] <Domenic_> yeah I guess so, huh. https://dvcs.w3.org/hg/streams-api/
- # [17:30] <arunranga> I think respec.js has a date updater, and this makes it look like the w3.org spec is updated as of today-ish.
- # [17:30] * Quits: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
- # [17:31] <arunranga> OK well, I’m glad I asked :-)
- # [17:31] <Domenic_> :)
- # [17:31] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
- # [17:34] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
- # [17:34] * Quits: arunranga (~otherarun@static-71-249-129-230.nycmny.east.verizon.net) (Quit: arunranga)
- # [17:36] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Ping timeout: 264 seconds)
- # [17:36] * Quits: IZh (~IZh@213.33.220.118) (Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26/20140428215651])
- # [17:37] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
- # [17:45] * Joins: lmclister (~lmclister@192.150.10.210)
- # [17:51] * Joins: ehsan (~ehsan@66.207.208.102)
- # [17:53] * Quits: Krinkle|detached (~Krinkle@wikimedia/Krinkle) (Quit: Bounce bounce - Powered by ZNC <http://znc.in>)
- # [17:54] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [17:57] * Joins: weinig (~weinig@17.202.50.223)
- # [17:58] * Joins: bkardell__ (uid10373@gateway/web/irccloud.com/x-oagngheetwblnepl)
- # [18:01] <mathiasbynens> zewt: “the list” meaning es-discuss?
- # [18:02] * Joins: Guest91747 (~Krinkle@ec2-50-112-50-28.us-west-2.compute.amazonaws.com)
- # [18:06] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
- # [18:06] * Joins: jsbell (jsbell@nat/google/x-jjofvxxcwunxguky)
- # [18:13] * Joins: Maurice` (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
- # [18:16] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [18:20] * Joins: annevk (~annevk@207.218.72.65)
- # [18:20] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
- # [18:24] * Quits: annevk (~annevk@207.218.72.65) (Ping timeout: 245 seconds)
- # [18:27] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
- # [18:27] * Joins: mven_ (~textual@169.241.49.240)
- # [18:27] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
- # [18:29] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
- # [18:29] <tyoshino____> Right. Sorry for confusing. W3C version is suspended. I'm a co-editor for it. We are working together with Domenic_ at WHATWG github now.
- # [18:30] <tyoshino____> re: Streams
- # [18:31] * Joins: Ms2ger` (~Ms2ger@91.182.58.217)
- # [18:33] * Joins: llkats (~llkats@h-64-236-138-2.aoltw.net)
- # [18:34] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
- # [18:38] * Joins: marcosc (~marcosc@66.207.208.102)
- # [18:40] * Joins: satazor (~satazor@bl16-83-211.dsl.telepac.pt)
- # [18:41] * Joins: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net)
- # [18:42] * Joins: ap (~ap@2620:149:4:304:d549:5595:872:aaa7)
- # [18:44] * Quits: satazor (~satazor@bl16-83-211.dsl.telepac.pt) (Ping timeout: 240 seconds)
- # [18:47] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
- # [18:51] * Quits: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) (Ping timeout: 245 seconds)
- # [18:56] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-wpebppzsvcrpfujb)
- # [18:58] * Joins: mven__ (~textual@169.241.49.240)
- # [18:59] * Quits: mven_ (~textual@169.241.49.240) (Read error: Connection reset by peer)
- # [19:00] <zewt> mathiasbynens: whatwg or webapps
- # [19:03] * hober2 is now known as hober
- # [19:05] * Joins: arunranga (~otherarun@cpe-69-203-2-134.nyc.res.rr.com)
- # [19:06] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
- # [19:10] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Ping timeout: 240 seconds)
- # [19:13] * Joins: weinig_ (~weinig@17.114.216.123)
- # [19:15] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
- # [19:16] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [19:17] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [19:19] <Hixie> zcorpan: the problem with such a hook is that it would jam in my half-complete changes as well :-)
- # [19:19] <Hixie> zcorpan: however if you ever make changes that aren't reflected within 24 hours, ping me
- # [19:19] * Joins: BigBangUDR (~Thunderbi@115.245.26.101)
- # [19:21] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 264 seconds)
- # [19:21] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 276 seconds)
- # [19:22] * Joins: IZh (~IZh@95.31.44.172)
- # [19:22] * Joins: mven_ (~textual@169.241.49.240)
- # [19:22] * Quits: mven_ (~textual@169.241.49.240) (Max SendQ exceeded)
- # [19:24] * Joins: Areks (~Areks@95-26-45-140.broadband.corbina.ru)
- # [19:24] * Quits: mven__ (~textual@169.241.49.240) (Read error: Connection reset by peer)
- # [19:26] * Joins: mven_ (~textual@169.241.49.240)
- # [19:27] * Joins: newtron_work (~newtron@199.71.174.204)
- # [19:27] <jgraham> Hixie: Surely the solution to that is to have your thing create a copy of his input, and his thing use the last copy rather than the current file
- # [19:28] <jgraham> Er
- # [19:28] <jgraham> Your thing create a copy of your input
- # [19:28] <Hixie> it does.
- # [19:29] <Hixie> but sometimes i do this:
- # [19:29] <Hixie> 1. create edit
- # [19:29] <Hixie> 2. regen
- # [19:29] <Hixie> 3. edit the edit, but it's in a poorer state now (e.g. bad markup)
- # [19:29] <Hixie> 4. go to sleep
- # [19:29] * Quits: newtron_work (~newtron@199.71.174.204) (Remote host closed the connection)
- # [19:30] <Hixie> if zcorpan triggers a thing then, then you either blow away my step 1 changes, or inject my step 3 changes
- # [19:30] <Hixie> i guess i could make a copy of the copy when i regen
- # [19:30] * Joins: newtron_work (~newtron@199.71.174.204)
- # [19:30] <Hixie> i'll have to add something like that when i get to that part of my new pipeline
- # [19:30] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
- # [19:30] <Hixie> right now i'm still just building the HTML parser :-)
- # [19:31] <Hixie> (only doing it in my free time, so...)
- # [19:31] * Quits: newtron_ (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
- # [19:31] * Quits: mven_ (~textual@169.241.49.240) (Ping timeout: 255 seconds)
- # [19:31] * Joins: newtron_ (~newtron@199.71.174.204)
- # [19:32] <Domenic_> rebuilding Git on top of svn, one step at a time.
- # [19:33] <jgraham> Yeah, it does seem like yor problem would be solved by correct use of a VCS
- # [19:34] <jgraham> But in the absence of that, I don't understand why making a copy duing step 2 wouldn't work
- # [19:34] <jgraham> If zcorpan caused a new build it would be based on the step 2 copy
- # [19:34] * Quits: newtron_work (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
- # [19:35] <SamB> Hixie: What, no test instance or anything?
- # [19:35] <Hixie> i like to live on the edge, man!
- # [19:35] * Quits: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net) (Quit: Textual IRC Client: www.textualapp.com)
- # [19:36] <Hixie> jgraham: yeah, it could work
- # [19:37] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [19:37] * ambv_ is now known as ambv
- # [19:41] * Joins: benv (~benv@38.104.194.126)
- # [19:42] <Hixie> anyone know Frederik S (fs@opera.com)'s last name?
- # [19:42] <Ms2ger`> "W3C Invites Implementations of W3C DOM4"
- # [19:43] <Ms2ger`> Hixie, presumably "S"
- # [19:44] <Hixie> well that's always possible i guess
- # [19:44] <mathiasbynens> Hixie: Fredrik Söderquist
- # [19:45] * Joins: fredy_ (~fredy@snf-8914.vm.okeanos.grnet.gr)
- # [19:46] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
- # [19:46] <Hixie> thanks!
- # [19:47] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Ping timeout: 240 seconds)
- # [19:47] * Quits: BigBangUDR (~Thunderbi@115.245.26.101) (Quit: BigBangUDR)
- # [19:47] * Quits: newtron_ (~newtron@199.71.174.204) (Remote host closed the connection)
- # [19:48] * Joins: newtron_ (~newtron@199.71.174.204)
- # [19:49] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
- # [19:49] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
- # [19:50] * Joins: newtron_work (~newtron@199.71.174.204)
- # [19:50] * Quits: newtron_work (~newtron@199.71.174.204) (Remote host closed the connection)
- # [19:50] * Joins: newtron_work (~newtron@199.71.174.203)
- # [19:50] * fredy_ is now known as fredy
- # [19:52] * Quits: newtron_ (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
- # [19:54] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
- # [19:54] <Hixie> MikeSmith: you around?
- # [19:57] * Joins: mven_ (~textual@169.241.49.240)
- # [19:57] * Quits: mven_ (~textual@169.241.49.240) (Max SendQ exceeded)
- # [19:57] * Joins: zdobersek (~zan@5.153.234.90)
- # [19:59] * Quits: weinig_ (~weinig@17.114.216.123) (Quit: weinig_)
- # [20:02] * Joins: weinig_ (~weinig@17.114.216.123)
- # [20:02] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
- # [20:04] * Joins: BigBangUDR (~Thunderbi@101.56.188.140)
- # [20:04] * Quits: BigBangUDR (~Thunderbi@101.56.188.140) (Client Quit)
- # [20:08] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 258 seconds)
- # [20:08] * Joins: mpt (~mpt@canonical/mpt)
- # [20:08] * Joins: newtron_ (~newtron@199.71.174.204)
- # [20:11] * Quits: newtron_work (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
- # [20:12] * Joins: ehsan_ (~ehsan@66.207.208.102)
- # [20:14] * Quits: Ms2ger` (~Ms2ger@91.182.58.217) (Ping timeout: 258 seconds)
- # [20:14] * Quits: ehsan (~ehsan@66.207.208.102) (Ping timeout: 258 seconds)
- # [20:15] * Joins: Ms2ger` (~Ms2ger@91.182.58.217)
- # [20:15] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 258 seconds)
- # [20:15] * Joins: hendry (~hendry@sg.webconverger.com)
- # [20:17] * Quits: hendry_ (~hendry@sg.webconverger.com) (Ping timeout: 258 seconds)
- # [20:17] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [20:20] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
- # [20:20] * Quits: bkardell__ (uid10373@gateway/web/irccloud.com/x-oagngheetwblnepl) (Quit: Connection closed for inactivity)
- # [20:22] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
- # [20:25] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
- # [20:28] * Joins: sankha93 (~sankha93@dslb-188-096-090-243.pools.arcor-ip.net)
- # [20:28] * Quits: sankha93 (~sankha93@dslb-188-096-090-243.pools.arcor-ip.net) (Changing host)
- # [20:28] * Joins: sankha93 (~sankha93@fsf/emeritus/sankha93)
- # [20:28] * Quits: weinig_ (~weinig@17.114.216.123) (Quit: weinig_)
- # [20:28] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
- # [20:33] * Joins: KevinMarks (~KevinMark@sjspeed.wiline.com)
- # [20:33] <TabAtkins> Hixie: Yeah, drop @global. (I saw you already have, just supporting the decision.) If we need something like it, we'll define it in Scoping ourselves.
- # [20:34] <Hixie> k. thanks.
- # [20:41] * Joins: weinig_ (~weinig@17.114.216.123)
- # [20:41] * Joins: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net)
- # [20:41] * Quits: newtron_ (~newtron@199.71.174.204) (Remote host closed the connection)
- # [20:42] * Joins: newtron_ (~newtron@199.71.174.203)
- # [20:42] * Joins: jonathanmarvens (~jonathanm@199.47.79.34)
- # [20:45] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-vvvsbyhtynlfgjpk)
- # [20:50] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Quit: jeffreyatw)
- # [20:51] * Joins: weinig__ (~weinig@17.202.49.35)
- # [20:51] * Quits: weinig_ (~weinig@17.114.216.123) (Ping timeout: 252 seconds)
- # [20:51] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Ping timeout: 240 seconds)
- # [20:55] <Hixie> uh
- # [20:55] <Hixie> can someone come up with a demo that shows firefox setting FocusEvent.relatedTarget to something other than 'null'?
- # [20:57] * Joins: Smylers (~smylers@2001:a60:102d:b701:51ea:561f:f88e:26c1)
- # [20:58] <Ms2ger`> Hixie, initFocusEvent? :)
- # [20:59] * Quits: jonathanmarvens (~jonathanm@199.47.79.34) (Remote host closed the connection)
- # [21:01] * Joins: othermaciej (~mjs@17.114.219.231)
- # [21:02] * Joins: mven_ (~textual@169.241.49.240)
- # [21:02] <Ms2ger`> But smaug____ can probably find a case
- # [21:05] <tobie> Is [Constructor((Foo or [EnsureUTF16] DOMString))] valid WebIDL. I think not from reading the spec. Can someone confirm? http://heycam.github.io/webidl/#EnsureUTF16
- # [21:07] <smaug____> Hixie: focusin/focusout events
- # [21:07] <Hixie> smaug____: wow, only for those? not focus/blur?
- # [21:07] * Quits: mven_ (~textual@169.241.49.240) (Ping timeout: 250 seconds)
- # [21:08] <smaug____> er
- # [21:08] <smaug____> hmm
- # [21:08] <smaug____> sorry
- # [21:08] <smaug____> Hixie: in FF focusin/out aren't implemented, and so aren't .relatedTarget setting
- # [21:09] * smaug____ looks at the code still
- # [21:10] <Hixie> i haven't specced focusin/focusout either
- # [21:10] <Ms2ger`> tobie, isn't, you forgot the argument name </unhelpful>
- # [21:10] <smaug____> well, some of it is in D3E
- # [21:11] <smaug____> Hixie: but yeah, FF doesn't set .relatedTarget to anything useful yet in case of focusevent
- # [21:11] <smaug____> known bug
- # [21:11] <tobie> Ms2ger`: might be helpful, actually. Let me check.
- # [21:12] * Joins: rektide (~rektide@eldergods.com)
- # [21:14] * Quits: Smylers (~smylers@2001:a60:102d:b701:51ea:561f:f88e:26c1) (Ping timeout: 245 seconds)
- # [21:14] * Joins: Smylers (~smylers@2001:a60:102d:b701:51ea:561f:f88e:26c1)
- # [21:16] <tobie> Ms2ger`: so no, that's actually not the issue.
- # [21:16] * Joins: jonathanmarvens (~jonathanm@199.47.79.34)
- # [21:16] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-vvvsbyhtynlfgjpk)
- # [21:16] * Quits: arunranga (~otherarun@cpe-69-203-2-134.nyc.res.rr.com) (Quit: arunranga)
- # [21:17] <tobie> So is the following WebIDL construct valid? [Constructor((Foo or [EnsureUTF16] DOMString) str)]
- # [21:18] * Joins: arunranga (~otherarun@cpe-69-203-2-134.nyc.res.rr.com)
- # [21:18] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [21:18] <Ms2ger`> I suspect not
- # [21:19] * Quits: jonathanmarvens (~jonathanm@199.47.79.34) (Remote host closed the connection)
- # [21:19] <Domenic_> JakeA: for service worker caches, can you explain why there are so many overloads? Overloads always scare me.
- # [21:20] <JakeA> Domenic_: can only think of URLs vs requests off the top of my head
- # [21:20] <tobie> JakeA:
- # [21:21] <JakeA> But have been drinking so may be forgetting others
- # [21:21] <tobie> ^ sorry, silly irc client.
- # [21:21] <Hixie> smaug____: fascinating
- # [21:22] <JakeA> tobie: s'ok, made me feel popular
- # [21:22] * Hixie is trying to spec relatedTarget, but it's not clear what exactly it should point to
- # [21:22] <tobie> JakeA: having issues with an probably invalid WebIDL construct in SW
- # [21:22] <smaug____> Hixie: that part is something D3E tries to spec, to some extent
- # [21:23] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 276 seconds)
- # [21:24] <tobie> JakeA: turns out it's in the cache Domenic_ was just mentioning: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache
- # [21:24] <Hixie> smaug____: the extent of their speccing relatedTarget durin 'blur' is "event target receiving focus"
- # [21:24] <Hixie> smaug____: which is great except with iframe and dialog and so on there could be multiple elements in multiple browsing contexts :-)
- # [21:24] <Hixie> smaug____: so... not so helpful in practice
- # [21:25] <JakeA> tobie: hmm, will need to check to see if that's up to date, proposed a lot of change to that API recently
- # [21:25] <smaug____> yup, that is still unclear
- # [21:25] <smaug____> must not reveal nodes from other domains
- # [21:25] <tobie> JakeA: [EnsureUTF16] can be applied to an argument apparently not to a type.
- # [21:25] * smaug____ wonders if webkit or blink does that
- # [21:26] <tobie> JakeA: (if I read the WebIDL spec correctly, which frankly, would surprise me.)
- # [21:26] <smaug____> given that they don't have any security checks there based on the JS wrappers
- # [21:28] * Joins: jonathanmarvens (~jonathanm@199.47.79.34)
- # [21:29] <Hixie> smaug____: they seem to only reveal elements from the same document
- # [21:29] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
- # [21:30] <Hixie> e.g. the blur when you blur an element to focus one outside an iframe doesn't have a relatedTarget
- # [21:30] <Hixie> i wonder what to do with the one fired at non-elements
- # [21:31] <Hixie> make it Event, like in webkit? make it FocusEvent with no relatedTarget?
- # [21:31] <Hixie> as in, null
- # [21:31] <Hixie> what if you move focus from one dialog to another... there's two focus/blur pairs, one for the control in the first dialog and the control in the second dialog, and one for the dialogs
- # [21:31] <Hixie> should the relatedTarget of the controls be null? and the relatedTarget of the dialogs be the dialogs?
- # [21:32] <Hixie> what's the use case for relatedTarget?
- # [21:32] <Domenic_> JakeA: ah you're right it got better since I last looked. Still don't quite understand how such different objects can be used. Is it just a convenience for cache.whatever(req.url, ...)?
- # [21:34] * Joins: newtron_work (~newtron@199.71.174.204)
- # [21:34] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 264 seconds)
- # [21:34] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [21:35] <smaug____> Hixie: use case is to know where the focus is moving from/to
- # [21:35] <smaug____> use case is fine
- # [21:36] <zewt> may be more useful to know from/to when you're eg. an event listener on document rather than the control itself, and you want to do an animation from the old thing to the new thing or something like that
- # [21:37] * Quits: newtron_ (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
- # [21:37] * Joins: rniwa (~rniwa@17.202.43.222)
- # [21:38] * Quits: newtron_work (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
- # [21:38] * Quits: llkats (~llkats@h-64-236-138-2.aoltw.net) (Remote host closed the connection)
- # [21:38] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
- # [21:39] * Quits: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [21:42] <Hixie> smaug____: that's what it gives you, but i mean the use case. Like, why would you use that information.
- # [21:43] <JakeA> Domenic_: a url will be converted to a basic GET request. The defaults are defined by the Request constructor. Feedback on this API is very welcome though!
- # [21:43] <Hixie> zewt: hmm, animating from one to the other is an interesting idea
- # [21:43] <Hixie> zewt: though you could do that by just listening to focus events and tracking where you last went
- # [21:43] <zewt> contrived, not sure i've needed to use relatedTarget myself
- # [21:43] * Quits: weinig__ (~weinig@17.202.49.35) (Quit: weinig__)
- # [21:43] <Hixie> in the case of a dialog you'd probably not want to animate away from one control to the other when changing dialogs
- # [21:44] <Hixie> you'd presumably want a per-dialog animation state
- # [21:44] <zewt> what if nothing is focused for a while, then the user focuses something, and you only want to animate for a transition, and not do the animation from something that was focused earlier
- # [21:44] <Hixie> so that argues for relatedTarget staying within its most local scope
- # [21:44] <Hixie> zewt: there's always _something_ focused
- # [21:44] <zewt> you'd need to add a timer to try to guess whether it was a direct transition or if there was some delay, which seems to be the main thing relatedTarget gives you
- # [21:44] <Domenic_> JakeA: hmm well I trust you guys have found it important to have a convenient way of doing that, i.e. the convenience of using url instead of `new Request({ url: ... })` outweighs the implicitness.
- # [21:45] <Domenic_> JakeA: but I like that there is such an equivalence, i.e. Requests are the "real" keys and URLs are just sugar; I was afraid that caches had two kinds of keys
- # [21:47] <zewt> Hixie: it seems like there's nothing focused if I click on text
- # [21:47] <Hixie> the browsing context is focused, at least
- # [21:48] <zewt> (the window has a focus message, but window focus/blur seems independent of element focus/blur)
- # [21:48] <zewt> (which is confusing)
- # [21:48] <Hixie> it's all the same algorithm per the spec these days
- # [21:48] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#focus-update-steps
- # [21:48] <zewt> it looks distinct from testing in chrome, at least
- # [21:48] <zewt> that is, i get focus/blur messages for window, and focus/blur messages for my <input type=text>, and i can get focus for both at the same time
- # [21:49] <Hixie> yeah, it's a hieararchy of focus
- # [21:49] <Hixie> hierarchy even
- # [21:50] * Quits: arunranga (~otherarun@cpe-69-203-2-134.nyc.res.rr.com) (Quit: arunranga)
- # [21:50] <zewt> i guess i can see that
- # [21:50] <zewt> that means that if you were trying to track focus yourself (to emulate relatedTarget), you'd need to maintain a stack, which would be brittle
- # [21:51] * Joins: llkats (~llkats@h-64-236-138-2.aoltw.net)
- # [21:51] <Hixie> maintaining it yourself would be a huge pain
- # [21:51] <Hixie> since it can cross iframe boundaries and so on
- # [21:52] <Hixie> ok i think the logical thing to do is to only set relatedTarget for the outermost thing that receives the focus/blur events, and then only set it if it's an Element
- # [21:52] <Hixie> outermost things
- # [21:52] <Hixie> the last entry in old chains and new chains
- # [21:52] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 264 seconds)
- # [21:52] <Hixie> after step 1 has pruned the end of the lists
- # [21:52] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [21:54] <zewt> weird, no focus event for the iframe itself if focus is inside the iframe (haven't needed that, it's just what i expected to happen)
- # [21:55] <Hixie> yeah teh iframe and its Document are kinda treated as one
- # [21:56] <zewt> i have a capturing listener on window, and if I focus an iframe inside it, the window just gets a blur
- # [21:56] <Hixie> hm actully...
- # [21:56] <zewt> i'd have thought i'd get a focus with a target of the iframe
- # [21:56] <Hixie> that may have been one of the things i'm trying to change with that new algorithm
- # [21:56] <zewt> like how mouseover works
- # [21:57] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
- # [21:57] <zewt> https://zewt.org/~glenn/foo1.html
- # [21:57] <zewt> fwiw
- # [21:59] * Joins: mven_ (~textual@169.241.49.240)
- # [22:02] * Joins: ehsan (~ehsan@66.207.208.102)
- # [22:03] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [22:04] <SamB> Hixie: didn't you keep notes on that?
- # [22:04] * Quits: mven_ (~textual@169.241.49.240) (Ping timeout: 265 seconds)
- # [22:04] <Hixie> the spec is my notes :-)
- # [22:05] <Hixie> it's easy enough to figure out just by reading the spec, i just didn't read the spec in response to zewt's comment :-)
- # [22:05] * Quits: ehsan_ (~ehsan@66.207.208.102) (Ping timeout: 252 seconds)
- # [22:06] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
- # [22:06] * Joins: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net)
- # [22:11] <marcosc> Hixie: with the <link rel=manifest> thing, I need to say that the user agent is not required to "obtain the resource" until needed, if ever (e.g., for the purpose of bookmarking). However, the link element has text about delaying the load event of a document until the resource being pointed to is obtained. Clearly, we don't want to delay the load event (as the manifest may never get loaded by the UA). I'm wondering, do we need in HTML a special exte
- # [22:11] <marcosc> rnal link that is low priority (may never be loaded) and that doesn't block the document load event from firing? The same could apply to <link rel=icon> - as those resources may never be loaded by the browser until needed.
- # [22:11] * Quits: IZh (~IZh@95.31.44.172) (Remote host closed the connection)
- # [22:14] <Hixie> marcosc: the spec doesn't say that it delays the load event until the resource is obtained
- # [22:15] <Hixie> marcosc: it says it delays the load event "until all the attempts to obtain the resource and its critical subresources are complete"
- # [22:15] * Quits: Smylers (~smylers@2001:a60:102d:b701:51ea:561f:f88e:26c1) (Quit: Leaving.)
- # [22:15] <Hixie> marcosc: if you don't begin an attempt, the load event isn't delayed
- # [22:15] <marcosc> ah
- # [22:15] <Hixie> indeed the very same paragraph explicitly says:
- # [22:15] <Hixie> "Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event."
- # [22:15] <Hixie> it's literally the next sentence
- # [22:16] <marcosc> Sorry, got stuck on that sentence
- # [22:16] <Hixie> see http://www.whatwg.org/specs/web-apps/current-work/#link-type-stylesheet for wording for how to trigger that stuff
- # [22:16] <marcosc> ok, awesome, then I think we are good.
- # [22:17] <Hixie> interestingly, rel=icon doesn't ever say to obtain anything, heh
- # [22:17] <marcosc> yeah
- # [22:17] <marcosc> I noticed that
- # [22:17] <marcosc> :)
- # [22:18] <marcosc> manifest and icon are pretty much the same
- # [22:25] * Joins: newtron_ (~newtron@184.175.19.162)
- # [22:35] * Joins: arunranga (~otherarun@cpe-69-203-2-134.nyc.res.rr.com)
- # [22:39] <arunranga> hi abarth, we’re trying to nail down the origin of blob: URLs and data: URLs (that’s https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 but specifically http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html).
- # [22:39] <abarth> hi
- # [22:39] <abarth> ok
- # [22:40] <abarth> have you nailed down the syntax of blob URLs?
- # [22:40] * Joins: espadrine_ (~ttyl@AMontsouris-158-1-62-182.w92-128.abo.wanadoo.fr)
- # [22:40] <arunranga> Yes, the syntax of a blob: URL is probably nailed down.
- # [22:40] <arunranga> Currently we’ve pegged the origin of the blob: URL to the origin of the incumbent settings object
- # [22:41] <arunranga> But we can’t gather that *from* the blob: URL alone.
- # [22:42] <arunranga> If you’ve got opinions on how we should fix this, and whether we should do the same thing for data: URLs as for blob: URLs, either of those two (email or bug) would be good places to weigh in :-)
- # [22:43] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [22:44] * Quits: espadrine` (~ttyl@AMontsouris-158-1-55-200.w92-128.abo.wanadoo.fr) (Ping timeout: 265 seconds)
- # [22:48] * Joins: cying (~cying@173-228-26-130.dedicated.static.sonic.net)
- # [22:49] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
- # [22:50] <abarth> what does a blob URL look like?
- # [22:50] <abarth> can you give me an example of one?
- # [22:51] <abarth> I ask because last time I studied this problem, different browsers used different syntax for blob URLs
- # [22:51] <abarth> which made the more complex problems intractable
- # [22:51] <zewt> well, you inherently can't get the origin of a blob url if it's revoked
- # [22:52] <zewt> abarth: though, since blob URLs have no meaning and there should never be any blob URLs stored anywhere, it might be possible to change that (even though the feature is already out there)
- # [22:52] <zewt> (not that that's necessarily the right thing to do)
- # [22:53] <abarth> zewt: those statements depend on the syntax of blob URLs
- # [22:53] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [22:53] <zewt> there is no syntax, right? it's just blob: + undefined data (that usually looks random)
- # [22:54] <SamB> abarth: there is none! what you see is an ill-uu-u-u-sion
- # [22:54] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
- # [22:54] <zewt> since the data has no meaning to scripts, you could change that to "blob: + origin + arbitrary data" (or blob: + sha1(origin) + data" or something) without breakage
- # [22:55] <abarth> zewt: right, it's the "undefined data" part that's problematic
- # [22:55] <arunranga> well, there is a syntax in that we do blob: + schemeid with schemeid typically being a UUID
- # [22:55] <SamB> who does that?
- # [22:55] <abarth> i'm happy to discuss a security model for blobs once folks agree on a syntax for blob URLs
- # [22:55] <abarth> that doesn't involve leaving platform-visible strings as implementation-defined
- # [22:56] <zewt> arunranga: individual implementations might have some pattern (like always looking like a UUID), but hopefully nobody's embedding info the web might be depending on
- # [22:56] <abarth> zewt: that hope seems wildly optimistic to me
- # [22:56] <zewt> abarth: maybe, but I'm not sure I can contrive a way people might be depending on that
- # [22:56] <arunranga> (Chrome annotates the blob: URL sometimes so that it looks like this — blob:http://google.com[uuid]
- # [22:56] <arunranga> )
- # [22:56] <zewt> yuck
- # [22:56] <tobie> slightlyoff: which file am I supposed to edit to modify the WebIDL in SW?
- # [22:56] <arunranga> Not sometimes/ all the time
- # [22:57] * Quits: bholley (~bholley@108-91-169-178.lightspeed.sntcca.sbcglobal.net) (Quit: Textual IRC Client: www.textualapp.com)
- # [22:57] <arunranga> I don’t like it :(
- # [22:57] <SamB> indeed yuck
- # [22:57] <abarth> hence the ability to get the origin of a revoked blob URL
- # [22:57] <arunranga> And I wish they didn't
- # [22:57] <tobie> slightlyoff: and in which branch?
- # [22:57] <abarth> wishing and ponies
- # [22:57] <arunranga> Fx doesn’t do it
- # [22:57] * Quits: TallTed (~Thud@63.119.36.36)
- # [22:57] <SamB> that's a terrible syntax
- # [22:57] <zewt> that's not necessarily a bad way to do it, but it's bad to put data inside blob URLs that people might look at and go "hey, I can parse info out of that", if only one vendor is doing it
- # [22:57] <SamB> you should standardize a different syntax just to spite them
- # [22:57] <abarth> zewt: this has all been discussed before
- # [22:57] <SamB> one with a : in it
- # [22:57] <SamB> after the origin
- # [22:57] <abarth> and each vendor appears entrenched in their position
- # [22:57] <zewt> abarth: that's nice :)
- # [22:58] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 265 seconds)
- # [22:58] <arunranga> abarth, zewt: what if this was what it looked like: http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme
- # [22:58] <arunranga> If we agreed on that (big if) could you suggest an origin ?
- # [22:58] <abarth> there is no such thing as an opaque string
- # [22:58] <abarth> strings in JavaScript are not opaque
- # [22:58] <abarth> they're sequences of characters
- # [22:58] <abarth> hence the lie
- # [22:59] * Joins: mven_ (~textual@169.241.49.240)
- # [22:59] <arunranga> abarth, the idea was unguessable.
- # [22:59] * Quits: jonathanmarvens (~jonathanm@199.47.79.34) (Remote host closed the connection)
- # [22:59] <abarth> the participants in the working group did not agree on a syntax
- # [22:59] <abarth> which is why the spec is vague
- # [22:59] <abarth> and why this area of the platform is a mess
- # [23:00] <arunranga> abarth, agreed
- # [23:00] <Ms2ger`> Yay, consensus
- # [23:00] <SamB> I assume "opaque" means something like "the meaning is not in the characters"
- # [23:00] <abarth> SamB: that's not what it means
- # [23:00] <zewt> "opaque" should mean at least "there's nothing users can try to parse out of this"
- # [23:00] <abarth> anyway, as I wrote above, I'm happy to talk with you about a security model after you get folks to agree on a syntax for the URLs
- # [23:00] <arunranga> abarth, on syntax: is UUID a bad idea ?
- # [23:00] <zewt> which blob:http://google.com fails at
- # [23:00] <abarth> arunranga: I'm not the person you need to convince about the syntax
- # [23:01] <abarth> I don't care at all beyond that it needs to be interoperable
- # [23:01] <zewt> that said, i'm not sure why the origin would be in the URL
- # [23:01] * Joins: weinig_ (~weinig@17.202.48.136)
- # [23:01] <abarth> the current situation isn't remotely interoperable
- # [23:01] <arunranga> abarth, the history of this is that Darin didn’t want a restriction to UUID
- # [23:01] <abarth> darin -> fishd ?
- # [23:01] <zewt> you have a live registry somewhere of blob URLs -> blobs; store it in there (means you can't get the origin after the blob URL is revoked, but that shouldn't matter)
- # [23:01] <arunranga> abarth, yep :( But Hixie’s formulation effectively made it UUID
- # [23:01] <abarth> yes, the history is that people did not agree on a syntax
- # [23:01] <abarth> that does not match reality
- # [23:02] <arunranga> abarth, OK. I’ll file bugs to not make claims that are misleading like “opaque” but if we insisted on UUID, so that it was something like blob:UUID, would we be better off?
- # [23:03] * Quits: mven_ (~textual@169.241.49.240) (Ping timeout: 240 seconds)
- # [23:04] <zewt> arunranga: won't help unless chrome people can be convinced to get the origin out of the URLs
- # [23:05] <arunranga> I think we should roll up the sleeves and try and sort this out. It’s hard, but that’s why I’m pestering abarth
- # [23:05] <SamB> hmm, won't that make debugging harder?
- # [23:05] <arunranga> :-)
- # [23:05] <zewt> i don't think it's necessarily bad to put the origin in there like that, it's just bad that one vendor decided to do that
- # [23:06] <abarth> zewt: I don't think you're going to get very far in this discussion if you use biased language like that
- # [23:07] <zewt> sounds like this whole discussion upsets you, but that's not my fault :)
- # [23:07] * Quits: othermaciej (~mjs@17.114.219.231) (Quit: othermaciej)
- # [23:07] * Joins: weinig__ (~weinig@17.202.49.35)
- # [23:07] * Joins: ambv (~ambv@206.108.217.134)
- # [23:08] <arunranga> abarth, actually the thinking was that since the blob: URL is never *seen* and only passed around, what it actually looked like wasn’t important.
- # [23:08] <arunranga> abarth, I tended to agree with that thinking, but it’s clear that if we want to evolve an origin concept for blob:, we need more syntax clarity
- # [23:09] <zewt> arunranga: only if the origin comes by parsing the URL, but since blob URLs have a live registry, is that really the case?
- # [23:09] * Quits: zdobersek (~zan@5.153.234.90) (Quit: Leaving.)
- # [23:09] <arunranga> abarth, the question is: is there a really good implementation reason for “tagging” the blob:UUID model with more info, such as some implementations do? If not, we could stick to something like blob:UUID.
- # [23:09] <arunranga> But this is probably not a convo solved in IRC alone, so I’ll take it to the lists!
- # [23:09] * Quits: weinig_ (~weinig@17.202.48.136) (Ping timeout: 264 seconds)
- # [23:13] * Quits: weinig__ (~weinig@17.202.49.35) (Quit: weinig__)
- # [23:13] * Quits: Maurice` (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
- # [23:14] * Joins: weinig_ (~weinig@17.202.49.35)
- # [23:17] * Quits: weinig_ (~weinig@17.202.49.35) (Client Quit)
- # [23:18] * Joins: weinig_ (~weinig@17.202.49.35)
- # [23:19] * paul_irish_ is now known as paul_irish
- # [23:20] * Quits: espadrine_ (~ttyl@AMontsouris-158-1-62-182.w92-128.abo.wanadoo.fr) (Ping timeout: 252 seconds)
- # [23:22] <sicking> arunranga, abarth: I think syntax for blob: depends on what we decide about origins for blob:
- # [23:23] * Joins: nessy (~silviapf@101.164.214.231)
- # [23:23] * Joins: espadrine_ (~ttyl@AMontsouris-158-1-17-85.w92-128.abo.wanadoo.fr)
- # [23:23] <sicking> if blob: URIs have an implicit origin, like http: does, and unlike data:, then I think it might be valuable to stick that origin inside the URI
- # [23:23] <sicking> but if blob: act more like data:, then obviously that does not make sense
- # [23:24] <sicking> so I think our first step here is to figure out a good story for data:
- # [23:24] <sicking> since without that I don't think we can answer the question of "should blob: act like data:"
- # [23:24] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
- # [23:26] * Joins: barnabywalters (~barnabywa@89.17.128.127)
- # [23:27] <slightlyoff> Tobie: spec/service_worker/index.html in master
- # [23:28] <tobie> slightlyoff: with all the crazy inline urls and such?
- # [23:28] <tobie> slightlyoff: I'd want to edit some of the WebIDL
- # [23:28] <abarth> (sorry, had to run off---back now)
- # [23:29] <tobie> slightlyoff: and it seems like it's generated from something.
- # [23:29] <slightlyoff> Going to fix via the framework shortly
- # [23:29] <slightlyoff> Hand rolled
- # [23:29] <abarth> arunranga: blob URLs are exposed to web sites, which mean we can't have them be implementation-defined
- # [23:29] <tobie> oh, my,
- # [23:29] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Remote host closed the connection)
- # [23:29] <tobie> What about using a tool that already works?
- # [23:29] * tobie hides
- # [23:30] <abarth> sicking: in chrome, a blob URI is bound to an origin
- # [23:30] <sicking> abarth: in gecko too
- # [23:30] <Ms2ger`> tobie, nah, not cool
- # [23:30] <abarth> the difference is just that chrome writes that origin in the syntax of the blob URI
- # [23:31] <sicking> abarth: we just don't stick that origin in the actual URI. It's just kept in an internal hash
- # [23:31] <tobie> Ms2ger`: the hiding part?
- # [23:31] <sicking> right
- # [23:31] <tobie> :P
- # [23:31] <marcosc> seriously, slightlyoff, just use Respec or Anolis. You will spend just as long rolling out your own spec generation thing as you will on the spec.
- # [23:31] <abarth> I never understood why it's problematic to write that origin in the URI
- # [23:31] <marcosc> slightlyoff: It also makes it easier for people to contribute/review the spec.
- # [23:31] <Hixie> all the coolest spec editors roll their own infrastructure
- # [23:31] <sicking> abarth: i'm happy to go with the chrome approach if we do decide that blob:s should have a bound origin (which I think it should)
- # [23:32] <Ms2ger`> tobie, existing tools
- # [23:32] <sicking> abarth: i'm slightly uncomfortable with the "nested URI" aspect of it. But that is probably solvable
- # [23:32] <arunranga> abarth, sicking: here’s a real world example. This is exactly what Chrome does (I coined it in the dev console) blob:http%3A//aaww.org/9efd7ba9-b707-4262-ab0d-6a395be173f1
- # [23:32] <abarth> yeah, I wanted to base64 encode it or something
- # [23:32] <abarth> but there was some reason why someone didn't want to do that
- # [23:33] <abarth> if you don't put the origin in the syntax
- # [23:33] <arunranga> sicking, are you uncomf because of information leak?
- # [23:33] <abarth> you have to decide what happens when someone outside your origin tries to use the URI
- # [23:33] <sicking> arunranga: no, just implementation issues
- # [23:33] <abarth> if its in the syntax, you can just reject it syntatically
- # [23:34] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 29.0/20140428110119])
- # [23:35] <tobie> slightlyoff: so is editing those by hand worthwhile at present?
- # [23:35] <marcosc> Hixie: don't encourage him
- # [23:35] <arunranga> (of course, Fx follows the spec exactly — here’s a blob: URL minted in Fx’s console): blob:2b87eebc-d9ef-954f-a61f-7263e17fba4d)
- # [23:35] <Hixie> imho editors should work with whatever infrastructure they are most comfortable with
- # [23:35] <Hixie> if that means rolling your own, then why not?
- # [23:36] <Hixie> i mean, there's a reason so many of us have done this
- # [23:36] <arunranga> Hixie, crap. I always knew I wasn’t cool. I just used rberjon’s infrastructure
- # [23:36] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 245 seconds)
- # [23:36] <Hixie> arunranga: if that's what makes you the most productive, seems good to me
- # [23:36] <sicking> abarth: anyhow, I think the first step here is to figure out security model for data:. I think what we discssued last time has a lot of potential. We should let Anne know about it
- # [23:36] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 255 seconds)
- # [23:36] <Hixie> i used to use bert's
- # [23:37] <Hixie> now i use gsnedders'
- # [23:37] <Hixie> soonish i'll use mine :-)
- # [23:37] <sicking> abarth: once we've figured out data:, we can figure out if we want to reuse that for blob: (I think we won't want to)
- # [23:37] <arunranga> sicking, abarth: why not just formalize what Chrome is doing, since we think there’s merit in origin extraction from the URL syntax?
- # [23:38] <sicking> arunranga: if you can convince anne that that's the right thing to do, then i'm all for it
- # [23:38] * Quits: Ms2ger` (~Ms2ger@91.182.58.217) (Quit: nn)
- # [23:38] <abarth> sicking: if you want to wait for data to be sorted out, you're going to have to wait a long time :(
- # [23:39] <tobie> Hixie: it's a common tradeoff: either favor external contributions or personal speed.
- # [23:39] * Joins: weinig__ (~weinig@17.114.216.123)
- # [23:39] <abarth> sicking: it's just a lot of engineering to change Blink to support a different security model for data
- # [23:39] <arunranga> sicking, abarth, convincing annevk takes a long time sometimes too
- # [23:39] <abarth> arunranga: or maybe just a few beers :)
- # [23:40] * arunranga knew the pros had a trick up their sleeves
- # [23:41] <sicking> abarth: If you don't think we'll settle data: for a long time, that's enough of an argument for me that we shouldn't use the same thing for blob:
- # [23:41] <sicking> arunranga: so I think that means that we should spec the Chrome behavior
- # [23:41] * Quits: weinig_ (~weinig@17.202.49.35) (Ping timeout: 240 seconds)
- # [23:42] <abarth> I believe the chrome behavior is as follows:
- # [23:42] <sicking> though people should feel free to fight things out about the syntax (%3A vs. : vs. whatever)
- # [23:42] <Hixie> tobie: imho editors should never accept contributions in the form of patches, they should make sure they've written all the text themselves so that they're intimately familiar with it. so i don't think it's that much of a trade-off.
- # [23:42] <Hixie> tobie: the infrastructure doesn't affect contribution speed in the form of bug reports.
- # [23:42] <abarth> 1) you're only allowed to kick off requests for blob URIs that syntatically have the origin of the incumbent script
- # [23:43] <abarth> 2) when loading a blob URI in a browsing context, the origin of the new document is the origin that's syntatically embedded in the URI
- # [23:43] <sicking> abarth: does 1) apply even in sitatuions where you normally can do cross-origin loads? Like for <img>?
- # [23:43] <abarth> yes
- # [23:43] <sicking> cool
- # [23:43] <sicking> sounds good to me
- # [23:43] <sicking> ship it!
- # [23:44] <sicking> this is same as what gecko does, just different syntax
- # [23:44] <sicking> but i like chrome's syntax more
- # [23:44] <abarth> the syntax is important in our implementation because the decision can all be made locally
- # [23:44] <abarth> without race conditions or global synchronization
- # [23:45] <sicking> right
- # [23:45] <sicking> which is why I like it :)
- # [23:45] * Quits: llkats (~llkats@h-64-236-138-2.aoltw.net)
- # [23:45] <arunranga> abarth, 1) matches the spec today absent syntax but 2) seems a bit laxer
- # [23:45] <tobie> agreed if that's your modus operandi. I drank the forking kool-aid, so patches just seem like a much more natural (and polite) way of interacting.
- # [23:46] <arunranga> Uhh, no. I take that back.
- # [23:46] <arunranga> The only thing is syntax
- # [23:47] <sicking> abarth: out of curiosity, is there a reason that for filesystem: you do filesystem:http://example.com/whatnot, but for blob: you do blob:http%3Aexample.com/whatnot?
- # [23:47] * arunranga ^^ good question
- # [23:47] <sicking> abarth: not ':' vs '%3A' after the http
- # [23:47] <sicking> note*
- # [23:48] <abarth> dunno, that seems a bit crazy
- # [23:48] <Hixie> tobie: right. like i said, editors should use whatever they prefer. If they want something that enables them to take patches easily, then obviously they should bear that in mind in their infrastructure selection.
- # [23:49] <abarth> sicking: I suspect we could change the blob one to match filesystem
- # [23:49] <sicking> abarth: I *think* there might be URL-parser-sanity reasons to pick one over the other. I don't know which is preferable though
- # [23:49] <sicking> i guess you guys would have a harder time changing filesystem:?
- # [23:49] <sicking> :(
- # [23:51] <abarth> I bet there's content that does "filesystem:" + location.origin + "/path/to/my/file"
- # [23:51] <sicking> yeah
- # [23:52] <abarth> it matches what gecko does for jar
- # [23:52] <sicking> you'll have to add + "temporary/" in there though
- # [23:52] <sicking> yeah, though jar handling has been a source of a lot of complexity
- # [23:52] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
- # [23:52] <sicking> i'd like to avoid having that get onto the web
- # [23:53] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
- # [23:53] <SamB> jar handling is a good example of, um, something that has had to be rethought because of, um, unforeseen implications?
- # [23:53] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Read error: Connection reset by peer)
- # [23:54] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [23:56] * Quits: jsbell (jsbell@nat/google/x-jjofvxxcwunxguky) (Quit: There's no place like home...)
- # [23:58] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 252 seconds)
- # [23:59] * Joins: mven_ (~textual@169.241.49.240)
- # Session Close: Fri May 09 00:00:01 2014
The end :)