/irc-logs / freenode / #whatwg / 2014-05-20 / end

Options:

# Session Start: Tue May 20 00:00:00 2014
# Session Ident: #whatwg
# [00:01] * Joins: jernoble (~jernoble@17.114.2.168)
# [00:01] * Quits: mven (~textual@169.241.49.202) (Read error: Connection reset by peer)
# [00:01] * Joins: mven (~textual@169.241.49.202)
# [00:01] * Quits: mven (~textual@169.241.49.202) (Max SendQ exceeded)
# [00:02] * Joins: weinig (~weinig@17.114.216.37)
# [00:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [00:02] * Joins: mven (~textual@169.241.49.202)
# [00:02] * Quits: jernoble (~jernoble@17.114.2.168) (Client Quit)
# [00:04] * Quits: systematik (~nick@thunder.nickmerrill.co) (Quit: leaving)
# [00:05] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
# [00:05] * Joins: tantek_ (~tantek@corp-nat.p2p.sfo1.mozilla.com)
# [00:06] * Quits: weinig (~weinig@17.114.216.37) (Client Quit)
# [00:10] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
# [00:13] * Quits: mven (~textual@169.241.49.202) (Ping timeout: 265 seconds)
# [00:16] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [00:18] * Quits: lokling (~quassel@quassel.woboq.de) (Read error: Operation timed out)
# [00:20] * Joins: lokling (~quassel@quassel.woboq.com)
# [00:21] * Joins: weinig (~weinig@17.114.216.37)
# [00:21] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [00:22] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [00:29] <TabAtkins> Hixie: What is FontLoader and what were you using it for? If you just want to load a font via JS, FontFace is constructable.
# [00:29] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [00:29] <TabAtkins> Hixie: There is no way to position the top and left of an element relative to different things at the moment.
# [00:33] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
# [00:34] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
# [00:34] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 240 seconds)
# [00:34] * Joins: systematik (~nick@thunder.nickmerrill.co)
# [00:40] <Hixie> TabAtkins: i don't recall. something in HTML. i filed a bug on myself to figure it out.
# [00:40] <Hixie> TabAtkins: re positioning: k. anything on the radar for that?
# [00:43] * Joins: weinig (~weinig@17.114.216.37)
# [00:43] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Remote host closed the connection)
# [00:43] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
# [00:47] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
# [00:48] <JonathanNeal> To whomever it concerns, I have filed my latest element query pleas @ http://discourse.specifiction.org/t/element-queries/26/last
# [00:51] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 258 seconds)
# [00:54] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [00:55] <TabAtkins> Hixie: Nope, nothing right now. I have plans, but no timeline for achieving them.
# [00:55] <Hixie> k
# [00:56] * Joins: karlcow (~karl@nerval.la-grange.net)
# [00:57] <Domenic> http://gridstylesheets.org/ is a related prolyfill/ideation exercise
# [00:57] <Domenic> i want to try it on a small project and see how i feel afterward
# [00:58] <Domenic> i could easily see it either being "wow this is amazing we must have this" or "meh that really doesn't work in practice, nice try"
# [00:59] * Guest19805 is now known as jory
# [01:01] * Joins: ap_ (~ap@17.114.219.248)
# [01:03] * Quits: plutoniix (~plutoniix@node-nc3.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
# [01:04] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 264 seconds)
# [01:04] * ap_ is now known as ap
# [01:04] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
# [01:09] <JonathanNeal> Domenic: were you the one who replied to me?
# [01:10] <JonathanNeal> If it was, I appreciate you citing TabAtkins’ blog as the canonical reply. But, at the same time, arrrrr! I had a bunch of links in my post, but discourse doesn’t let me add more than one or two.
# [01:18] <zewt> are clipboard events those sort of broken ancient events that have side-effects when fired from script (like click)?
# [01:19] <zewt> it doesn't seem like they are in testing, but hallvord implied that they are on the list (and he's apparently the editor of the clipboard spec)
# [01:20] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [01:25] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [01:25] <JonathanNeal> Domenic: re: gss, it’s amazing that we can think up entirely different ways to write stylesheets, and its best marketing is still “now you can vertically center something”
# [01:29] * Krinkle is now known as Krinkle|detached
# [01:29] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
# [01:32] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [01:32] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [01:32] <gsnedders> Okay then, to continue my questioning from yesterday: which Chromebook do I want? Given they basically all have 1366x768 displays, I guess there's no point in going for one of the larger ones? AFAICT, the HP Chromebook 11 seems to have the best screen of them, but it does have a now ancient SoC in it…
# [01:34] * Joins: weinig (~weinig@17.114.216.37)
# [01:35] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [01:35] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [01:36] * Quits: bholley (~bholley@corp.mtv2.mozilla.com) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [01:36] * Quits: jeffreyatw (~jeffreyat@173.247.197.10) (Quit: jeffreyatw)
# [01:37] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Remote host closed the connection)
# [01:37] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
# [01:38] <JonathanNeal> gsnedders: that sounds all right. I’m very productive on 1440x900.
# [01:41] * gsnedders vaguely wonders about selling his tablet
# [01:42] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
# [01:42] <gsnedders> I just don't use it that much…
# [01:42] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [01:44] * Joins: lmclister (~lmclister@192.150.10.205)
# [01:48] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 240 seconds)
# [01:51] <JonathanNeal> gsnedders: i used mine for one project, and my 1 year old found a better use for it, namely the tinkerbell film series.
# [01:52] * Quits: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net) (Quit: ZZZzzz…)
# [01:52] <gsnedders> All the Chromebooks seem to be somewhat flawed. The HP Chromebook 11 has a wonderful screen, but opinions are mixed on the keyboard, and apparently performance isn't brilliant with a few tabs open… On the other hand, the Dell Chromebook 11 has a less good screen but better everything else…
# [01:53] * Joins: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp)
# [01:57] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 265 seconds)
# [01:58] * Joins: mven (~textual@ip68-104-38-84.lv.lv.cox.net)
# [02:00] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: Textual IRC Client: www.textualapp.com)
# [02:02] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [02:04] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-bbomruskdbappzel)
# [02:05] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [02:07] <TabAtkins> gsnedders: Buy a Pixel.
# [02:08] <gsnedders> TabAtkins: no. :)
# [02:09] <TabAtkins> Too pricey, or does it fail one of your other criteria?
# [02:09] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
# [02:09] <gsnedders> Too pricey. If I'm dropping that money, I'd get a Macbook of some variety.
# [02:11] * Quits: jsbell (jsbell@nat/google/x-gzonfgsawpjtulso) (Quit: There's no place like home...)
# [02:12] <gsnedders> (and then just entirely replace my existing MBP, instead of getting something more to replace my tablet than anything else)
# [02:13] * Joins: zcorpan (~zcorpan@113.199.41.81)
# [02:14] * Quits: zcorpan (~zcorpan@113.199.41.81) (Remote host closed the connection)
# [02:15] * Joins: zcorpan (~zcorpan@113.199.41.81)
# [02:15] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [02:17] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Read error: Connection reset by peer)
# [02:17] * Joins: ap_ (~ap@2620:149:4:304:60b2:7b5b:c970:cd45)
# [02:17] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [02:17] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
# [02:18] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [02:19] * Joins: bholley (~bholley@98.210.101.88)
# [02:19] * Quits: ap (~ap@17.114.219.248) (Ping timeout: 240 seconds)
# [02:19] * ap_ is now known as ap
# [02:19] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 276 seconds)
# [02:20] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Remote host closed the connection)
# [02:22] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
# [02:23] * Quits: bholley (~bholley@98.210.101.88) (Ping timeout: 252 seconds)
# [02:25] * Joins: weinig (~weinig@17.114.216.37)
# [02:26] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
# [02:27] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
# [02:28] * Joins: othermaciej (~mjs@17.114.217.202)
# [02:47] * Joins: scor (~scor@drupal.org/user/52142/view)
# [02:49] * Joins: zcorpan (~zcorpan@113.199.42.59)
# [02:54] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
# [02:54] <zewt> the Most Annoying Thing On The Internet: http://social.msdn.microsoft.com/Forums/en-US/53ae87d1-dd83-4a44-8303-4a31c9c37015/stopping-scrollviewer-from-auto-scrolling-when-item-gets-focus
# [02:55] <zewt> "how do I do this thing?" "never mind, here's the solution" *404*
# [02:58] <caitp> there are many annoying things on the internet, there will be many more in the future
# [02:58] <caitp> exponentially more
# [02:59] * Quits: zcorpan (~zcorpan@113.199.42.59) (Remote host closed the connection)
# [03:00] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
# [03:00] * Joins: zcorpan (~zcorpan@113.199.42.59)
# [03:03] * Quits: tantek_ (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek_)
# [03:04] * Quits: zcorpan (~zcorpan@113.199.42.59) (Ping timeout: 258 seconds)
# [03:06] * Quits: ap (~ap@2620:149:4:304:60b2:7b5b:c970:cd45) (Quit: ap)
# [03:09] * Joins: marbleEye (~marbleEye@host86-145-211-9.range86-145.btcentralplus.com)
# [03:13] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
# [03:15] * Quits: lmclister (~lmclister@192.150.10.205)
# [03:21] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [03:21] * Joins: a-ja (~Instantbi@70.230.147.189)
# [03:30] * Quits: a-ja (~Instantbi@70.230.147.189) (Read error: Connection reset by peer)
# [03:31] * Joins: a-ja (~Instantbi@70.230.147.189)
# [03:31] * Joins: othermaciej_ (~mjs@17.202.49.252)
# [03:32] * Quits: othermaciej (~mjs@17.114.217.202) (Ping timeout: 240 seconds)
# [03:32] * othermaciej_ is now known as othermaciej
# [03:33] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 255 seconds)
# [03:39] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:40] * Joins: lmclister (~lmclister@192.150.10.205)
# [03:40] * Joins: karlcow (~karl@nerval.la-grange.net)
# [03:41] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-plzzkzllmyxakhha)
# [03:46] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
# [03:49] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
# [03:56] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [03:57] * Quits: newtron (~newtron@184.175.16.140) (Remote host closed the connection)
# [03:58] * htmelvis_zzz is now known as htmelvis
# [04:02] * Joins: othermaciej_ (~mjs@17.114.217.202)
# [04:02] * Quits: othermaciej_ (~mjs@17.114.217.202) (Client Quit)
# [04:04] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-wchgzlklpxvcwoxj) (Ping timeout: 264 seconds)
# [04:04] * Quits: othermaciej (~mjs@17.202.49.252) (Ping timeout: 252 seconds)
# [04:06] * Parts: a-ja (~Instantbi@70.230.147.189)
# [04:07] * Joins: morrita_ (uid16889@gateway/web/irccloud.com/x-phemqzbmcrmyjkta)
# [04:18] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [04:18] * Joins: zcorpan (d25fff95@gateway/web/freenode/ip.210.95.255.149)
# [04:19] <zcorpan> Hixie: i can fix the autorotate thing relatively soon i think
# [04:19] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [04:29] <MikeSmith> zcorpan John told me he'd replied -- replied to you, I think.
# [04:34] <zcorpan> MikeSmith: i don't see anything in my inbox and i don't see anything in http://lists.w3.org/Archives/Public/www-archive/2014May/thread.html
# [04:35] <zcorpan> MikeSmith: he had replied to denis in private before all three of us emailed him and cc-ed www-archive i think, but i wanted a public record
# [04:36] <zcorpan> MikeSmith: so the critic issue actually isn't resolved yet afaict
# [04:37] <Hixie> zcorpan: cool. it sounds pretty straightforward. file a bug on me once you've done it to add it to the index. thanks!
# [04:37] <zcorpan> Hixie: ok
# [04:38] <MikeSmith> zcorpan: OK, when we have cases like this I'd like to suggest we open separate issues and then close the PR, if this kind of problem is the only thing blocking it
# [04:39] <MikeSmith> zcorpan: I think it's bad for everybody to keep PRs hanging open for months on end
# [04:39] <MikeSmith> zcorpan: they get stale and people lose interest in following up on them
# [04:40] <MikeSmith> zcorpan: or in in this specific case, the guy who was responsible for that PR no longer is paid to work on testing, and has moved on
# [04:40] <zcorpan> MikeSmith: i don't disagree that it's bad to have PRs open for a long time
# [04:41] <MikeSmith> zcorpan: I'll ping John again and ask him if he can reply to your www-archive message
# [04:41] <zcorpan> ok great
# [04:42] <zcorpan> Hixie: as for styling, e.g. the stylesheet for http://dev.w3.org/csswg/cssom/ is a lot less busy than the whatwg stylesheet, but still has enough visible cue (at least for me) to see where the links are
# [04:44] <zcorpan> Hixie: i'm not saying that stylesheet is without problems, but i agree with jgraham that it should be possible to create a stable and subtle yet usable style. i'm not sure i agree with jgraham about the underline, it doesn't bother me and something other than color is necessary for people with some color-blindnesses (unless you can find a color that works for all common color blindnesses)
# [04:45] <zcorpan> (maybe a lighter shade would work to make a contrast difference even if you can't distinguish the color?)
# [04:46] <MikeSmith> Hixie: as far as the undelrines, what zcorpan said
# [04:46] <MikeSmith> people who have a problem with underlines are going to have a hard time on the internet
# [04:48] <MikeSmith> Hixie: the underlines have a utility -- exactly the utility that you mentioned earlier (distinguishing, e.g., between hyperlinked <code> and unhyperlinked -- or whatever specific case you mentioned)
# [04:49] <MikeSmith> Hixie: I think some people are willing to sacrifice the utility of the spec to aesthetics or making it look less "busy" or however they're stating it
# [04:50] <SamB> hey, I've heard of this thing called alternate stylesheets
# [04:50] <zcorpan> (i don't personally have a problem with the "busy" style, so long as it doesn't do the fading thing)
# [04:50] <MikeSmith> zcorpan: yeah
# [04:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [04:50] <zewt> things nobody should ever have to use: alternate stylesheets
# [04:51] <zcorpan> SamB: that has already been brought up
# [04:51] <SamB> 'kay
# [04:52] <zewt> don't know what's changed, but the main TOC is pretty hard to look at right now, probably too much space around everything
# [04:53] <MikeSmith> zcorpan: I could live without the fading thing, but I thought it was a good clever solution to the problem Hixie was trying to solve. Now, I think, it would be nice to solve that problem if it's solvable, but I'm not sure it is, and maybe it's not worth spending a lot of time trying to solve.
# [04:53] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
# [04:53] <MikeSmith> zewt: hmm yeah maybe there's too much line space there now
# [04:53] <zewt> looks like all numbered lists have that problem
# [04:54] <MikeSmith> zewt: ah yeah, seems so
# [04:54] <MikeSmith> I guess Hixie should just rachet that back down a bit
# [04:54] <zewt> dotted lists are fine
# [04:55] <MikeSmith> anyway it would be a shame to see that spec change in ways that it less usable for implementors, even it if it made it slightly more usable for others
# [04:57] <MikeSmith> I've never had any problem with the colors or anything else. in fact, the opposite -- I really appreciate that all those various cues are there are value them. I couldn't care less if it looks "busy" as long as it makes it easier for me to find what I need
# [04:57] <MikeSmith> I'm not reading it for fun
# [04:58] <MikeSmith> if people want less busy, there's always IETF style
# [04:58] <zewt> 80 column with hardcoded page breaks for 80x55 daisy wheel printers?
# [04:59] <MikeSmith> zewt: yeah but I meant more the lack of colors and the lack of hyperlinks
# [05:00] <SamB> I like it how zewt says it though
# [05:00] <SamB> I mean, it's funnier that way
# [05:01] <SamB> not that I'd want to see the spec like that
# [05:01] <zewt> i didn't have any issues with the formatting, my main issue with the spec is just wishing it loaded faster, heh
# [05:01] <zewt> (maybe if the multipage referencing worked better i'd use it, though being able to text search the whole spec is probably also hard to do without)
# [05:01] <SamB> so you want it to be less busy on the *inside*
# [05:02] <SamB> me too
# [05:02] <zewt> i don't know the first thing about why it's so slow, heh ("it's huge" is obviously a part, but I assume it's more complicated than that)
# [05:02] <SamB> I remember a time when I could actually load the single-page spec
# [05:03] <zewt> guess I could load it with no styles or scripts and find out
# [05:03] <TabAtkins> It's huge, it does some JS loops over the whole document, and I'd bet the selectors aren't well-optimized.
# [05:06] <zewt> "no copyright is asserted on this file"? is that really a valid way to disclaim copyright? heh
# [05:10] <MikeSmith> Hixie: about the validator not catching the <dd> thing before you fixed it, I think it might have been because validator.nu hasn't been synched for a while and has an older version of the schema that wasn't going <dl><dt><dd> checking correctly for a while after we made the change to allow <script> and <template> in there
# [05:10] * marbleEye is now known as blindCode
# [05:12] <MikeSmith> Hixie: I think it works as expected in the current source and at http://sideshowbarker.net:8888/ and http://validator.w3.org/nu/
# [05:12] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Remote host closed the connection)
# [05:14] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
# [05:16] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Quit: tav)
# [05:19] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 29.0/20140428110119])
# [05:23] <TabAtkins> zewt: No, it's not a valid way. Copyright is automatic regardless of what you say.
# [05:23] <TabAtkins> At least in US law, and most other countries.
# [05:25] <Hixie> MikeSmith: cool
# [05:25] <Hixie> i should probably change to ssb.n:8888
# [05:26] <Hixie> btw re the style sheet, there were some substantial changes earlier today, so i'm letting it sit for a few days to see how people like it
# [05:27] <Hixie> (in particular, i think it might be less busy that the /csswg/cssom/ style sheet at this point)
# [05:28] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [05:35] <TabAtkins> Still super-hate the fading thing.
# [05:35] <TabAtkins> I didn't hate it earlier, but it's fading on me. ^_^
# [05:36] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
# [05:36] <Hixie> it's long gone
# [05:39] * Quits: blindCode (~marbleEye@host86-145-211-9.range86-145.btcentralplus.com) (Quit: Leaving)
# [05:43] * Joins: newtron (~newtron@184.175.16.140)
# [05:45] * Joins: bholley (~bholley@98.210.101.88)
# [05:50] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Remote host closed the connection)
# [05:54] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [05:55] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
# [05:57] * Quits: newtron (~newtron@184.175.16.140) (Remote host closed the connection)
# [06:10] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
# [06:14] <TabAtkins> Oh, hm, must need to force-refresh.
# [06:17] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-phemqzbmcrmyjkta) (Quit: Connection closed for inactivity)
# [06:20] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Ping timeout: 240 seconds)
# [06:20] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [06:21] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
# [06:31] * Quits: lmclister (~lmclister@192.150.10.205)
# [06:33] <zcorpan> MikeSmith: can you look into the w3c-test:mirror thing? i want some people to look at the tests without having them clone and get wptserve running
# [06:34] <zcorpan> MikeSmith: the PR is https://github.com/w3c/web-platform-tests/pull/996
# [06:36] <zcorpan> oh i see you replied in #testing
# [06:36] * Joins: lmclister (~lmclister@192.150.10.205)
# [06:36] * Quits: lmclister (~lmclister@192.150.10.205) (Remote host closed the connection)
# [06:41] <MikeSmith> zcorpan: checkong on it now
# [06:44] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 240 seconds)
# [06:51] <zcorpan> MikeSmith: thanks!
# [06:51] <zcorpan> MikeSmith: maybe i don't have the right permissions, like jgraham said?
# [06:53] <MikeSmith> yeah checking on that too
# [06:56] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Remote host closed the connection)
# [06:56] <MikeSmith> zcorpan: http://w3c-test.org/submissions/996/
# [06:56] <MikeSmith> still working on the underlying cause
# [06:56] <zcorpan> MikeSmith: thank you
# [06:59] <MikeSmith> zcorpan: fwiw as far as the underlying cause, I think it might be a github bug
# [06:59] <MikeSmith> because the script relies on https://api.github.com/repos/w3c/web-platform-tests/collaborators
# [06:59] <MikeSmith> the sync script
# [07:00] <MikeSmith> zcorpan: and you're not listed there and neither am I
# [07:00] <zcorpan> weird
# [07:00] <MikeSmith> yeah
# [07:00] <zcorpan> i can report it to github if you like
# [07:01] <MikeSmith> zcorpan: yeah please do if you have time
# [07:01] * Joins: gavin___ (~gavin@76.14.87.162)
# [07:01] * Quits: gavin__ (~gavin@76.14.87.162) (Read error: Connection reset by peer)
# [07:02] <MikeSmith> zcorpan: and in the mean time I guess the workaround to get something mirrored is to ask somebody who's actually listed there to add a comment
# [07:03] <MikeSmith> jgraham is not there either, no Ms2ger, so I guess we really should be checking it against some other list if there is one
# [07:03] <zcorpan> MikeSmith: what's your github handle?
# [07:03] <MikeSmith> zcorpan: sideshowbarker
# [07:05] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 245 seconds)
# [07:05] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
# [07:08] <zcorpan> MikeSmith: ok reported. didn't get a URL or anything for the issue and i failed to get under 140 chars so i didn't get a gold star
# [07:09] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [07:09] <zcorpan> but i'll let you know when i get a reply
# [07:09] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
# [07:10] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [07:12] * Quits: nicolasbadia (~nicolasba@78.209.78.103) (Quit: nicolasbadia)
# [07:13] <MikeSmith> zcorpan: thanks
# [07:13] <MikeSmith> win 27
# [07:14] * Joins: nicolasbadia (~nicolasba@78.209.78.103)
# [07:21] * htmelvis is now known as htmelvis_zzz
# [07:24] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [07:25] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [07:28] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [07:30] * Joins: bholley (~bholley@98.210.101.88)
# [07:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [07:30] * Joins: IZh (~Igor_Zhba@0897578511.static.corbina.ru)
# [07:37] * Joins: bholley (~bholley@98.210.101.88)
# [07:39] * Joins: zdobersek (~zan@185.3.135.82)
# [07:40] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [07:44] * Joins: bholley (~bholley@98.210.101.88)
# [07:44] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
# [07:49] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 252 seconds)
# [07:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [07:50] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [07:52] * Quits: nicolasbadia (~nicolasba@78.209.78.103) (Quit: nicolasbadia)
# [07:54] * Quits: roc (~chatzilla@60.234.66.18) (Ping timeout: 255 seconds)
# [07:55] * Joins: ambv (~ambv@173.252.71.129)
# [07:56] * Joins: bholley (~bholley@98.210.101.88)
# [07:56] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [07:56] * Quits: ambv (~ambv@173.252.71.129) (Client Quit)
# [07:57] * Joins: nicolasbadia (~nicolasba@78.209.78.103)
# [08:03] * Quits: aretecode (~aretecode@64.120.6.170) (Remote host closed the connection)
# [08:05] <zcorpan> Hixie: i think i didn't write ""; but actually wrote "list of available images"; in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25797
# [08:06] <zcorpan> Hixie: is there a bug somewhere tampering with it or am i mistaken about what i wrote? :-)
# [08:06] * Joins: roc (~chatzilla@60.234.66.18)
# [08:07] <Hixie> i don't log anything for file-bug.cgi, so dunno
# [08:07] <zcorpan> ok
# [08:07] <Hixie> but i can't imagine what i could do to cause that :-)
# [08:08] <zcorpan> yeah i dunno either
# [08:08] <zcorpan> maybe it was what i wrote
# [08:08] <Hixie> wait, i do log something
# [08:08] <Hixie> when did you file this? just now?
# [08:08] <zcorpan> 2014-05-19 07:37:09 UTC
# [08:09] * Hixie tries to work out what time zone he's in
# [08:10] <Hixie> that's either two minutes in the future or an hour ago
# [08:10] * Quits: CvP (~CvP@27.147.199.131) (Disconnected by services)
# [08:10] <Hixie> wait wtf
# [08:10] * Joins: xCG (~CvP@27.147.199.131)
# [08:10] <Hixie> this computer's clock is WAY off
# [08:11] * xCG is now known as CvP
# [08:12] <IZh> Hixie: Hi. Last PDF was not generated because of missing fonts. It seems there are new rare characters in the spec. :-) I'll find suitable font and regenerate it.
# [08:12] <Hixie> hehe thanks :-)
# [08:13] <Hixie> zcorpan: ok according to the logs if there's a bug it's somewhere in Apache or Perl's core libraries
# [08:13] <Hixie> zcorpan: because my code gets the text, then logs it immediately before fiddling with it, and it logged "".
# [08:14] <zcorpan> Hixie: so that means it's unlikely that there is a bug
# [08:15] <zcorpan> i can try filing a new bug with what i think i wrote, and see if it reproduces
# [08:15] <Hixie> occam's razor suggests there isn't a bug. murphy's law suggests there is. your call. :-)
# [08:17] <zcorpan> didn't reproduce
# [08:18] * Joins: bholley (~bholley@98.210.101.88)
# [08:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [08:19] <IZh> I have written a script that looks for missing characters and prints font list that contains it sorted by number of missing characters found in each font. :-)
# [08:23] * Joins: Ducki (~Ducki@137.116.197.171)
# [08:23] * Joins: bholley (~bholley@98.210.101.88)
# [08:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [08:24] * Joins: bholley (~bholley@98.210.101.88)
# [08:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [08:27] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
# [08:27] * Joins: bholley (~bholley@98.210.101.88)
# [08:27] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [08:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [08:36] * Joins: bholley (~bholley@98.210.101.88)
# [08:36] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [08:39] * Joins: zaal_ (~zaal@cpc65346-nrwh11-2-0-cust48.4-4.cable.virginm.net)
# [08:43] * Joins: markkes (~markkes@62.207.90.201)
# [08:50] <IZh> Hixie: I've fixed it. :-)
# [08:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [08:52] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [08:52] <IZh> Hixie: Currently the document needs 15 fonts. (And some web-fonts too.)
# [09:14] * Joins: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e)
# [09:14] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [09:16] * Quits: IZh (~Igor_Zhba@0897578511.static.corbina.ru) (Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26/20140428215944])
# [09:25] * Joins: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net)
# [09:28] * Joins: gavin__ (~gavin@76.14.87.162)
# [09:32] * Joins: espadrine` (~ttyl@AMontsouris-158-1-15-151.w92-128.abo.wanadoo.fr)
# [09:34] * Joins: Dashiva_j (Dashiva@wikia/Dashiva)
# [09:34] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-bbomruskdbappzel)
# [09:37] * Quits: gavin___ (~gavin@76.14.87.162) (*.net *.split)
# [09:37] * Quits: Dashiva (Dashiva@wikia/Dashiva) (*.net *.split)
# [09:37] * Quits: espadrine (~ttyl@AMontsouris-158-1-15-151.w92-128.abo.wanadoo.fr) (*.net *.split)
# [09:37] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (*.net *.split)
# [09:37] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-ydafuxmgkkjmfmjb) (*.net *.split)
# [09:37] * Dashiva_j is now known as Dashiva
# [09:38] * Quits: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
# [09:39] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
# [09:43] * Joins: Garbee (uid21171@gateway/web/irccloud.com/session)
# [09:43] * Quits: Garbee (uid21171@gateway/web/irccloud.com/session) (Changing host)
# [09:43] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-dsoytojouwletajb)
# [09:43] * Garbee is now known as Guest57780
# [09:43] * Quits: zcorpan (d25fff95@gateway/web/freenode/ip.210.95.255.149) (Ping timeout: 240 seconds)
# [09:47] <annevk> Hixie: I think the only reason you wanted FontLoader or some such is to be able to have a solution for fonts in workers
# [09:47] <annevk> Hixie: in combination with <canvas> in workers
# [09:49] * Quits: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net) (Quit: ZZZzzz…)
# [09:49] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
# [09:51] * Quits: beverloo_ (beverloo@nat/google/x-efyrfutrbymkovva) (Read error: Operation timed out)
# [09:51] * Joins: beverloo_ (beverloo@nat/google/x-labaagdtgnhweotc)
# [09:53] * Joins: richt (~richt@83.218.67.123)
# [09:57] <TabAtkins> Which exists!
# [09:58] <TabAtkins> I need to make FontFace objects transferable, but you can definitely construct them inside of a worker and add them to the font source.
# [09:58] <TabAtkins> Hm, I'm adding a .fonts property to the worker global. Is that okay? Should I be doing something else?
# [09:59] <TabAtkins> It's added to document in normal pages.
# [09:59] * Joins: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk)
# [10:00] * Joins: yoav_ (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [10:02] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
# [10:03] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [10:05] * Joins: Ms2ger (~Ms2ger@134.199-242-81.adsl-dyn.isp.belgacom.be)
# [10:07] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [10:07] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
# [10:11] <annevk> TabAtkins: why not CSS.fonts ?
# [10:12] <TabAtkins> annevk: Good question, I guess.
# [10:16] * Joins: darobin (~darobin@78.109.80.74)
# [10:16] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [10:21] <annevk> TabAtkins: I guess another thing to think about is how this would work with modules
# [10:22] <annevk> TabAtkins: presumably once you import "css" this should be imported as well, but we haven't really explored the layering of the subsystems I suppose
# [10:22] <JakeA> Hixie: What's your take on promise-vending .loaded() methods (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-March/253949.html)? The HTML Imports spec wants it (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25007) but it'd be great to have it on other <link> elements too (and maybe img, script)
# [10:23] * Joins: zcorpan (~zcorpan@113.199.42.54)
# [10:24] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [10:25] * Quits: zcorpan (~zcorpan@113.199.42.54) (Remote host closed the connection)
# [10:25] * Joins: zcorpan (~zcorpan@113.199.42.54)
# [10:29] * Quits: zcorpan (~zcorpan@113.199.42.54) (Ping timeout: 240 seconds)
# [10:30] * Joins: bholley (~bholley@98.210.101.88)
# [10:34] * Quits: bholley (~bholley@98.210.101.88) (Ping timeout: 252 seconds)
# [10:38] * amtiskaw__ is now known as amtiskaw
# [10:47] <annevk> JakeA: why methods?
# [10:51] * Joins: Lachy (~Lachy@213.166.174.2)
# [10:52] <JakeA> annevk: because they're of the moment. As in, img.src = foo; img.loaded().then(...); img.src = bar; img.loaded().then(...)
# [10:53] <JakeA> felt like methods made more sense, but it wouldn't break my world if they were properties :D
# [11:03] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [11:07] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Quit: Leaving.)
# [11:09] <annevk> JakeA: if you invoke loaded() multiple times, do you get the same object?
# [11:10] <JakeA> annevk: Yes, unless there's a good reason not to. Of course, as soon as you change "src" the promise vended by loaded() changes
# [11:11] <annevk> JakeA: in that case a property seems fine
# [11:12] <JakeA> annevk: navigator.serviceWorker.whenReady should be the same I guess
# [11:12] <JakeA> (although I hate that API with a passion, but don't have a better idea)
# [11:12] <annevk> JakeA: yeah makes sense
# [11:17] * Joins: IZh (~IZh@213.33.220.118)
# [11:27] * Quits: darobin (~darobin@78.109.80.74) (Quit: Leaving...)
# [11:27] * Joins: darobin (~darobin@78.109.80.74)
# [11:31] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [11:35] <tobie> It feels kind of weird to have a promised not related to the action itself.
# [11:35] <tobie> As in: img.loadResource(url).then(...
# [11:42] <JakeA> tobie: I don't think it's a big deal. People have been using whatever.ready(callback) in various libraries
# [11:43] <annevk> tobie: it's just status observation, seems fine for one-offs
# [11:45] <tobie> Yeah. There seems to be cases where there's no other solution than that one. Thinking out loud really, but it seems it would help if we can classify those.
# [11:47] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
# [11:48] <hsivonen> mathiasbynens: validator.nu seems to be up for me. maybe it was just busy earlier?
# [11:49] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
# [11:49] * Quits: roc (~chatzilla@60.234.66.18) (Ping timeout: 255 seconds)
# [11:51] <tobie> Seems most of them are around the declarative/imperative boundary (not sure whether this helps).
# [11:52] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 255 seconds)
# [11:55] <mathiasbynens> hsivonen: yeah, works fine now. I’ll keep an eye on it
# [12:01] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [12:03] * Guest57780 is now known as Garbee
# [12:06] * Joins: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt)
# [12:07] <annevk> tobie: well, serviceWorker.whenReady is not on that boundary I think
# [12:07] <JakeA> Neither is document.ready()
# [12:07] <annevk> tobie: I think the pattern is more that if you have something that multiple parties might want to observe, you need to expose it independently from the action
# [12:07] <tobie> doc.ready is.
# [12:07] <annevk> tobie: as a status-promise
# [12:08] <JakeA> Or anyParserInsertedElement.loaded()
# [12:08] <annevk> (again, I'd prefer document.ready and ele.loaded)
# [12:08] <JakeA> ah yes, sorry
# [12:08] <tobie> you mean props?
# [12:08] <tobie> I agree.
# [12:08] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [12:09] <JakeA> document.querySelector('img').loaded.then(...)
# [12:09] <mathiasbynens> document.images[0].loaded.then(…)
# [12:09] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Ping timeout: 265 seconds)
# [12:09] <mathiasbynens> </code-golf>
# [12:10] <JakeA> haha
# [12:10] <JakeA> but your IRC handle is longer, so it almost balances out
# [12:13] <tobie> None of these (.ready, .ready() .whenReady()) are particularly nice. :(
# [12:14] <JakeA> What's not nice about it? Do you feel the same about jquery's $(document).ready(callback)?
# [12:14] <tobie> yeah. it's terrible.
# [12:15] <tobie> but less ugly with a callback then with a promise.
# [12:16] <JakeA> Got anything more constructive? :D
# [12:17] <tobie> Man, I wish I had.
# [12:18] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
# [12:18] * Quits: richt (~richt@83.218.67.123) (Quit: Leaving...)
# [12:18] <TabAtkins> FontFace uses a .loaded attribute to expose a promise.
# [12:18] <TabAtkins> tobie: A promise is a callback. ^_^
# [12:20] <JakeA> TabAtkins: Ohh, I didn't realise that. Well, that's all the more reason for these to be attributes & not methods
# [12:20] <tobie> agreed.
# [12:20] <annevk> Oh right, TabAtkins is in Seoul, it all makes sense now
# [12:20] <TabAtkins> Hah, wondering about my timezone?
# [12:20] <tobie> when(font.loaded).then
# [12:20] <TabAtkins> tobie: ??? No, font.loaded.then(...)
# [12:20] <tobie> (sorry, toying with stuff)
# [12:20] <annevk> TabAtkins: I was doing the math and at 3-4AM you're usually not around
# [12:21] <TabAtkins> annevk: Yeah, checking gavin's stats I'm virtually never around in the 12am to 6am block.
# [12:22] <TabAtkins> Still a good bit behind jgraham in the stats. I don't think I'll ever move past 5th place.
# [12:22] <annevk> Whoa, Hixie made a solid comeback :-)
# [12:22] <JakeA> await img.loaded;
# [12:23] <annevk> JakeA: you can almost read it
# [12:23] <JakeA> wfm
# [12:23] <tobie> Only concern I still have is loaded feels a tad like a boolean
# [12:24] <TabAtkins> tobie: Was my concern too, but shrug.
# [12:24] <tobie> yeah.
# [12:24] <tobie> What's gavin's stats?
# [12:24] <annevk> tobie: see /topic
# [12:24] <tobie> duh
# [12:25] * Joins: richt (~richt@83.218.67.123)
# [12:26] * Joins: richt_ (~richt@91.216.105.52)
# [12:27] * Joins: richt__ (~richt@83.218.67.123)
# [12:27] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
# [12:27] * Joins: zcorpan (~zcorpan@113.199.41.81)
# [12:28] <jgraham> Also glob has stats under "about". Not as detailed as gavin's though
# [12:29] <jgraham> But using more data, I think?
# [12:29] <TabAtkins> dear gavin (or gavin__ ), your stats page doesn't handle unicode properly.
# [12:29] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
# [12:29] <TabAtkins> Saw some curly quotes turned into â€œ
# [12:30] * TabAtkins will never get over that Divya holds both first and second place for most all-caps shouting.
# [12:30] * Joins: karlcow (~karl@nerval.la-grange.net)
# [12:30] * Quits: richt_ (~richt@91.216.105.52) (Ping timeout: 240 seconds)
# [12:30] * Quits: richt (~richt@83.218.67.123) (Ping timeout: 276 seconds)
# [12:30] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
# [12:31] <TabAtkins> Even when you cut her shouting in half, she beats everyone else.
# [12:34] <jgraham> I have a theory that the most productive place to write documentation is on the train. Maybe I should just go and sit on the circle line for the rest of the day.
# [12:35] <jgraham> (yes, I know you can't actually just go round and round the circle line anymore)
# [12:35] <Ms2ger> Sounds like a theory to be tested
# [12:35] <TabAtkins> I certainly like writing on the train.
# [12:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [12:37] * Joins: adactio (~adactio@212.42.170.181)
# [12:43] <JakeA> annevk: Looking at https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-40742195 - agree the tagging thing is weird, but what can fetchEvent.default() resolve to?
# [12:49] <JakeA> annevk: event.default() could do a fetch but return OpaqueResponse for redirects. Could say that OpaqueResponse redirects don't go back through the serviceworker
# [12:50] <JakeA> feels like trading one kind of magic for another
# [12:51] <annevk> JakeA: I think part of the problem is that you're not observing this from the perspective of how APIs use Fetch (the platform layer, not the API)
# [12:51] <annevk> JakeA: most APIs use Fetch and have it follow redirects
# [12:51] <annevk> JakeA: the navigate action uses Fetch and explicitly tells it to not follow redirects, it's the only part of the platform that does that as far as I know (and maybe AppCache now?)
# [12:52] <annevk> JakeA: so in the typical case all redirects will be followed and you get back a normal Response
# [12:53] <annevk> JakeA: in the navigate case you can already get back an OpaqueResponse as the user can navigate away from your site
# [12:54] <annevk> JakeA: so there we'd hand back an OpaqueResponse for redirects (because Fetch was instructed not to follow them) and allow the navigate action to inspect that and take appropriate action
# [12:55] <annevk> JakeA: but I don't think explaining this in terms of fetch() helps, as that might throw away CSP things, priorities, etc.
# [12:56] <annevk> JakeA: also, there's some things we need to consider with respect to what happens when the user navigates away and the service worker hands back a generated response or some such
# [12:57] <JakeA> annevk: So, if I have <link rel=stylesheet href=blah>, it goes off into the fetch layer, does its redirects, and gives the page its response. How is the base url of the CSS handled, via the response url?
# [12:58] <annevk> JakeA: yes
# [12:59] <annevk> (assuming no service workers in play)
# [13:09] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [13:12] <zcorpan> Hixie: i ran a screenshot of the spec through a color blindness simulator, and it seems OK with protanopia and deuteranopia (1-5% in males), but the link is almost the same as the surrounding text with tritanopia (< 0.003% of males and females)
# [13:12] <zcorpan> (unvisited link, didn't include a visited link in the image)
# [13:14] <wilhelm> jgraham: So like Yamanote parties, just more boring? :D
# [13:15] <zcorpan> http://www.etre.com/simulate.php?image=defa540b013c2e5c3fdfcbd79b63c773&condition=tritanopia&type=jpeg - tritanopia (zoom in, i guess the blurry result can simulate some other visual impairedness :-P)
# [13:18] * Joins: Kolombiken (~Adium@94.137.124.2)
# [13:26] <zcorpan> Hixie: that said, i think the current style is an improvement
# [13:29] <jgraham> wilhelm: I'm not sure I would want to try and work on the Tokyo metro
# [13:33] * Joins: scor (scor@nat/acquia/x-msuwjnnemddsrper)
# [13:33] * Quits: scor (scor@nat/acquia/x-msuwjnnemddsrper) (Changing host)
# [13:33] * Joins: scor (scor@drupal.org/user/52142/view)
# [13:34] * Quits: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
# [13:34] * Quits: scor (scor@drupal.org/user/52142/view) (Client Quit)
# [13:36] <JakeA> annevk: Can I get a sanity check of this? https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-43614413
# [13:38] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
# [13:38] <zcorpan> Hixie: i'm not entirely sure about the :target styling. i think i'd want the arrow and its box to be smaller. some color for that thing seems OK to me
# [13:39] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
# [13:41] <wilhelm> zcorpan: It could be fun to have a designer play with a revision of the stylesheet.
# [13:41] * wilhelm has one in mind. (c:
# [13:42] <zcorpan> wilhelm: like http://developers.whatwg.org ?
# [13:44] <wilhelm> Oh, I hadn't seen that one. That's certainly more readable. (c:
# [13:45] <zcorpan> Hixie: the "next" link at the bottom is a nice thing in the dev version
# [13:45] * Joins: scor (scor@nat/acquia/x-uileqqgtxmhzupup)
# [13:45] * Quits: scor (scor@nat/acquia/x-uileqqgtxmhzupup) (Changing host)
# [13:45] * Joins: scor (scor@drupal.org/user/52142/view)
# [13:49] <annevk> JakeA: looks wrong
# [13:50] <annevk> JakeA: default() just needs to use incoming "fetchStandardRequest" that could have manualRedirect either set to true or false
# [13:50] <zcorpan> benschwarz_: seems like the svg doesn't load/exist in http://developers.whatwg.org/content-models.html#kinds-of-content
# [13:51] <annevk> JakeA: e.g. <img src=...> comes in SW, SW does default(), redirects will be followed
# [13:52] <JakeA> annevk: isn't that correct?
# [13:53] <annevk> JakeA: oh wait, I missed the if statement
# [13:54] <zcorpan> annevk: so <img> is going to be able to load two resources in parallel
# [13:54] <zcorpan> in case that affects things for SW
# [13:54] <annevk> JakeA: even so, there's no castToOpaqueResponse needed, that should be wrapped automagically
# [13:54] <annevk> zcorpan: that'll just be two events quickly after another
# [13:55] <annevk> zcorpan: SW can't do true parallel
# [13:55] * Quits: adactio (~adactio@212.42.170.181) (Quit: adactio)
# [13:56] <annevk> JakeA: as in, the way I think this should work is that .default() just hands the request back to Fetch and Fetch does the rest
# [13:56] <jgraham> wilhelm++ for getting a designer to play with the stylesheet. Although they have to understand the functional requirements (most of the things that have style have it for a reason, but the styles that they have aren't necessarily good)
# [13:57] <annevk> JakeA: and then Fetch hands a Response, potentially Opaque, back to .default()'s promise
# [13:57] <zcorpan> annevk: not sure i follow, but then i basically know nothing about SW :-)
# [13:57] <annevk> zcorpan: the network stack is still on a single thread
# [13:58] <annevk> zcorpan: anyway, it should be fine
# [13:58] <zcorpan> annevk: so you can only fetch one thing at a time in a SW?
# [13:58] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
# [13:58] <annevk> zcorpan: you can queue one thing at a time
# [13:59] <annevk> zcorpan: it's a subtle but important difference, and that's not really limited to SW
# [13:59] <zcorpan> but then you could have mutliple things fetching at the same time?
# [14:00] <annevk> zcorpan: yeah, it's not really different from constructing several XHRs in a row and then invoking send() in them in a row and waiting for data to come back
# [14:01] <zcorpan> ok. so i didn't mean that <img> is able to queue two things in parallel. i meant that it could start fetch A at time T and start fetch B at time T+x which would not necessarily abort A
# [14:02] <wilhelm> jgraham: Indeed. (c:
# [14:03] <annevk> zcorpan: I can't think offhand of places that assume 1 API : 1 fetch
# [14:03] <zcorpan> ok
# [14:03] <annevk> zcorpan: well... sounds like a potential problem for integrity=""
# [14:04] <annevk> zcorpan: and of course you can't control crossorigin for each fetch
# [14:05] <annevk> zcorpan: you might want to email public-webappsec@w3.org with regards to integrity="" I suppose, given that this kind of loading is actually a feature people want to use
# [14:05] <annevk> s/given/provided/
# [14:05] <zcorpan> annevk: do you have a pointer to integrity=""?
# [14:05] <zcorpan> annevk: it's not so much want to use, more required for web compat
# [14:05] <annevk> zcorpan: http://w3c.github.io/webappsec/specs/subresourceintegrity/
# [14:06] <annevk> zcorpan: basically allows you to specify a hash for the resource
# [14:06] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Remote host closed the connection)
# [14:06] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [14:07] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
# [14:09] <zcorpan> so... for example let's say you have <img src=foo integrity=bar> and then, while foo is loading but the dimensions are known, you do .src = 'baz'; .integrity = 'quux'; which starts a pending fetch. then foo completes loading and the UA compares the hash and finds that it doesn't match quux?
# [14:09] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [14:11] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Ping timeout: 258 seconds)
# [14:12] <zcorpan> maybe the integrity thing could check the value of the integrity attribute at the time you resolve the URL or at the time you start the fetch, instead of when you're done fetching
# [14:13] <annevk> zcorpan: it could be an argument for tight coupling the integrity data with the fetch
# [14:14] <zcorpan> seems like it does take the integrity at the time of start of fetch
# [14:15] <zcorpan> also: monkey patching
# [14:15] <annevk> zcorpan: yeah, temporarily
# [14:16] <annevk> Temporarily monkey patching is actually somewhat beneficial, it's just that people don't always follow up on cleaning up
# [14:16] <zcorpan> it seems like the general approach is compatible with <img>'s dual fetching
# [14:16] <zcorpan> yeah
# [14:17] * Quits: jahman (~woops@129.175.204.73) (Remote host closed the connection)
# [14:18] * Quits: IZh (~IZh@213.33.220.118) (Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26/20140428215651])
# [14:18] <zcorpan> do people want to use integrity together with picture/srcset ?
# [14:19] * Joins: jahman (~woops@129.175.204.73)
# [14:19] <annevk> prolly
# [14:19] <zcorpan> <img srcset="foo.jpg 100w integrity(foo), bar.jpg 200w integrity(bar)"> maybe
# [14:20] <annevk> if that works that could be nice
# [14:20] <annevk> can you do url(foo.jpg) too?
# [14:20] <zcorpan> no
# [14:20] <annevk> oh
# [14:21] <annevk> I would expect CSS to end up with fetch(foo.jpg, other stuff here)
# [14:21] <annevk> and deal with integrity that way if we want it there
# [14:22] <zcorpan> can you give an example of how it would work together with some property (like background-image, say)?
# [14:23] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
# [14:24] * Quits: ^esc (~esc-ape@178.115.131.194.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
# [14:26] <annevk> background-image:fetch(foo.jpg, some new syntax)
# [14:26] <jgraham> that's pretty ugly
# [14:27] <jgraham> (using "fetch" there sounds very imperative whereas css is typically declarative)
# [14:29] <zcorpan> annevk: i think foo.jpg will need to be either a string or a url() to remain sanity
# [14:29] <zcorpan> but i also agree with jgraham about the imperative part
# [14:30] <annevk> zcorpan: I'm sort of indifferent on the name and the syntax particulars
# [14:30] <zcorpan> ok
# [14:30] <zcorpan> so now there's a thing called image() in css
# [14:30] <zcorpan> with some new syntax
# [14:30] <annevk> it's more that we need to be able to pass more data along with a URL
# [14:30] <zcorpan> so maybe integrity can go in that
# [14:31] <annevk> can image() be used for SVG subresources and shapes and things?
# [14:31] <annevk> also doesn't work for @import
# [14:33] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
# [14:33] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [14:34] <zcorpan> yeah i guess we've deferred on supporting crossorigin for @import
# [14:37] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
# [14:37] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [14:38] <annevk> :/
# [14:39] <zcorpan> maybe i can bring it up tomorrow
# [14:39] <zcorpan> is there an email somewhere about this?
# [14:39] <annevk> don't think so
# [14:39] <zcorpan> can you send one to www-style? :-)
# [14:39] <annevk> well, there's a long thread on public-fx somewhere
# [14:40] <annevk> regarding what to do with shapes and SVG and what not and how they can all work together
# [14:41] <annevk> how can you figure out if two things happen in the same task?
# [14:42] * zcorpan doesn't follow
# [14:44] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Quit: tav)
# [14:44] <annevk> http://dump.testsuite.org/xhr/upload-events.html I want to know if (upload) "loadend: 1" is in the same task as "xhr onreadystatechange: 2"
# [14:45] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
# [14:46] <annevk> Hmm, in Chrome they are not
# [14:47] * Joins: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp)
# [14:51] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
# [14:51] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 252 seconds)
# [14:53] * Joins: zcorpan (~zcorpan@113.199.41.81)
# [14:55] <zcorpan> annevk: like load() a video in the first event and check the networkState in the second event
# [14:55] <annevk> zcorpan: for next time :-)
# [14:56] <zcorpan> annevk: if it's NETWORK_NO_SOURCE then they were the same task, if it's NETWORK_EMPTY then they were separate tasks
# [14:56] <zcorpan> for a <video> without src or source
# [14:56] * Krinkle|detached is now known as Krinkle
# [14:59] <zcorpan> annevk: do you have a pointer to public-fx thread?
# [15:00] * yoav_ is now known as yoav
# [15:01] <zcorpan> annevk: otherwise, please send a short message to www-style so i can bring it up tomorrow. now i need to sleep
# [15:02] * Joins: tav (~tav`@37.157.36.218)
# [15:03] <annevk> zcorpan: around http://lists.w3.org/Archives/Public/public-fx/2013AprJun/thread.html#msg176
# [15:04] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
# [15:07] * Quits: Areks (~Areks@rs.gridnine.com) (Read error: Connection reset by peer)
# [15:10] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
# [15:11] <zcorpan> annevk: thx
# [15:14] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Client Quit)
# [15:14] * Quits: CvP (~CvP@27.147.199.131) (Ping timeout: 255 seconds)
# [15:15] * Joins: plutoniix (~plutoniix@node-l8i.pool-101-108.dynamic.totbb.net)
# [15:15] * Joins: CvP (~CvP@27.147.199.131)
# [15:15] * Joins: newtron (~newtron@199.71.174.204)
# [15:15] * Quits: newtron (~newtron@199.71.174.204) (Remote host closed the connection)
# [15:16] * Joins: newtron (~newtron@199.71.174.203)
# [15:18] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [15:25] * Quits: zcorpan (~zcorpan@113.199.41.81) (Remote host closed the connection)
# [15:25] * Joins: zcorpan (~zcorpan@113.199.41.81)
# [15:26] * Joins: tj_vantoll (~Adium@2601:4:5380:eba:7c7b:d7ac:5969:7195)
# [15:30] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 240 seconds)
# [15:31] * Quits: tav (~tav`@37.157.36.218) (Quit: tav)
# [15:32] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
# [15:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [15:36] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
# [15:38] * Quits: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e) (Ping timeout: 240 seconds)
# [15:39] <foolip> annevk: but note that <video> doesn't use tasks as per spec in at least WebKit, Blink and Presto, so if it doesn't work be careful about which code to blame :)
# [15:40] <jgraham> foolip: That sounded a lot like "if it doesn't work, blame foolip" :)
# [15:43] * Joins: Areks (~Areks@rs.gridnine.com)
# [15:43] <foolip> jgraham: that wouldn't be entirely unfair :)
# [15:43] * Quits: Areks (~Areks@rs.gridnine.com) (Client Quit)
# [15:44] * Joins: Areks (~Areks@rs.gridnine.com)
# [15:45] * Joins: bholley (~bholley@98.210.101.88)
# [15:45] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [15:47] * Joins: izhak (~izhak@92.248.142.152)
# [15:48] * Joins: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e)
# [15:50] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
# [15:53] <annevk> I wonder what happend to HTTPbis https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097#c0
# [15:53] <JakeA> annevk: if the request is to the same origin, but it responds with a redirect to /somewhere-else/?secret=1234567890, will that be an OpaqueResponse?
# [15:54] <JakeA> annevk: I thought it wouldn't be, which is why I added the cast
# [15:54] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 240 seconds)
# [15:55] <annevk> JakeA: yeah, currently Fetch does not say that because the redirect would not be exposed to script, but once that's an option I'll make sure to do that right at the source
# [15:55] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
# [15:56] <MikeSmith> annevk: yeah I thought I remembered seeing a tweet from Julian months ago that implied it had been sent to the IETF editor for publication
# [15:57] <MikeSmith> annevk: btw html5.org/tools/web-apps-tracker is hanging atm
# [15:58] <annevk> MikeSmith: prolly means svn.whatwg.org is hanging
# [15:58] <annevk> hmm no
# [15:58] * Quits: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
# [15:59] <annevk> MikeSmith: seems to work again
# [16:00] <MikeSmith> annevk: yeah wfm too now
# [16:01] * Joins: bholley (~bholley@98.210.101.88)
# [16:02] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Remote host closed the connection)
# [16:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:06] * Joins: bholley (~bholley@98.210.101.88)
# [16:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:07] * Joins: bholley (~bholley@98.210.101.88)
# [16:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:07] * Joins: bholley (~bholley@98.210.101.88)
# [16:08] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [16:08] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:08] * Joins: bholley (~bholley@98.210.101.88)
# [16:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:09] * Joins: bholley (~bholley@98.210.101.88)
# [16:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:10] * Joins: bholley (~bholley@98.210.101.88)
# [16:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:10] * Quits: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) (Excess Flood)
# [16:11] * Joins: bholley (~bholley@98.210.101.88)
# [16:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:11] * Joins: bholley (~bholley@98.210.101.88)
# [16:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:12] * Joins: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr)
# [16:15] * Joins: bholley (~bholley@98.210.101.88)
# [16:15] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:19] * Joins: bholley (~bholley@98.210.101.88)
# [16:19] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:23] * Quits: mven (~textual@ip68-104-38-84.lv.lv.cox.net) (Ping timeout: 265 seconds)
# [16:24] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [16:25] * Joins: bholley (~bholley@98.210.101.88)
# [16:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:26] * Joins: bholley (~bholley@98.210.101.88)
# [16:26] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:27] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
# [16:28] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 255 seconds)
# [16:28] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [16:31] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
# [16:36] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
# [16:36] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-plzzkzllmyxakhha) (Quit: Connection closed for inactivity)
# [16:37] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [16:37] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Ping timeout: 276 seconds)
# [16:41] <zewt> annevk: whew? (re: dodging another onclick)
# [16:41] <annevk> zewt: I have no idea what is going on
# [16:41] <annevk> zewt: I blame DOM Level 3 Events for not cleaning this up
# [16:41] <zewt> i think we should discourage people from ever using the phrase "default action"
# [16:42] <annevk> I have been trying to call it out each time I see it
# [16:42] <annevk> zewt: what onclick behavior though?
# [16:42] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
# [16:42] <zewt> the fact that onclick does have "in-dispatch" behavior
# [16:43] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [16:43] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
# [16:43] <zewt> i think we need a new name for that, to clearly distinguish it from what people think of as "default actions"
# [16:44] <annevk> zewt: pointer to the spec for that? I think I'm missing something
# [16:44] <JakeA> annevk: if a fetch is performed as part of a navigation, is the responses url redundant?
# [16:44] <zewt> i don't know if it's specced anywhere
# [16:44] <JakeA> response's*
# [16:44] <annevk> JakeA: could still be relevant if the SW returned something unexpected
# [16:45] <JakeA> annevk: like?
# [16:45] <annevk> JakeA: navigate to /bar SW returns response for http://www.google.com/
# [16:46] <zewt> annevk: https://zewt.org/~glenn/test-stupid-click-event.html
# [16:46] <JakeA> annevk: I think the exception there is OpaqueResponse, not url
# [16:46] <Domenic> annevk: I think it was good guidance that events are for notification, not actions. I hadn't read that anywhere before.
# [16:46] * Joins: bholley (~bholley@98.210.101.88)
# [16:46] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:47] <annevk> JakeA: it's not really an exception
# [16:47] <annevk> JakeA: but it would be a CORSResponse
# [16:47] <JakeA> That's fine though, isn't it?
# [16:47] * Joins: bholley (~bholley@98.210.101.88)
# [16:47] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:47] <annevk> JakeA: but in that case you want to look at the url of the response
# [16:47] <zewt> i think there are a couple other events like that but I don't know what they are
# [16:47] <annevk> JakeA: you being the navigate algorithm
# [16:48] <annevk> Domenic: yeah, maybe I should add that more explicitly to the DOM specification
# [16:48] <zewt> i wonder if that could be explained in terms of capturing the event on the link, then queuing a task to look at defaultPrevented after the event finishes... probably not, since that could be broken by stopPropagationImmediate
# [16:48] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [16:49] <Domenic> annevk: +1, that would be excellent.
# [16:50] <annevk> zewt: so when I tested myself I forgot to generate an event that is a MouseEvent
# [16:50] <zewt> sorry, I thought we talked about this before or I'd have made more noise about it
# [16:50] <JakeA> annevk: I'm wondering if we can ditch fetchEvent.default(). If subresources have a base url of response.url, but navigations use window.location.href (as in, what's in the url bar), I don't think we need .default()
# [16:51] <Domenic> annevk: oh wow, i was wondering when someone would bring up the ArrayBuffer mess
# [16:52] <annevk> JakeA: default() is for preserving the request instance
# [16:53] <annevk> JakeA: so you preserve e.g. that redirects are not to be followed
# [16:53] <annevk> JakeA: and that CSP applies
# [16:54] <annevk> zewt: HTML has a bunch of stuff around "synthetic click"
# [16:56] <annevk> Domenic: I'm not sure what is going on there
# [16:56] * Joins: bholley (~bholley@98.210.101.88)
# [16:56] <annevk> Domenic: or how their implementations have been moved to ES without anyone else noticing this
# [16:56] <zewt> html spec seems to be thrashing chrome on load way more than it was
# [16:56] <Domenic> annevk: my guess is that they only looked at the Khronos spec, which doesn't contain neutering? (Is that true?)
# [16:57] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:57] <zewt> heh now I'm scrolling the spec and getting a transparent background
# [16:57] * Joins: bholley (~bholley@98.210.101.88)
# [16:57] <annevk> Domenic: no Khronos defines what to do when something is neutered
# [16:57] <annevk> Domenic: http://www.khronos.org/registry/typedarray/specs/latest/
# [16:57] <JakeA> annevk: hmm, true
# [16:57] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:57] <zewt> annevk: there's "synthetic click activation steps", which has nothing to do with events I think
# [16:58] * Joins: bholley (~bholley@98.210.101.88)
# [16:58] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:58] <zewt> (click-like things to do when other things happen, not when the user dispatches his own click event)
# [16:58] * Joins: bholley (~bholley@98.210.101.88)
# [16:59] <Domenic> annevk: welp... more cases where Allen is not properly integrating with existing systems, IMO.
# [16:59] * Domenic is still disgruntled about ES tasks vs. HTML microtasks
# [16:59] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [16:59] <zewt> why would the language level have tasks? that doesn't even make sense
# [16:59] * Joins: bholley (~bholley@98.210.101.88)
# [16:59] <zewt> tasks are part of the event loop, which don't belong at the language layer
# [16:59] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
# [17:00] <annevk> zewt: how can you have asynchronous language then?
# [17:00] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:00] <zewt> that doesn't belong at the language layer either
# [17:00] * Joins: bholley (~bholley@98.210.101.88)
# [17:00] <annevk> zewt: I think you're right that HTML basically does not define this; I slowly start to remember a long time ago when we looked at this and decided it was for DOM Level 3 Events to define and that of course never happened
# [17:00] <annevk> zewt: see async/await syntax
# [17:00] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:01] * Joins: bholley (~bholley@98.210.101.88)
# [17:01] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
# [17:01] <zewt> especially here, where the web has a complex event loop mechanism; the language is at a lower layer than it
# [17:01] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:01] <zewt> annevk: i don't think an external spec could define it without monkey patching, since it seems to need a hook in dispatchEvent
# [17:02] * Joins: bholley (~bholley@98.210.101.88)
# [17:02] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
# [17:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:02] * Joins: bholley (~bholley@98.210.101.88)
# [17:03] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:03] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
# [17:03] * Joins: bholley (~bholley@98.210.101.88)
# [17:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:04] * Joins: bholley (~bholley@98.210.101.88)
# [17:04] <annevk> zewt: I found https://www.w3.org/Bugs/Public/show_bug.cgi?id=10897
# [17:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:05] * Joins: bholley (~bholley@98.210.101.88)
# [17:05] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
# [17:05] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:05] * Joins: bholley (~bholley@98.210.101.88)
# [17:06] <zewt> don't think the popup counterexample is valid (just check the trusted flag)
# [17:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:06] * Joins: bholley (~bholley@98.210.101.88)
# [17:06] <zewt> i wrote code myself that dispatched click myself (before I knew what I was doing), so it seems guaranteed that other people have too
# [17:07] * Joins: ehynds (~ehynds@64.206.121.41)
# [17:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:07] <zewt> (i was capturing events on document, cancelling them, doing other stuff, then re-dispatching them later; it worked for click, and I recall being annoyed that it didn't work with submit)
# [17:07] <annevk> zewt: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 seems to be master bug
# [17:07] * Joins: bholley (~bholley@98.210.101.88)
# [17:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:08] <zewt> (it does work with submit? maybe it was some other event I had trouble with)
# [17:09] * Joins: bholley (~bholley@98.210.101.88)
# [17:09] <zewt> or maybe not (according to comment 10); retesting...
# [17:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:09] * Joins: bholley (~bholley@98.210.101.88)
# [17:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:10] * Joins: bholley (~bholley@98.210.101.88)
# [17:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:11] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [17:11] * Joins: bholley (~bholley@98.210.101.88)
# [17:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:12] * Joins: bholley (~bholley@98.210.101.88)
# [17:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:12] <zewt> submits for me in firefox, but not chrome
# [17:12] * Joins: bholley (~bholley@98.210.101.88)
# [17:13] <zewt> (maybe that's what I was annoyed about--probably wrote the code in firefox first)
# [17:13] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:13] <zewt> (test at same url)
# [17:13] <dglazkov> good morning, Whatwg!
# [17:13] * Joins: bholley (~bholley@98.210.101.88)
# [17:14] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:14] * Joins: bholley (~bholley@98.210.101.88)
# [17:14] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:15] * Joins: bholley (~bholley@98.210.101.88)
# [17:15] <caitp> i need to script my client to say good morning like that in every channel, it's so charming
# [17:15] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:15] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
# [17:15] <JakeA> annevk: if I do event.respondWith(caches.match('/fallback.html')), what's the base url for the resulting page (assuming no <base> element)? Is it event.request.url or the cachedRepsonse.url?
# [17:15] <zewt> (don't, it's really annoying; highlights everyone's window for no reason)
# [17:15] * Joins: jsbell (jsbell@nat/google/x-jrbkufctaojtophx)
# [17:16] * Joins: bholley (~bholley@98.210.101.88)
# [17:16] <JakeA> annevk: Feels like it should be the former
# [17:16] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:16] * Joins: bholley (~bholley@98.210.101.88)
# [17:17] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:17] <annevk> JakeA: yes
# [17:17] * Joins: bholley (~bholley@98.210.101.88)
# [17:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:19] <annevk> JakeA: I think we jotted this on the etherpad at some point
# [17:19] * Joins: bholley (~bholley@98.210.101.88)
# [17:19] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:19] * Joins: bholley (~bholley@98.210.101.88)
# [17:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:20] <JakeA> annevk: What if fetch(request) didn't follow redirects if the context was one of the navigation ones? Then the only benefit of event.default() is CSP, right?
# [17:20] * Joins: bholley (~bholley@98.210.101.88)
# [17:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:21] * Joins: bholley (~bholley@98.210.101.88)
# [17:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:22] * Joins: bholley (~bholley@98.210.101.88)
# [17:22] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:23] * Joins: bholley (~bholley@98.210.101.88)
# [17:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:23] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
# [17:23] <annevk> JakeA: prioritization
# [17:23] * Joins: bholley (~bholley@98.210.101.88)
# [17:24] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:24] * Joins: bholley (~bholley@98.210.101.88)
# [17:25] * Joins: NDoc (~NDoc@68.80.107.173)
# [17:25] <annevk> JakeA: oh, and default() follows redirects for subresources and updates the resulting url
# [17:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:25] * Joins: bholley (~bholley@98.210.101.88)
# [17:25] <annevk> JakeA: e.g. if you do respondWith(fetch("something-that-redirects")) it wasn't clear to me we'd use the response's url as base URL
# [17:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:26] * Joins: bholley (~bholley@98.210.101.88)
# [17:26] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 255 seconds)
# [17:26] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:26] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
# [17:27] * Joins: bholley (~bholley@98.210.101.88)
# [17:27] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:27] * Joins: bholley (~bholley@98.210.101.88)
# [17:27] <JakeA> annevk: I think using the responses url as base url for non-navigations is fine. I wasn't keen on that at first, but it fits in with the fetch spec nicely
# [17:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:28] * Joins: bholley (~bholley@98.210.101.88)
# [17:28] <annevk> but not with typical server setups
# [17:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:29] * Joins: bholley (~bholley@98.210.101.88)
# [17:29] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:30] * Joins: bholley (~bholley@98.210.101.88)
# [17:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:30] * Joins: bholley (~bholley@98.210.101.88)
# [17:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:31] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Ping timeout: 240 seconds)
# [17:32] * Joins: bholley (~bholley@98.210.101.88)
# [17:32] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:32] <JakeA> annevk: yeah, the concept of responses with a url property felt really alien to me at first
# [17:33] * Joins: bholley (~bholley@98.210.101.88)
# [17:33] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:33] <JakeA> annevk: But then, in a typical server setup, the base url would be event.request.url, but if I did event.respondWith(fetch(url)) the base would be url & not event.request.url, right?
# [17:33] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [17:34] <JakeA> unless respondWith overrides the response url, but then how can it tell the difference between event.default() and fetch()
# [17:34] * Joins: bholley (~bholley@98.210.101.88)
# [17:34] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:35] * Quits: NDoc (~NDoc@68.80.107.173) (Quit: leaving)
# [17:35] * Quits: jsbell (jsbell@nat/google/x-jrbkufctaojtophx) (Quit: There's no place like home...)
# [17:36] * Quits: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e) (Ping timeout: 240 seconds)
# [17:37] <Domenic> response URLs make sense to me, they're the URL after all redirects, right?
# [17:37] * Joins: KevinMarks (~yaaic@2607:fb90:2201:a156:fbd2:98bc:7719:330)
# [17:38] <JakeA> Domenic: yeah, but they don't exist in the traditional client/server model
# [17:39] <Domenic> JakeA: right, but there's a difference between ClientRequest/ClientResponse and ServerRequest/ServerResponse
# [17:39] <Domenic> if writing a web server, you use the latter; if sending requests as a client, you use the former
# [17:39] <Domenic> Node.js actually has 4 different classes for this
# [17:39] * Joins: bholley (~bholley@98.210.101.88)
# [17:39] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [17:40] <annevk> JakeA: Fetch uses the latest url of Request, as url for Response
# [17:40] <annevk> JakeA: but note that SW sits a layer deeper
# [17:40] <annevk> JakeA: so the latest url of Request is the one that the SW was opened for
# [17:41] <annevk> JakeA: if you use default() however, the url of that Request will be updated further
# [17:41] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [17:42] <JakeA> Domenic: right, so here's the question, if I do fetchEvent.respondWith(fetch(url)), assuming the fetch is for some CSS, what's the base-url for the response? a) fetchEvent.request.url b) url c) the final redirect while fetching url
# [17:44] <Domenic> JakeA: I don't feel qualified to give an answer that fits well with the rest of the moving parts involved, but my gut instinct is c).
# [17:45] * Joins: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [17:45] <JakeA> Domenic: Gut instinct is fine. I think my original instinct was a), but I'm coming round to c)
# [17:47] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
# [17:47] <JakeA> annevk: wouldn't fetch take the response url from response.url, as provided by the serviceworker?
# [17:52] * Quits: ehynds (~ehynds@64.206.121.41)
# [17:52] * Quits: tj_vantoll (~Adium@2601:4:5380:eba:7c7b:d7ac:5969:7195) (Quit: Leaving.)
# [17:53] <gavin> TabAtkins: blame pisg, probably
# [17:53] * Joins: tav (~tav`@37.157.36.218)
# [17:54] <annevk> JakeA: not how it's currently written
# [17:56] * Joins: ehynds (~ehynds@64.206.121.41)
# [17:56] <annevk> JakeA: I feel like I/we should create a series of examples of request / response flows when there's a SW and figure out what all the various parties want to know
# [17:56] <JakeA> annevk: I'll make a ticket to try and summarise this. I'd love to kill event.default() if we can
# [17:57] <annevk> JakeA: I was hoping that would be done as part of providing hooks for Fetch, but I can take a stab at it too I suppose
# [17:57] <annevk> JakeA: killing that does not make much sense to me, I'd prefer we focus on understanding the problem space first
# [17:58] <JakeA> annevk: Ok, I'll provide examples in the ticket and see what we're left with
# [17:59] * htmelvis_zzz is now known as htmelvis
# [18:01] * Joins: bholley (~bholley@98.210.101.88)
# [18:01] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:02] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
# [18:02] * Joins: bholley (~bholley@98.210.101.88)
# [18:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:02] * Quits: tav (~tav`@37.157.36.218) (Quit: tav)
# [18:02] * Joins: bholley (~bholley@98.210.101.88)
# [18:03] * Quits: izhak (~izhak@92.248.142.152) (Quit: exit(0);)
# [18:03] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:03] * Joins: bholley (~bholley@98.210.101.88)
# [18:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:05] <JakeA> annevk: event.default(), .installing/waiting/active/controller, and serviceWorker.waitUntil are keeping me awake at night
# [18:05] * Joins: bholley (~bholley@98.210.101.88)
# [18:05] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:06] * Joins: bholley (~bholley@98.210.101.88)
# [18:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:07] * Joins: bholley (~bholley@98.210.101.88)
# [18:08] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:08] * Joins: bholley (~bholley@98.210.101.88)
# [18:09] <Domenic> JakeA: this reminds me, we need to figure out our story for .loaded vs. .loaded()
# [18:09] <Domenic> I was going to comment in bug, I should probably do that so that there's a record.
# [18:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:09] <Domenic> but basically https://github.com/w3ctag/promises-guide/issues/25
# [18:09] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [18:11] * Joins: bholley (~bholley@98.210.101.88)
# [18:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:11] <Hixie> why would loaded() be a method?
# [18:11] <Hixie> shouldn't there be one promise per load attempt?
# [18:12] <Hixie> the FontFace API approach seems sensible
# [18:12] * Joins: bholley (~bholley@98.210.101.88)
# [18:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:12] * Quits: richt__ (~richt@83.218.67.123) (Remote host closed the connection)
# [18:13] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
# [18:13] <JakeA> There was a conversation around this earlier http://krijnhoetmer.nl/irc-logs/whatwg/20140520#l-395
# [18:14] <Hixie> yes that's what led to my question
# [18:14] <JakeA> Doing the same as FontFace is compelling
# [18:15] * Joins: lmclister (~lmclister@192.150.10.210)
# [18:15] <Hixie> well they should clearly be consistent, but if a method makes more sense thenwe should do that
# [18:15] <Hixie> i just don't see why a method would make sense here
# [18:15] <Hixie> since it's vending the same value each time
# [18:15] <Hixie> a method implies that work is done
# [18:15] <Hixie> whereas here no work is done except "return the cached value"
# [18:15] <JakeA> well, the value can change
# [18:15] <JakeA> if .src is changed
# [18:15] <JakeA> but that's easy enough
# [18:16] <Hixie> right, but that's the .src setter doing work
# [18:16] <JakeA> yeah
# [18:16] <Hixie> not loaded()/.loaded
# [18:16] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:16] <Hixie> in totally different news, i must admit to something. this no-underline style is actually growing on me. i was clearly wrong about that.
# [18:17] <JakeA> For the record, I've never found a style-related readability problem with the html spec. Except for that bit where there was a gradient at the top. Those were dark times for the web.
# [18:17] <Hixie> the backgrounds on examples and notes are prettier too.
# [18:18] * Joins: bholley (~bholley@98.210.101.88)
# [18:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:18] <Hixie> JakeA: there's actually a gradient there still. :-D
# [18:18] <Hixie> JakeA: and yeah, me either, but we consistently get feedback about it
# [18:19] <Hixie> JakeA: i did a survey a few months ago, and it was funny, i got a bunch of feedback "this spec is really pretty" and a bunch of feedback "this spec is really ugly"
# [18:19] * Joins: ap (~ap@2620:149:4:304:60b2:7b5b:c970:cd45)
# [18:19] <JakeA> ohh, the gradient is at the bottom now. Hadn't noticed that
# [18:20] <Hixie> i figured it was more subtle than the line that we had before
# [18:20] * Joins: bholley (~bholley@98.210.101.88)
# [18:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:20] <Hixie> (the line got harder to do right after i added a max-width on body)
# [18:20] * Joins: bholley (~bholley@98.210.101.88)
# [18:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:21] * Joins: bholley (~bholley@98.210.101.88)
# [18:21] * Quits: ehynds (~ehynds@64.206.121.41)
# [18:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:22] * Joins: bholley (~bholley@98.210.101.88)
# [18:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:24] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
# [18:28] * Joins: bholley (~bholley@98.210.101.88)
# [18:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:28] * Joins: bholley (~bholley@98.210.101.88)
# [18:29] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:29] * Joins: bholley (~bholley@98.210.101.88)
# [18:30] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 265 seconds)
# [18:30] <TabAtkins> Hixie: FontFace returns a promise from the .load() method, but also exposes a .loaded promise for when you want to listen for the load status without actually triggering a load.
# [18:30] <Hixie> right
# [18:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:30] <Hixie> same promise right?
# [18:30] <Hixie> .loaded just returns the last value .load() created?
# [18:30] * Joins: bholley (~bholley@98.210.101.88)
# [18:31] <TabAtkins> No, it was easier to just return a fresh promise that is resolved to the .loaded promise.
# [18:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:31] <Hixie> that seems confusing
# [18:31] <Hixie> why would it be easier?
# [18:31] * Joins: bholley (~bholley@98.210.101.88)
# [18:31] <TabAtkins> .loaded is the same promise all the time.
# [18:31] <TabAtkins> .load() returns fresh promises, I think. Lemme see...
# [18:31] <Hixie> until the next load, right?
# [18:31] <TabAtkins> A given font only loads once.
# [18:31] <Hixie> ah ok
# [18:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:31] * Joins: Somatt_wrk (~somattwrk@130.193.24.135)
# [18:32] <Hixie> well then why have more than one promise?
# [18:32] <Hixie> just have The One Promise Of The FontLoad Object
# [18:32] <TabAtkins> Oh, no, they all return the same promise.
# [18:32] <TabAtkins> Yes.
# [18:32] <Hixie> or if you're doing it the JS style, [[The One Promise Of The FontLoad Object]]
# [18:32] * Joins: bholley (~bholley@98.210.101.88)
# [18:32] <TabAtkins> Every call to .load() returns the .loaded promise.
# [18:32] <TabAtkins> That's the [[FontStatusPromise]]
# [18:32] <Hixie> called it
# [18:32] <Hixie> :-P
# [18:32] <TabAtkins> hehe
# [18:32] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:33] * Joins: bholley (~bholley@98.210.101.88)
# [18:33] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:33] <Domenic> I dunno, I kind of feel that for things that could change, a method might be better?
# [18:34] * Joins: bholley (~bholley@98.210.101.88)
# [18:34] <Domenic> That way, if it's a property, it's the same every time, whereas if it's a method, it's more like "getPromiseForNextTransitionToLoadedState()"
# [18:34] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:34] <Domenic> except we shorten that to ".loaded()"
# [18:34] * Joins: bholley (~bholley@98.210.101.88)
# [18:35] <Domenic> (or, "whenLoaded()" or "waitForLoad()"??)
# [18:35] <Hixie> when* and wait* are ugly
# [18:35] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:35] <Domenic> when doesn't seem so bad. but yes.
# [18:35] <Hixie> but i don't understand what you mean
# [18:35] <Hixie> attributes can change
# [18:35] * Joins: bholley (~bholley@98.210.101.88)
# [18:36] <Hixie> if they couldn't, we'd call them constants :-)
# [18:36] <Hixie> the thing to avoid with attributes is not that they change when state changes, but that they change every time they are called
# [18:36] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:36] <Hixie> that is, the getter should be idempotent
# [18:36] <Domenic> yeah, that's true
# [18:36] <Hixie> but that's all really
# [18:36] <Domenic> i think i am just trying to use the method vs. attribute designation to signal something only tangentially-related
# [18:37] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
# [18:37] <Domenic> i.e. we have to classes of these promises: "generic state transitions" for state machines that could go back and forth, or "intrinsic properties of the object" for whether something has completed its one-time transition from not-loaded to loaded, or similar.
# [18:38] <Domenic> s/to/two
# [18:38] * Joins: bholley (~bholley@98.210.101.88)
# [18:38] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:39] <Domenic> but the methods i am proposing are definitely not actions, so that's a point against methods
# [18:39] <Domenic> most getter-methods get named with a `get` prefix, and `.getLoaded()` is horrible...
# [18:40] <Domenic> .nextLoad property maybe??
# [18:40] <TabAtkins> Domenic: In support of your point, the promise for "are there are pending font loads, or are we cool?" is returned by a method.
# [18:40] <Domenic> or i can just be ok with the fact that there will be slightly different types of promises returned, both by getters...
# [18:40] <Hixie> i think we should be consistent between one-shot objects and reusable objects, and for one-shot objects "nextLoad" is confusing
# [18:41] * Joins: ehsan (~ehsan@66.207.208.102)
# [18:41] <Hixie> 'loaded' seems fine to me
# [18:41] <TabAtkins> I return a fresh promise with every call there, though.
# [18:41] <Domenic> Hixie: I think it is exactly that consistency I am arguing against, actually.
# [18:41] <JakeA> await document.ready
# [18:41] <TabAtkins> I made most of these choices without conscious attempts at consistency, though.
# [18:41] <Hixie> most reusable objects are treated by most authors as one-shot objects
# [18:41] <Domenic> that is true
# [18:42] <Hixie> so i don't think optimising e.g. img for people using it for multiple loads is a good idea
# [18:42] * Joins: bholley (~bholley@98.210.101.88)
# [18:42] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:42] <Domenic> i kind of liked the idea of force-feeding authors the knowledge that they are reusable, heh.
# [18:42] <Domenic> but in practice, thinking about the dev experience, i guess it's bad
# [18:43] <Domenic> you have to keep a table in your head of reusable vs. one-shot objects
# [18:43] * Joins: bholley (~bholley@98.210.101.88)
# [18:43] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:43] <Domenic> "use .nextLoad for img, but .loaded for documents..."
# [18:43] <Domenic> or, probably worst, "use .loaded() for img, but .loaded for documents..."
# [18:44] <JakeA> "await img.loaded" seems better than "await img.nextLoad"
# [18:44] <caitp> it doesn't really matter what the API looks like, it's going to both suck and be adequate and even enjoyable simultaneously, depending on who uses it and what problem they're solving
# [18:44] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
# [18:45] <JakeA> I might get a tattoo of that
# [18:45] <Hixie> Domenic: documents can be reused
# [18:45] <Domenic> welp
# [18:45] <Domenic> what *can't* be reused, actually...
# [18:45] <Hixie> which i think is a solid argument against making a distinction in the api :-)
# [18:46] * Joins: bholley (~bholley@98.210.101.88)
# [18:46] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:46] <Hixie> even xhr can be reused
# [18:46] <Hixie> websocket can't
# [18:48] * Joins: bholley (~bholley@98.210.101.88)
# [18:49] <Domenic> JakeA: you have too many internet names
# [18:50] <JakeA> Domenic: yeahhhhh, I should probably drop the jaffathecake thing
# [18:50] <caitp> why would you want to do that
# [18:51] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
# [18:51] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [18:52] <JakeA> consistency?
# [18:53] <JakeA> it's all the rage these days
# [18:53] <Hixie> it's been "all the rage" for a long time :-)
# [18:53] <JakeA> how appropriate!
# [18:54] <caitp> every nickname is just a different expression of a different facet of a different side of your personality's current mood, as it should be
# [18:55] * Joins: ehsan (~ehsan@66.207.208.102)
# [18:57] * Quits: Somatt_wrk (~somattwrk@130.193.24.135) (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
# [18:58] * Joins: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net)
# [18:59] * Joins: weinig (~weinig@17.202.50.223)
# [19:02] * Joins: mven (~textual@169.241.49.196)
# [19:03] * Joins: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch)
# [19:03] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Read error: Connection reset by peer)
# [19:03] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
# [19:07] * Joins: aiglesias (~aiglesias@147-195-17-190.fibertel.com.ar)
# [19:09] * Quits: weinig (~weinig@17.202.50.223) (Quit: weinig)
# [19:11] * Joins: weinig (~weinig@17.114.217.5)
# [19:18] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
# [19:19] * Joins: jsbell (jsbell@nat/google/x-pvabvuvmhmtwilyw)
# [19:20] * Joins: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net)
# [19:20] * Joins: jernoble (~jernoble@17.202.46.221)
# [19:20] * Quits: KevinMarks (~yaaic@2607:fb90:2201:a156:fbd2:98bc:7719:330) (Ping timeout: 240 seconds)
# [19:22] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
# [19:27] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Ping timeout: 240 seconds)
# [19:29] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [19:29] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [19:29] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
# [19:31] <Hixie> Domenic: i don't understand why you keep saying "JavaScript does not make such a distinction"
# [19:32] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [19:33] <Hixie> Domenic: it doesn't make a distinction between functions that return a value and functions that don't return a value either, but i hope you agree that to programmers they are different things nonetheless.
# [19:33] <Ms2ger> No
# [19:33] * Ms2ger ducks
# [19:34] <Hixie> Ms2ger: context is https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-43657022
# [19:34] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
# [19:34] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
# [19:34] <Domenic> I don't agree with that. All functions return a value; sometimes that value is `undefined`.
# [19:34] <Ms2ger> See?
# [19:34] <Hixie> ...
# [19:35] <Hixie> Domenic: that is entirely my point.
# [19:35] <Hixie> Domenic: all functions return something in JS. but programmers ignore the return values of functions that return undefined.
# [19:35] <Hixie> they are different to the programmer.
# [19:35] <Ms2ger> inb4 "No"
# [19:35] <Domenic> Sure. But language-level features do not do different things with undefined-returning functions vs. anything-else-returning functions.
# [19:35] <caitp> where would we be if we weren't putting a reference to an undefined JSValue into EAX after every function call
# [19:35] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
# [19:36] <caitp> it would be chaos
# [19:36] * Quits: weinig (~weinig@17.114.217.5) (Quit: weinig)
# [19:36] <Hixie> Domenic: i don't understand the relevance of your statement
# [19:36] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 240 seconds)
# [19:37] <Domenic> Hixie: Language-level features like promises are not designed to handle different types of errors in different ways
# [19:37] <Domenic> Hixie: all errors that an async function can result in go through the promise, just like all errors that a sync function can throw get bubbled as exceptions
# [19:37] * Joins: cheron (~cheron@unaffiliated/cheron)
# [19:37] <Domenic> We don't e.g. return some as return values and some as thrown exceptions
# [19:37] <Hixie> Domenic: well, a, promised shouldn't be a language-level feature imho. but b, yes, that's the bug.
# [19:37] <Domenic> We just throw them all
# [19:37] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [19:38] <Hixie> Domenic: i understand what you want. i'm saying it's bad.
# [19:38] <Domenic> So similarly deciding to use throw vs. reject as a channel to interject your preference for dividing up errors into two categories is not really good language design
# [19:38] <Domenic> ok. well I am saying it's good.
# [19:38] <Hixie> i pretty fundamentally disagree here.
# [19:38] <Domenic> I can offer years of experience working with promise APIs, if it helps?
# [19:39] <Hixie> it does not.
# [19:39] <Ms2ger> Your brain must be fried by now :)
# [19:39] <Hixie> Domenic: did some promise APIs send TypeErrors on the promises?
# [19:39] * Joins: weinig (~weinig@17.114.217.5)
# [19:39] <Domenic> Hixie: of course, whenever there was a TypeError.
# [19:40] <Hixie> how did you implement that?
# [19:40] <Domenic> I don't understand the question
# [19:41] <Hixie> well your years of using promises in JS had to be built on top of a non-promise-native JS, right?
# [19:41] <Domenic> sure
# [19:41] <Hixie> and you had IDL-like APIs that did type checking?
# [19:41] <Domenic> in some cases, yeah
# [19:42] <Hixie> so how did you send the type checks to the promises? they'd be caught before the function's code ran.
# [19:42] <Domenic> wait what?
# [19:42] <Domenic> i'm in javascript; there are no type checks before the function's code runs
# [19:42] <Domenic> the functions code is the thing doing the type checks
# [19:42] <Hixie> maybe that's where the disagreement stems from
# [19:42] <Hixie> i'm not in JavaScript.
# [19:42] <Hixie> i'm in WebIDL.
# [19:43] <Domenic> Which is a macro system for writing JavaScript ;)
# [19:43] <Hixie> not really, it's usually implemented in C++.
# [19:43] <Domenic> Yes, but that C++ just invokes JS engine C++ APIs
# [19:43] <Ms2ger> Or Rust
# [19:43] <Domenic> And the spec is done in terms of JS semantics
# [19:43] <Hixie> i'm finding it hard to express just how much i would hate to use an API where a type error would get sent to a promise.
# [19:43] <Hixie> i hate it enough that it's run-time not compile-time
# [19:44] * Quits: weinig (~weinig@17.114.217.5) (Ping timeout: 240 seconds)
# [19:44] <Hixie> but this is like an order of magnitude worse.
# [19:44] <Domenic> i mean, i can say the same thing about how much i would hate apis that force me to handle errors through two channels
# [19:44] <Hixie> you don't have to handle the errors i'm talking abuot.
# [19:44] <Hixie> that's the _entire_ point.
# [19:44] <Domenic> you do!
# [19:44] <Domenic> when building robust systems, you *definitely* need to handle errors
# [19:44] * Joins: weinig (~weinig@17.202.50.223)
# [19:44] <caitp> why not push for dart then, then you can at least get some level of static typechecking and throw these errors during parsing/compilation rather than at runtime
# [19:44] <Hixie> (dart's not even remotely enough.)
# [19:44] <caitp> change the web!
# [19:45] <caitp> I joke, I joke
# [19:45] <Hixie> Domenic: if you call a function with bogus data, but the bogus data is not fatal, then you're just going to call more and more functions with that bogus data. it's going to propagate the errors throughout the system.
# [19:45] <Hixie> Domenic: if you instead throw an exception, the code will crash.
# [19:45] <Hixie> Domenic: and the damage will be limited.
# [19:46] <Domenic> rejections are just as fatal to async systems as exceptions are to sync ones
# [19:46] <Domenic> you literally cannot do any more work until you handle the rejection
# [19:46] <Hixie> no they're not
# [19:46] <Hixie> sure you can
# [19:46] <Hixie> var promise = func();
# [19:46] <Hixie> moreCode();
# [19:46] <caitp> presumably if you get a rejection that you care about, you don't recover
# [19:46] <Domenic> you cannot do any more work that depends on the result of that computation
# [19:47] <Hixie> sure, but you can do lots more work with the original bad data.
# [19:47] <caitp> you don't always care about rejections
# [19:47] <Domenic> caitp: you recover, or don't recover, in the same way you would at sync code: add judicious catches at the boundaries of the system to encapsulate parts that can be wrapped and retried/signaled to the user without breaking the rest of the program.
# [19:47] <caitp> that's what I'm saying
# [19:47] <caitp> it's not too different from regular try/catch
# [19:47] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
# [19:47] <Domenic> it's exactly the same :)
# [19:48] <Hixie> you don't have to recover from logic errors at all in sync code. The code is bad. There's by definition no way to recover sanely. The best you can do is catch onerror and send a report to the server, then tell the user that the code is bad.
# [19:48] <Domenic> that's just not true. you can easily recover from logic errors
# [19:48] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
# [19:48] <Domenic> this keeps webpages running without breaking at the first sign of things going wrong
# [19:48] <caitp> there are a lot of errors that you can recover from
# [19:48] <caitp> like JSON.parse() throwing
# [19:48] <Hixie> JSON.parse() throwing isn't a logic error.
# [19:48] <caitp> not everything is necessarily fatal
# [19:48] <Hixie> it's a data error.
# [19:49] <Hixie> i'm talking about things like null derefs, calling a function with the wrong arguments, etc.
# [19:49] <Hixie> stuff that should never have gotten checked in in the first place.
# [19:49] <Domenic> there is no distinction.
# [19:49] <Domenic> (in JavaScript)
# [19:49] <Hixie> agreed
# [19:49] <Hixie> the distinction is a programmer-level distinction.
# [19:49] <Hixie> even more important.
# [19:50] <Domenic> the user can click into a rare code path that generates a TypeError, and it's nice to be able to say "oops, we couldn't load the current bid right now!" without crashing the entire app/server.
# [19:50] <Domenic> you'd give the same error for a NetworkError
# [19:50] <caitp> much like you can distinguish from a catch block, you can also distinguish from a rejection handler
# [19:50] <caitp> at the programmer-level
# [19:50] <Domenic> yeah, in both cases, you might log the NetworkError, but not the TypeError, to the server.
# [19:50] * Joins: barnabywalters (~barnabywa@89.17.128.127)
# [19:51] <Domenic> er,,, other way around
# [19:51] <Hixie> the distinction is at the API level, and it does exist.
# [19:51] <Hixie> it's the difference between firing onerror and throwing, today.
# [19:51] * Quits: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net) (Quit: Leaving.)
# [19:51] <Hixie> all i'm saying is that I want my APIs to maintain that difference.
# [19:51] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
# [19:52] <caitp> maybe some day people will be happy with mobile phones statically analyzing scripts for their applications before running, so that they can throw typeerrors that might never be reached
# [19:52] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Ping timeout: 258 seconds)
# [19:53] <Ms2ger> Hixie, why do you want to set JS back to the stone age?
# [19:53] * Hixie feeds Ms2ger
# [19:53] <caitp> > implying it ever left the stone age
# [19:54] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [19:55] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [19:57] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
# [20:02] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [20:03] * Joins: mven (~textual@169.241.49.196)
# [20:03] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
# [20:04] * Joins: BigBangUDR (~Thunderbi@101.57.10.135)
# [20:04] * Quits: BigBangUDR (~Thunderbi@101.57.10.135) (Client Quit)
# [20:04] * Quits: mven (~textual@169.241.49.196) (Max SendQ exceeded)
# [20:05] * Joins: mven (~textual@169.241.49.196)
# [20:05] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [20:06] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
# [20:06] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
# [20:10] * Quits: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
# [20:11] <jtcranmer> Domenic: ping
# [20:11] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [20:12] * Joins: KevinMarks (~yaaic@2607:fb90:40d:e3e1:4896:1887:aad1:4657)
# [20:13] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
# [20:13] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [20:14] * Joins: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net)
# [20:14] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 265 seconds)
# [20:16] * Quits: weinig (~weinig@17.202.50.223) (Ping timeout: 240 seconds)
# [20:16] * Joins: weinig_ (~weinig@17.114.217.5)
# [20:16] * Quits: KevinMarks (~yaaic@2607:fb90:40d:e3e1:4896:1887:aad1:4657) (Ping timeout: 240 seconds)
# [20:16] * Quits: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch) (Ping timeout: 258 seconds)
# [20:16] * Joins: KevinMarks (~KevinMark@50-0-120-82.dedicated.static.sonic.net)
# [20:18] <smaug____> Hixie: want to interpret what http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control means
# [20:21] <Domenic> jtcranmer: pong
# [20:21] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
# [20:22] * Joins: annevk (~annevk@77-57-127-188.dclient.hispeed.ch)
# [20:23] <jtcranmer> Domenic: when are you planning on working on the streams spec again?
# [20:23] * Joins: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch)
# [20:24] <Domenic> jtcranmer: as soon as possible; i had a conversation with an implementer the other day that brought up a number of things to get my head back in the game
# [20:25] <jtcranmer> that's good to hear
# [20:25] * Quits: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch) (Read error: Connection reset by peer)
# [20:25] * Joins: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch)
# [20:25] <jtcranmer> I hadn't seen any progress since the CSP... firestorm a month ago
# [20:25] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
# [20:26] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [20:26] <smaug____> Hixie: especially " the first row describing that autofill field in the table below." part
# [20:26] * Joins: rniwa (~rniwa@17.202.43.222)
# [20:27] <smaug____> also, is anyone shipping this API
# [20:27] <smaug____> or could we like... rewrite it
# [20:27] * Quits: annevk (~annevk@77-57-127-188.dclient.hispeed.ch) (Ping timeout: 276 seconds)
# [20:28] * Joins: sankha93 (~sankha93@dslb-188-096-088-194.pools.arcor-ip.net)
# [20:28] * Quits: sankha93 (~sankha93@dslb-188-096-088-194.pools.arcor-ip.net) (Changing host)
# [20:28] * Joins: sankha93 (~sankha93@fsf/emeritus/sankha93)
# [20:29] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
# [20:29] * Joins: annevk (~annevk@77-57-114-66.dclient.hispeed.ch)
# [20:30] * Quits: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch) (Ping timeout: 252 seconds)
# [20:33] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Read error: Connection reset by peer)
# [20:33] * Joins: annevk (~annevk@77-57-114-66.dclient.hispeed.ch)
# [20:33] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
# [20:35] * Joins: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch)
# [20:36] * Joins: bholley (~bholley@98.210.101.88)
# [20:37] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Ping timeout: 240 seconds)
# [20:41] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
# [20:44] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Remote host closed the connection)
# [20:52] * Joins: richt (~richt@c83-248-137-176.bredband.comhem.se)
# [20:58] * Quits: KevinMarks (~KevinMark@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
# [21:00] * Quits: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
# [21:02] * Joins: KevinMarks (~yaaic@2607:fb90:40d:e3e1:b170:e1d:7f75:ff78)
# [21:03] <Hixie> smaug____: here now, what's up?
# [21:05] <smaug____> trying to interpret what the spec says
# [21:05] <smaug____> first, should the tokens be in order
# [21:06] <smaug____> "set of space-separated tokens" hints no ordering
# [21:06] <smaug____> (since a set isn't normally ordered)
# [21:06] <Hixie> are you asking for implementations, or authors?
# [21:06] <smaug____> implementations
# [21:06] <Hixie> k let me see...
# [21:06] <smaug____> but then there is "in the order given below"
# [21:07] <Hixie> you want the next section
# [21:07] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#processing-model-2
# [21:07] <smaug____> then in http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control I have no idea what it means the there is "name" and under that some other values which are indented a bit
# [21:08] <smaug____> are those other values somehow special
# [21:08] <smaug____> the text above talks about "first row", but of what
# [21:08] * Joins: mven (~textual@169.241.49.196)
# [21:08] <Hixie> are we switching to talking about author conformance criteria?
# [21:09] <smaug____> I don't know what in the spec says it isn't implementation thing
# [21:10] <Hixie> there aren't any requirements that apply to UAs in that first section
# [21:11] <Hixie> it doesn't say that anywhere, it's just a description of what is in that section
# [21:11] <Hixie> the only "must"s are things that would apply to authors (and validators)
# [21:12] <smaug____> "The attribute, if present, must have a value that is a set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or the following, in the order given below:"
# [21:12] <smaug____> why is that not for implementations ?
# [21:12] <Hixie> it's saying what the value must be
# [21:12] <Hixie> how could that be an implementation requirement?
# [21:12] <Hixie> i don't understand what the requirement would be if it was an implementation requirement
# [21:13] <Hixie> the spec talks a bit about this here: http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-to-read-this-specification
# [21:13] <Hixie> does that help?
# [21:13] <Hixie> (second paragraph)
# [21:13] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 252 seconds)
# [21:13] <smaug____> ok, I see
# [21:13] <smaug____> this is just unusually hard to interpret
# [21:13] <smaug____> also, does anyone implement this stuff yet?
# [21:14] <smaug____> (since if not, I might r- patches trying to implement it)
# [21:14] <Hixie> yeah, chrome has shipped this for some time. i tried to get impl feedback on it before they shipped but mozilla was being unusually confusing in its responses and didn't give feedback, and apple and microsoft didn't say anything at all iirc.
# [21:15] <Hixie> (they waited many months before shipping, and it only got specced a year or so later when mozilla started implementing)
# [21:15] <Hixie> (actually, the rAc() is what didn't get specced. I guess the attribute was specced earlier.)
# [21:15] <Hixie> i can try to make it clearer
# [21:15] <Hixie> not sure what is hard to interpret though
# [21:17] * Joins: IZh (~IZh@0897578511.static.corbina.ru)
# [21:17] <smaug____> well, the whole API is odd
# [21:17] * Joins: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net)
# [21:18] <Hixie> how so?
# [21:18] <smaug____> trying to do so much using just one attribute
# [21:19] <Hixie> it's not doing that much, it's just saying what the field represents
# [21:19] <smaug____> in very different level
# [21:19] <smaug____> shipping|billing could be one attribute, name etc one
# [21:20] <smaug____> home|work|etc one
# [21:20] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
# [21:20] <Hixie> isn't that just syntactically equivalent?
# [21:20] <Hixie> i don't understand the difference
# [21:20] <Hixie> (except that having multiple attributes means more confusion about when things take effect)
# [21:21] <smaug____> easier to understand what the attribute is about
# [21:21] <Hixie> seems to me to be exactly equivalent, but ok
# [21:21] <Hixie> either way, i didn't design this, i just specced what had shipped
# [21:21] <smaug____> but if this is shipping in chrome, perhaps I'll need to live with this
# [21:22] <Hixie> so it's about 2 years too late for that kind of feedback :-)
# [21:22] <Hixie> next time, send feedback when it's requested :-)
# [21:22] <smaug____> I can't really follow all the spec stuff
# [21:22] <Hixie> i hear ya
# [21:22] <smaug____> I end up commenting when someone asks for a review
# [21:23] <smaug____> Hixie: but ok, thanks
# [21:23] * Joins: newtron_ (~newtron@199.71.174.204)
# [21:24] <Hixie> fwiw, https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&resolution=---&target_milestone=Needs%20Impl%20Interest is a list of bugs that represent features that are not yet implemented for which feedback is being requested
# [21:24] <Hixie> (especially feedback of the form "we want to implement this" or "we think this is dumb and should not exist", but also api design)
# [21:25] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:25] <Hixie> so looking at that list every few weeks would be a good way to keep on top of this kind of thing in the future
# [21:25] * Quits: tobie (sid5692@gateway/web/irccloud.com/x-yhzxcjhagxmyjyun) (Ping timeout: 245 seconds)
# [21:25] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:25] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [21:25] * Quits: jamesr_ (sid10481@gateway/web/irccloud.com/x-bzmmsicnhegukigf) (Ping timeout: 258 seconds)
# [21:26] * Quits: krit (sid15081@gateway/web/irccloud.com/x-tfcxmqkxceiukdam) (Read error: Connection reset by peer)
# [21:26] * Joins: jamesr_ (sid10481@gateway/web/irccloud.com/x-enxypchdphrlsczj)
# [21:26] * Joins: krit (sid15081@gateway/web/irccloud.com/x-bkigebdudrkybudl)
# [21:27] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
# [21:27] * Joins: bholley (~bholley@98.210.101.88)
# [21:28] * Quits: newtron_ (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
# [21:28] * Joins: tobie (sid5692@gateway/web/irccloud.com/x-rmlqqgzmdzwgmbkw)
# [21:29] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [21:29] * smaug____ bookmarks
# [21:29] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Quit: Reconnecting…)
# [21:30] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
# [21:30] <caitp> if only there were some way to undumb the dumb of old
# [21:32] <Hixie> you can have a pretty API, or you can have a successful API. your call. :-)
# [21:33] <caitp> lots of pretty people are successful, no reason pretty APIs can't be
# [21:35] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [21:35] * Joins: othermaciej (~mjs@17.114.217.202)
# [21:37] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net) (Remote host closed the connection)
# [21:39] * Quits: weinig_ (~weinig@17.114.217.5) (Quit: weinig_)
# [21:41] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [21:43] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Ping timeout: 252 seconds)
# [21:44] <Hixie> caitp: i think there is a reason, actually
# [21:45] <Hixie> caitp: the problem is that once an API is deployed, you can't change it. But you can't work out how to make it perfect before it's deployed.
# [21:45] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
# [21:49] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Quit: leaving)
# [21:49] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [21:49] * Joins: othermaciej (~mjs@17.114.217.202)
# [21:49] <Philip`> I think caitp is suggesting that you should design seven billion variations of an API, and then let people work out which ones are pretty, and those ones will become successful
# [21:50] <caitp> or you could break peoples applications periodically, preferably early on
# [21:50] <caitp> or any number of other ways
# [21:50] <caitp> peoples lives don't depend on this stuff, and people aren't going to stop using the web just because they have to change a few letters in some application
# [21:51] <caitp> just my opinion, nobody gotta take it, but nobody's life depends on this stuff never changing
# [21:51] <Domenic> that's precisely what they'll do
# [21:51] <Domenic> or worse, they'll stop using your browser
# [21:51] <caitp> what alternative are they going to turn to?
# [21:52] * Quits: othermaciej (~mjs@17.114.217.202) (Client Quit)
# [21:52] <Domenic> iOS/Android
# [21:52] <Domenic> and/or a browser that didn't break their sites
# [21:52] <caitp> they might go outside or read a book or get back to working on curing cancer
# [21:52] <Hixie> breaking people's applications is how you get "pretty and not successful"
# [21:53] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [21:53] <caitp> there are plenty of examples of apis with breaking changes which don't really hurt their use
# [21:53] <caitp> openGL and openglES for one
# [21:53] <caitp> for two, rather
# [21:53] <Hixie> (at least, not successful on the scale of the Web or Windows)
# [21:53] <caitp> gtk2 vs gtk3
# [21:53] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
# [21:53] <Hixie> get back to me when gtk has a billion users.
# [21:54] <caitp> well hopefully it never gets there, if we're lucky it will die off and be replaced by something pretty and successful
# [21:55] <caitp> breaking changes are valuable. you don't want them every day, but at least a few times a decade
# [21:55] <Philip`> caitp: Assuming you mean the breaking transition from GL to GLES, that worked because GLES existed on a new platform that no existing GL application could possibly run on anyway, so application developers had to start from scratch and could use whatever API was there
# [21:56] <caitp> OpenGL2 vs OpenGL3 is massively different, and there have been breaking changes from early gles to more recent gles as well, but it's just an example
# [21:56] <Hixie> caitp: https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
# [21:56] <caitp> I've read it, it's a nice post
# [21:59] <caitp> but I think people greatly exaggerate the importance of users changing browsers for a while, or of users not browsing the web for a while. It's never going to make any real difference to anybody
# [21:59] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
# [22:00] <Hixie> let's suppose that you're right. it actually still doesn't matter. what matters is that the people developing browsers think it's true.
# [22:02] <caitp> imagine if people started using IE again to browse tumblr because of some rendering glitch in a particular theme that affected gecko or blink, due to a breaking change
# [22:02] <caitp> maybe you'd see less irrational complaints about "IE is awful/slow/etc", and more reality
# [22:02] <caitp> you'd bring honesty back!
# [22:02] <caitp> man, that would be great
# [22:02] * Joins: scor (~scor@drupal.org/user/52142/view)
# [22:02] * Joins: othermaciej (~mjs@17.114.217.202)
# [22:04] <Domenic> and people would get fired from mozilla and google (or get very poor performance reviews)
# [22:04] <Domenic> you have to remember that there are real consequences to effin up the software you ship
# [22:04] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [22:05] <Hixie> what would happen is that just one browser (the one that implemented the breaking change) would not work
# [22:05] <Hixie> and users would blame the browser and move to another one
# [22:05] <Hixie> some very small number of users if it was just one breaking change
# [22:05] <Hixie> and the other browser vendors would see this and say "well we're not doing _that_"
# [22:06] <Hixie> just look at the level of difficulty that browsers are facing trying to drop showModalDialog()
# [22:06] <Hixie> an API that every browser vendor desperately wants to drop
# [22:06] <Hixie> an API that has virtually no use on the Web itself
# [22:06] <Hixie> an API that causes security problems
# [22:06] <Hixie> an API that massively complicates the specs and implementations
# [22:07] <Hixie> an API that was originally non-standard
# [22:07] <caitp> I know it's hard, Hixie
# [22:08] * Joins: mven (~textual@169.241.49.196)
# [22:08] <caitp> but it's hard because of an attitude problem, and that is a bug worth fixing
# [22:09] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
# [22:09] <Hixie> i have no idea whatsoever how to fix humans. good luck. in the meantime...
# [22:09] <zewt> if you're working for a browser vendor trying to get politics and practicalities changed, great; if you're not, that's a lovely statement but not an actionable one
# [22:10] <Hixie> (this is the same argument i have against RDF&co. Embedding structured data in the web page is essentially a human problem, and it's harder to fix that problem than it is for us to develop NLP.)
# [22:10] <Hixie> (not that NLP is easy at all. It's just that social problems are even harder.)
# [22:10] <Domenic> an attitude problem O_O
# [22:11] <caitp> I think it can be done
# [22:11] <zewt> Domenic: that's what business realities look like, when it's not your job :P
# [22:11] <caitp> for most of the browser vendors out there, browser use isn't their main business
# [22:12] <caitp> well, okay, maybe not most
# [22:12] <caitp> lets say 2 out of 5
# [22:12] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [22:12] <caitp> maybe you could even throw apple in there too, since they push objc
# [22:12] <Domenic> Yes, and for Goldman Sachs, structured investments isn't their main business. Doesn't mean the structured investments group wants to give all their business to Citigroup.
# [22:12] <caitp> that's comparing an apple to an orchard, don't you think?
# [22:12] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 255 seconds)
# [22:13] <Domenic> not at all
# [22:13] <caitp> there's a lot more money in one arena than the other
# [22:13] <Domenic> business units and companies and responsibility and performance reviews work the same way in both environments
# [22:13] <caitp> thus the attitude problem
# [22:13] <Domenic> if you say so...
# [22:14] <caitp> when something doesn't have a real impact, either financially or culturally, it must not be held to such a high standard
# [22:14] <Hixie> as you said before, it's an attitude problem. Specifically, the attitude of the engineers on the browser teams, and the people who evaluate their performance.
# [22:14] <Hixie> for those people, browser use is their main business.
# [22:15] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [22:16] <Hixie> btw, even if all the browser vendors were to agree to break things together, even that wouldn't solve your problem. You'd just make the Web platform less attractive and cause Web developers to consider becoming developers for other platforms.
# [22:16] <caitp> and that would be just fine
# [22:16] <caitp> it really doesn't matter in the grand scheme of things :)
# [22:16] <caitp> it really doesn't
# [22:17] <caitp> but, I know I don't have to convince you of that
# [22:17] <Hixie> well, it greatly matters to me that the open multi-vendor platforms be more successful than the proprietary ones.
# [22:18] <Hixie> Also, do you really want to be breaking these web apps? Consider if one of them is the ticketing app for an airline. Suddenly over the course of a week all the browsers stop working on that site. Can you imagine the chaos that that company would face? Now multiply that across the whole of our economy.
# [22:18] * Joins: KevinMarks_ (~KevinMark@50-0-120-82.dedicated.static.sonic.net)
# [22:19] <IZh> It's hot here today. ;-)
# [22:19] <caitp> fortunately, it's possible to have relationships with businesses who use your product, and inform them of coming breaking changes
# [22:19] <Hixie> in practice, those relationships don't exist.
# [22:19] <Hixie> i mean, i would love to live in the world you describe, don't get me wrong.
# [22:19] <caitp> sure they do, I have participated in them
# [22:19] <Hixie> but it's not the world i live in.
# [22:19] <caitp> you can have more of them
# [22:20] <caitp> you can encourage effective communication
# [22:20] <caitp> there is no shortage of ways to make things suck less than they do, and just no real effort to take on those endeavors
# [22:21] <Hixie> well that's just offensive.
# [22:21] <caitp> but I don't want to have a fight about this
# [22:21] <Hixie> you basically just said that the last 15 years of my life have been "no real effort"
# [22:21] <caitp> oh come now Hixie, I'm not saying that
# [22:21] <Hixie> you really did.
# [22:21] <caitp> maybe "no real effort" was the wrong choice of words
# [22:22] <Hixie> (not just my life, either.)
# [22:22] <IZh> Evolution vs revolution.
# [22:24] <caitp> various organizations are certainly making an effort to open the process and get more input from different interested parties, so yes, that effort is being made
# [22:24] <Hixie> we've also spent years trying to improve the web concretely, by providing better APIs, defining the platform better to improve interop, etc.
# [22:24] <Hixie> not to mention all the work on test suites
# [22:25] <Hixie> and all the work on developer advocacy
# [22:25] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [22:25] <Hixie> and all the work on campaigning to browser vendors that they better support standards
# [22:25] <Hixie> and all the work trying to convince each other that particular design patterns are better than others
# [22:26] <caitp> and that's all awesome, no doubt
# [22:26] <Hixie> what have _you_ done to improve the web?
# [22:27] <caitp> I've worked on improving compliance with various proposed standards, improving application frameworks, and am not quiet at all about my opinions on the problems with it and how they can be addressed
# [22:27] <Domenic> it's interesting that you flipped the offensive bit at "no real effort"; I flipped it at "attitude problem"
# [22:27] <caitp> and have even campaigned to some degree to address some of those problems
# [22:28] <Hixie> urls?
# [22:28] <caitp> but I'm just one person, and I am very snarky, not necessarily diplomatic
# [22:28] <caitp> so campaigning is not my strongpoint
# [22:28] <IZh> 8
# [22:28] <IZh> Oops
# [22:31] * Quits: Ms2ger (~Ms2ger@134.199-242-81.adsl-dyn.isp.belgacom.be) (Quit: nn)
# [22:36] <caitp> sorry Hixie I didn't mean to come across as saying that there have been __no__ efforts to improve things, but I don't think there has been much of a real effort to give people a reality check about the importance of number-of-downloads/users/etc
# [22:37] <caitp> so I apologize for that =)
# [22:38] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [22:39] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [22:40] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [22:41] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [22:41] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [22:41] * Quits: ahf (ahf@irssi/staff/ahf) (Ping timeout: 240 seconds)
# [22:42] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [22:43] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
# [22:44] <Hixie> caitp: i think if you tried to tell a browser vendor that users were less important, they'd respond with a precise dollar figure per user and ask you how many dollars you think they should give up in order to make some API slightly prettier
# [22:45] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [22:45] <caitp> sure, and then you say "whatever it takes", because the reality is that the revenue models for most of these vendors don't really come from people using their particular browser all the time
# [22:45] <Hixie> i also think the reaction would probably depend on whether they were currently increasing in market share or losing it. It's worth noting that Chrome is more willing to break APIs these days than other browsers; I don't think their relative market numbers are unrelated to this.
# [22:46] <Hixie> uh
# [22:46] <Domenic> what i am hearing is that caitp hates capitalism ;)
# [22:46] <Hixie> the revenue model of all browsers is pretty much entirely based on how much they use their browsers.
# [22:46] <Hixie> caitp: what do you think the revenue model of browsers is?
# [22:46] <caitp> you've got a number of revenue models
# [22:46] <Hixie> you do?
# [22:47] <Domenic> hmm, i was pretty sure the argument from a few minutes ago was that revenue wasn't important, and people should go outside and read books or something.
# [22:47] <caitp> in Mozilla's case, you have donations to the foundation, ad revenue for the corporation. In the case of Google, you have piles of ad revenue. in the case of Mozilla, you have cloud services, OEM licensing, and other models
# [22:47] <caitp> in the case of Apple, you have iPhone sales, etc etc
# [22:48] <caitp> it's not that revenue isn't important, it's that the impact on revenue breaking changes would have is exaggerated
# [22:48] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [22:48] <Hixie> um... you might want to look at mozilla's financials more closely.
# [22:48] <Domenic> JakeA: curious what https://twitter.com/trygve_lie/status/468839273010323456 is about?
# [22:49] <Hixie> and in the case of iPhone, sales of the device are going to drop if people find that browsers on their device don't work (there's only one rendering engine for all browsers on iPhones)
# [22:49] <caitp> and that's only significant if it breaks a huge amount of the web
# [22:50] <caitp> you can break a lot with minimal impact
# [22:50] <Hixie> what is a huge amount? a million pages?
# [22:50] <Hixie> a hundred thousand?
# [22:50] <caitp> lets put it this way, hamstersmut.com rendering a paragraph wrong is probably not going to severely impact sales
# [22:51] <Hixie> so 2 million?
# [22:51] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [22:51] <caitp> a number of pages that have real audiences
# [22:51] <Hixie> the tail on the web is very long
# [22:51] <caitp> and the number of those pages breaking could be mitigated by discussing with them
# [22:51] <Hixie> veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery long
# [22:52] <JakeA> Domenic: https://twitter.com/leftieFriele/status/468836645362757633, although I was genuinely unaware of the meaning of "webbles", I just found " web rebels " difficult to say
# [22:52] <Hixie> google knows of ~100 trillion pages
# [22:52] <Hixie> how do you plan to contact them? phone calls?
# [22:52] <caitp> mass email to DNS providers >:D
# [22:53] <Domenic> JakeA: haha wow
# [22:53] <Hixie> yeah, because spamming the world is definitely going to improve sales
# [22:53] * Joins: jeremyj (~jeremyj@17.202.44.231)
# [22:53] <caitp> for applications with real audiences, which have a real impact on sales, you could even go with face to face conversation to discuss breaking changes
# [22:53] <caitp> does it scale? no, but it doesn't have to
# [22:54] * Joins: othermaciej (~mjs@17.114.217.202)
# [22:55] <Hixie> 100 trillion pages.
# [22:55] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [22:55] <Hixie> 0.001% of them is a billion pages.
# [22:56] <Hixie> i think it might have to scale.
# [22:56] <caitp> pages is not necessarily "domains"
# [22:56] <Hixie> there's more than a quarter of a billion domains
# [22:56] <caitp> and a given organization may have many domains
# [22:57] <Domenic> 100 trillion, really? that's awesome.
# [22:57] <Hixie> 0.001% is 2500 domains that have to be contacted
# [22:57] <caitp> which is totally doable
# [22:57] <caitp> and then you could even bundle them by industry
# [22:57] <caitp> government, utilities/transportation, entertainment, etc
# [22:57] <Hixie> at five hours per domain, that's a year and a half non-stop per breaking change
# [22:57] <Hixie> are you paying for that?
# [22:58] <Hixie> also, have you seen the response you get from developers when you tell them there's going to be a breaking change? look in blink-dev at the reaction around showModalDialog().
# [22:58] <caitp> out of my own pocket? hey, I'm a genius, not an oil executive
# [22:58] <Hixie> so who's going to be paying for it?
# [22:59] <caitp> who indeed
# [23:00] <Hixie> hello browser vendor executive, please make a choice: we could do nothing, and it would cost nothing, or we could make this breaking change, and it would cost us x% of users or a year and a half of intensive conversations with developers who will be angry at us for breaking their site.
# [23:00] <caitp> hey, what is money if it doesn't flow down the river
# [23:01] <wilhelm> Hey, opportunity cost. (c:
# [23:02] <Hixie> that's true, i forgot about hte opportunity cost. All the effort spent making that breaking change could instead have been spent making the browser a bit faster or more stable or whatever.
# [23:02] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [23:02] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [23:02] <caitp> if you remove brokenness, you might see a performance and stability improvement, too :D
# [23:03] <Hixie> do you have an example of how that could happen?
# [23:03] <Hixie> generally, changing APIs just introduces bugs, it doesn't remove them
# [23:03] * Quits: TabAtkins (sid11559@gateway/web/irccloud.com/x-gevdqifacmmsaftp) (Ping timeout: 265 seconds)
# [23:03] <caitp> sure, suppose we removed 12 million lines of code, which no longer has to be linked into a binary
# [23:03] <Domenic> Hixie: where in the spec would I go to find out what DOM should result from the strings "" vs. " "
# [23:03] * Quits: jkomoros__ (uid7860@gateway/web/irccloud.com/x-lqntiyfvhnovplek) (Ping timeout: 240 seconds)
# [23:04] <caitp> no longer ends up getting called and no longer takes up cache lines
# [23:04] * Quits: cwilso (sid10206@gateway/web/irccloud.com/x-oxaiubbbpkkfhidy) (Ping timeout: 240 seconds)
# [23:04] * Quits: bterlson (sid23757@gateway/web/irccloud.com/x-ahjrnjuprxkhvphy) (Ping timeout: 252 seconds)
# [23:04] <caitp> beautiful
# [23:04] <Domenic> Hixie: as in, I saved an empty .html file and opened it in my browser, vs. a one-byte one containing a space.
# [23:04] <Hixie> Domenic: you mean in parsing?
# [23:04] <Domenic> Hixie: yeah I'd imagine so.
# [23:04] <Hixie> Domenic: http://www.whatwg.org/specs/web-apps/current-work/#parsing
# [23:04] <Domenic> Noooo trolled by the single-page spec again :P
# [23:05] <Hixie> caitp: you were talking about changing APIs, not removing APIs
# [23:05] <caitp> it's an example hixie, you could definitely do a lot of both
# [23:05] * Joins: bterlson (sid23757@gateway/web/irccloud.com/x-lbrwhrjhsaxnmdda)
# [23:05] <Domenic> if i were a browser engine implementer i would spend all my time improving browser speed when viewing the html standard, just as a matter of improving my own productivity :P
# [23:05] <Hixie> caitp: you say "definitely", but i don't see on what you're basing this
# [23:05] * Joins: cwilso (sid10206@gateway/web/irccloud.com/x-vbeddiyoakrnscik)
# [23:05] * Joins: TabAtkins (sid11559@gateway/web/irccloud.com/x-wwpveoohsvklapjf)
# [23:06] <Domenic> Hixie: I really like the new "Note", "Example", etc.
# [23:06] <caitp> I base things on hypothetical scenarios
# [23:06] <Hixie> Domenic: chrome is pretty fast at loading it. I don't really understand why the other browsers aren't improving to match it.
# [23:06] * Quits: Rubennn (~Rubennn@apher.gewooniets.nl) (Ping timeout: 245 seconds)
# [23:06] <caitp> it's the best source of evidence
# [23:06] <Domenic> (stunned silence)
# [23:06] <caitp> such empirical, much scientific, wow
# [23:07] <Hixie> i'll take that as a concession speech...
# [23:07] <caitp> hardly
# [23:07] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
# [23:07] * Joins: Rubennn (~Rubennn@apher.gewooniets.nl)
# [23:07] <caitp> just a little good humour
# [23:07] * Joins: jkomoros__ (uid7860@gateway/web/irccloud.com/x-grdfzhelwdquglqe)
# [23:07] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net)
# [23:07] * Joins: mven (~textual@169.241.49.196)
# [23:08] <Hixie> caitp: so what are you basing it on then?
# [23:08] <caitp> let me scroll up to see what I said "definitely" baout
# [23:08] <caitp> about*
# [23:08] <Domenic> Hixie: well it turns out today is not the day I'm going to spend understanding the HTML parsing algorithm :P. Do you happen to know off the top of your head what behavior should be for "" vs " "? I can always test browsers I suppose.
# [23:08] <caitp> oh, definitely remove and change apis
# [23:09] <caitp> sure, there's a lot of complete crap that you could remove, like most of the parsing algorithm
# [23:09] <caitp> (just for example)
# [23:09] <caitp> most of the DOM api
# [23:09] <caitp> most of CSS
# [23:09] <Hixie> Domenic: i can look...
# [23:10] <caitp> although removing a lot of that wouldn't make anyone very happy, it would be a marked improvement
# [23:10] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
# [23:10] * Quits: IZh (~IZh@0897578511.static.corbina.ru) (Remote host closed the connection)
# [23:10] <Hixie> Domenic: looks like no difference. a space at the very start gets dropped on the floor.
# [23:11] * Quits: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
# [23:11] <Hixie> caitp: ok so removing "most of the parsing algorithm" would in fact affect trillions of pages on hundreds of millions of domains.
# [23:11] * Quits: abarth (sid5294@gateway/web/irccloud.com/x-drqxasbbrukseuos) (Ping timeout: 265 seconds)
# [23:11] <caitp> yeah, but think of how much code smell you could get rid of 8)
# [23:11] * Quits: JakeA (uid3836@gateway/web/irccloud.com/x-mqazovfmjccinyhw) (Ping timeout: 252 seconds)
# [23:11] <Hixie> caitp: so that's a non-starter even if i concede everything you said earlier about how easy it is to make breaking changes
# [23:12] * Quits: parshap_ (sid18846@gateway/web/irccloud.com/x-rntuzhtkxhptvobc) (Ping timeout: 265 seconds)
# [23:12] <Hixie> caitp: i'm going to assume that "msot of the DOM api" and "most of CSS" are just more "little good humour"
# [23:12] <Domenic> Hixie: appreciated, thanks.
# [23:12] * Joins: abarth (sid5294@gateway/web/irccloud.com/x-yvzwzwcxorkbvlwt)
# [23:13] * Joins: JakeA (uid3836@gateway/web/irccloud.com/x-amwuauijhiovzsxc)
# [23:13] <caitp> nah, if you could do it all over again, you could learn from past mistakes and improve it, and minimize special casing and bizarre behaviour
# [23:13] <caitp> it would be beautiful
# [23:14] * Joins: parshap_ (sid18846@gateway/web/irccloud.com/x-bndjlyrzgtthwqud)
# [23:14] <caitp> but obviously that's a wild leap beyond removal of simple things
# [23:14] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 276 seconds)
# [23:14] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [23:14] <caitp> but oh man, it would be glorious
# [23:14] <Hixie> it would be glorious for about a month
# [23:15] <Hixie> until the next new feature developed by someone who didn't have anything to do with the initial glorious design was added
# [23:15] <Hixie> or until the next browser shipped with a minor bug that the web then started depending on
# [23:15] <Hixie> and within a year we'd be back where we started
# [23:15] <caitp> yeah but in another 2 decades you could do it all over again
# [23:15] <caitp> totally worth it
# [23:16] <Hixie> (or, more likely, it wouldn't take off in the first place, since it would have to compete with the existing web, and 100 trillion existing documents in ugly code would trump the 0 documents of beautiful code in users' eyes, since they don't see the code)
# [23:16] <wilhelm> caitp: Aw, you're 12 years late. Here you go: http://www.w3.org/TR/xhtml2/
# [23:16] <caitp> I have good friends on that WG
# [23:16] <caitp> well, the xmlwg
# [23:16] <Domenic> hehehehe
# [23:17] <Domenic> wilhelm++
# [23:17] <Hixie> well that explains a lot
# [23:17] <wilhelm> :D
# [23:17] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net)
# [23:18] <caitp> good people is good people, and sometimes they have sensible ideas
# [23:18] <jgraham> caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hug
# [23:19] <wilhelm> jgraham: /load splitlong.pl
# [23:19] <jgraham> wilhelm: Oh, I thought I already had
# [23:19] <jgraham> caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hug
# [23:19] <jgraham> ... got hundreds of thousands of Opera users.
# [23:19] <caitp> yeah but if all of our mighty browser vendor overlords joined in for the breaking changes, people wouldn't really have a choice. but I do know that it's not something that's going to happen any time soon, it's a pipedream
# [23:20] <jgraham> Yes, but getting everyone to act like that isn't a Nash equilibrium
# [23:22] <Hixie> jgraham: your text cut off at "Not small site either; hug" then contined with "... got hundreds"
# [23:22] <Hixie> continued
# [23:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 264 seconds)
# [23:24] <Hixie> caitp: i don't think anyone is arguing that "people" aren't "good people". Just that said "people", apparently including you, have an unrealistic idea of what is achievable when it involves changing how people think or act.
# [23:24] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
# [23:24] <caitp> or you know what might happen instead, maybe the WWW will simply stop existing as nationstates put up huge national firewalls, and architect strong protections against those firewalls being undermined, and that greatly reduces the pool of applications that would be affected
# [23:25] <caitp> it's not that I have an unrealistic sense of what is achievable
# [23:25] <Hixie> that is debatable.
# [23:25] <caitp> it's that I have a lot of confidence
# [23:25] <jgraham> "huge ones that probably"
# [23:25] <Hixie> ok, you have an unrealistic level of confidence in what is achievable.
# [23:25] <Hixie> imho
# [23:25] <wilhelm> Not unrealistic. Positively harmful. What a waste of good engineers. (c:
# [23:26] <caitp> hey, at least I'm not trying to start the next snapchat
# [23:27] <Hixie> as jgraham says, getting all the browser vendors to work in this way is not a nash equilibrium. In practice, humans do act to find a nash equilibrium.
# [23:28] * Joins: `nik` (~nik@li490-134.members.linode.com)
# [23:28] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [23:30] * Quits: KevinMarks_ (~KevinMark@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 265 seconds)
# [23:32] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
# [23:36] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:36] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
# [23:37] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
# [23:38] * Quits: richt (~richt@c83-248-137-176.bredband.comhem.se) (Remote host closed the connection)
# [23:38] * Joins: a-ja (~Instantbi@70.230.147.189)
# [23:38] * Joins: richt (~richt@c83-248-137-176.bredband.comhem.se)
# [23:39] * Quits: KevinMarks (~yaaic@2607:fb90:40d:e3e1:b170:e1d:7f75:ff78) (Ping timeout: 240 seconds)
# [23:42] * Quits: richt (~richt@c83-248-137-176.bredband.comhem.se) (Ping timeout: 240 seconds)
# [23:45] * Joins: sankha_ (~sankha93@dslb-084-057-207-063.pools.arcor-ip.net)
# [23:45] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
# [23:46] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
# [23:46] * Joins: KevinMarks (~yaaic@2607:fb90:212a:1795:dc53:91fa:58e0:4449)
# [23:46] <Hixie> Domenic: how does the promise pattern fit into models where we use onreadystatechange today, where the object can be in multiple states and transitions through them one by one?
# [23:47] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Ping timeout: 252 seconds)
# [23:48] <Domenic> Hixie: three answers to that...
# [23:48] <Domenic> 1) it doesn't; promises are for simple one and done async ops
# [23:48] <Domenic> 2) it might be useful for users to have a promise for the 80% case, e.g. completely-loaded
# [23:49] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
# [23:49] * Joins: sankha__ (~sankha93@dslb-084-057-203-058.pools.arcor-ip.net)
# [23:49] <Domenic> 3) in certain cases it can be natural to model individual state transitions as promises. E.g. you could have both ".headersReceived" and ".loaded" promises. (I don't remember the other ready states besides loaded... picked headersReceived because it seemed plausible.)
# [23:49] <Domenic> 3) is pretty rare though
# [23:50] <Domenic> you could consider document.ready vs. document.loaded as an instance of 3), I guess.
# [23:51] * Quits: sankha_ (~sankha93@dslb-084-057-207-063.pools.arcor-ip.net) (Ping timeout: 264 seconds)
# [23:51] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
# [23:55] <Hixie> Domenic: i'm looking at script and resource loading, and there's all kinds of edge cases, different states, etc.
# [23:55] * Joins: sankha_ (~sankha93@dslb-188-104-195-160.pools.arcor-ip.net)
# [23:55] <Hixie> Domenic: e.g. you want to know when some things are downloaded but not yet executed, so you can execute something when everything is ready
# [23:55] <Hixie> Domenic: or you want to know when everything has executed, so you can use the api
# [23:55] <Hixie> Domenic: or you want to know when things have started downloading, to show progress UI
# [23:56] <Domenic> some of the questions to ask are: is it useful for a "late" subscriber to know that these things occurred?
# [23:56] <Domenic> e.g. if the script has already executed, do you usually want to run the same code in response to that, as you would run if you had queued up a handler before the execution happened?
# [23:57] <Domenic> with events, if you miss your chance for registration, then you have to switch programming patterns
# [23:57] <Domenic> if (alreadyExecuted) { doStuff1(); } else { addEventListener("executed", doStuff2); }
# [23:57] <Domenic> if doStuff1 and doStuff2 are always the same code, then promises are better
# [23:57] <Domenic> if they are always different, events are better
# [23:58] <Domenic> (a common case being doStuff1 is a noop, whereas doStuff2 takes action)
# [23:58] * Quits: sankha__ (~sankha93@dslb-084-057-203-058.pools.arcor-ip.net) (Ping timeout: 252 seconds)
# [23:59] <Domenic> progress is pretty explicitly out of scope for promises
# [23:59] <Domenic> events work well for that
# [23:59] <Domenic> although the use case of knowing when progress *starts* is an interesting one... my gut says it's not a common use case?
# [23:59] <Domenic> i could potentially see .executed and .loaded as two separate state-transition-signalling promises
# [23:59] <Domenic> but i am not sure it is worth the use case
# Session Close: Wed May 21 00:00:00 2014

The end :)