Options:
Previous day, Next day
- # Session Start: Wed Nov 19 00:00:00 2014
- # Session Ident: #whatwg
- # [00:00] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
- # [00:00] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [00:03] * Quits: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [00:03] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
- # [00:03] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [00:04] * Joins: roc (~chatzilla@203.192.141.163)
- # [00:06] * Joins: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net)
- # [00:07] * Quits: eric_carlson (~ericc@17.202.49.94) (Quit: eric_carlson)
- # [00:08] * Joins: newtron (~newtron@184.175.3.104)
- # [00:10] <Hixie> (and so friendly to copy-paste across whitespace-ignoring environments like HTML)
- # [00:12] * Joins: karlcow (~karl@nerval.la-grange.net)
- # [00:18] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-dgzkxvktlgebipjc)
- # [00:19] * Joins: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
- # [00:20] * Joins: eric_carlson (~ericc@17.245.27.39)
- # [00:21] * Quits: eric_carlson (~ericc@17.245.27.39) (Client Quit)
- # [00:23] * Quits: jsbell (jsbell@nat/google/x-eacwtfdoyezfbqmt) (Quit: There's no place like home...)
- # [00:26] * Joins: woebtz (~woebtz@cpe-172-250-93-102.socal.res.rr.com)
- # [00:27] * Quits: Mso150 (~ctlM@80.83.238.51) (Remote host closed the connection)
- # [00:27] * Joins: Mso150 (~ctlM@80.83.238.51)
- # [00:32] * Joins: tantek (~tantek@209.129.91.3)
- # [00:41] * Joins: Mso150_g (~ctlM@80.83.239.36)
- # [00:42] * Quits: Mso150 (~ctlM@80.83.238.51) (Ping timeout: 240 seconds)
- # [00:42] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [00:43] <TabAtkins> Hixie: Luckily, don't care! That's what <pre> is for. ^_^
- # [00:43] <TabAtkins> Or <plaintext> ^_^
- # [00:46] * Quits: newtron (~newtron@184.175.3.104) (Remote host closed the connection)
- # [00:49] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 250 seconds)
- # [00:49] * Quits: tantek (~tantek@209.129.91.3) (Quit: tantek)
- # [00:50] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
- # [00:51] * Joins: weinig (~weinig@17.245.26.114)
- # [00:52] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
- # [00:53] * Joins: newtron (~newtron@184.175.3.104)
- # [00:53] * Quits: newtron (~newtron@184.175.3.104) (Remote host closed the connection)
- # [00:58] * Quits: weinig (~weinig@17.245.26.114) (Quit: weinig)
- # [00:59] * Quits: darobin (~darobin@2a01:e34:ed05:d180:e400:f5c2:e938:ce43) (Remote host closed the connection)
- # [00:59] * Joins: tantek (~tantek@209.129.91.3)
- # [01:02] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
- # [01:03] <hober> <xmp> 4evah
- # [01:03] * Quits: Mso150_g (~ctlM@80.83.239.36) (Ping timeout: 240 seconds)
- # [01:04] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [01:07] <caitp> "Blending of HTML and SVG elements" << is that part of what you were saying before about moving svg into the html namespace?
- # [01:08] <pdr> caitp, no, this is about blend modes
- # [01:08] <caitp> mm
- # [01:08] <caitp> if google groups notifications would link to the actual thread it would be easier to read the whole thing :>
- # [01:09] <pdr> caitp, https://groups.google.com/a/chromium.org/d/msg/blink-dev/WoLwgoPB-GE/KqAftxiogKMJ
- # [01:09] <pdr> caitp, agreed, google groups... ( ._.)
- # [01:09] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Ping timeout: 272 seconds)
- # [01:10] <caitp> so it's basically a feature, that's cool
- # [01:16] * Joins: plutoniix (~plutoniix@210.213.57.70)
- # [01:19] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Ping timeout: 245 seconds)
- # [01:19] * heycam is now known as heycam|away
- # [01:23] * Quits: bnicholson (~bnicholso@corp.mtv2.mozilla.com) (Quit: Leaving)
- # [01:24] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
- # [01:24] * Joins: I (~bnicholso@corp.mtv2.mozilla.com)
- # [01:24] * Quits: I (~bnicholso@corp.mtv2.mozilla.com) (Client Quit)
- # [01:25] * Quits: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff) (Ping timeout: 272 seconds)
- # [01:30] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
- # [01:30] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [01:34] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
- # [01:35] * Joins: I (~bnicholso@corp.mtv2.mozilla.com)
- # [01:36] * I is now known as Guest16407
- # [01:36] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Remote host closed the connection)
- # [01:41] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
- # [01:53] * Joins: webtroll (~webtroll@96.24.28.144)
- # [01:56] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Quit: Snuggling with the puppies)
- # [01:56] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-hfbckobkskzajrkb) (Quit: Connection closed for inactivity)
- # [02:00] * Joins: pfefferle (~pfefferle@x2f57866.dyn.telefonica.de)
- # [02:02] * Joins: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
- # [02:03] * Joins: eric_carlson (~ericc@24.6.239.9)
- # [02:04] * Joins: newtron (~newtron@184.175.3.104)
- # [02:05] * Quits: ap (~ap@17.202.44.214)
- # [02:06] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-swjhadjcwscivfdo)
- # [02:08] * Quits: newtron (~newtron@184.175.3.104) (Ping timeout: 255 seconds)
- # [02:09] * Joins: jernoble (~jernoble@76.74.153.49)
- # [02:15] * Quits: pfefferle (~pfefferle@x2f57866.dyn.telefonica.de) (Quit: pfefferle)
- # [02:18] * Quits: jwalden (~waldo@2620:101:80fb:224:7e7a:91ff:fe25:a5a3) (Quit: back tomorrow)
- # [02:20] * Quits: jernoble (~jernoble@76.74.153.49) (Ping timeout: 256 seconds)
- # [02:23] * Joins: JosephSilber (~JosephSil@ool-44c3e80a.static.optonline.net)
- # [02:23] <MikeSmith> Hixie: CSSOM added now (and CSSOM Views)
- # [02:24] <JonathanNeal> A few of us are starting work on Element Queries. Your thoughts, concerns, questions, and feedback are most desired. https://github.com/ResponsiveImagesCG/eq-demos
- # [02:25] * Joins: jernoble (~jernoble@166.170.37.219)
- # [02:25] * Quits: jernoble (~jernoble@166.170.37.219) (Read error: Connection reset by peer)
- # [02:28] <Una> hey JonathanNeal can you give me a use case? I'm trying to understand better
- # [02:28] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [02:29] * Joins: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net)
- # [02:31] * Joins: jernoble (~jernoble@76.74.153.49)
- # [02:32] <JonathanNeal> Una: yes. You have a widget running in a web page that you do not control. The widget may be in a narrow column or a wide column. When the column is narrow, even though the screen is large, things go poorly for the widget.
- # [02:32] * Quits: tantek (~tantek@209.129.91.3) (Quit: tantek)
- # [02:33] <JonathanNeal> Una: there is also an effort in progress to formalize use cases @ http://responsiveimagescg.github.io/eq-usecases/
- # [02:33] <Una> JonathanNeal but if you don't control the widget, how are you going to style it with element queries?
- # [02:33] <JonathanNeal> The widget deploys its own HTML and CSS, but does not control where it lives on the page.
- # [02:34] <JonathanNeal> The admin who controls the page has the power to “deploy the widget here”, here being any kind of column.
- # [02:35] <JonathanNeal> This is the same need we have in media queries, but in context of the layout vs in context of the screen size.
- # [02:37] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [02:40] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-lqdsjiwijqjunxzv) (Quit: Connection closed for inactivity)
- # [02:46] * Quits: jernoble (~jernoble@76.74.153.49) (Quit: Computer has gone to sleep.)
- # [02:46] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
- # [02:47] * Quits: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [02:51] * Quits: lerc (~quassel@121-74-5-229.telstraclear.net) (Ping timeout: 258 seconds)
- # [02:56] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
- # [02:58] <JonathanNeal> For Element Queries, I think the simpliest use case is: “I have a widget that needs to look good in any column of our layout, whether that column is small, medium, or large.”
- # [02:59] * Quits: Guest16407 (~bnicholso@corp.mtv2.mozilla.com) (Quit: This computer has gone to sleep)
- # [03:01] * Quits: mko (~mko@50.240.205.146) (Ping timeout: 255 seconds)
- # [03:02] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [03:06] <Hixie> MikeSmith: cool, thanks
- # [03:14] * Joins: Guest16407 (~bnicholso@24.130.60.241)
- # [03:15] * Quits: jyasskin (jyasskin@nat/google/x-kxnzlrabxvhddhfv) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [03:27] * Joins: yhirano (uid40668@gateway/web/irccloud.com/x-tlswhixndhxvuyth)
- # [03:32] * Joins: dwim (~dwim@210.94.41.89)
- # [03:33] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
- # [03:47] * Quits: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a) (Ping timeout: 258 seconds)
- # [03:47] * Quits: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net) (Quit: Leaving.)
- # [03:50] * Quits: webtroll (~webtroll@96.24.28.144) (Remote host closed the connection)
- # [03:50] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [03:51] * Joins: Goplat (~goplat@reactos/developer/Goplat)
- # [03:57] * Joins: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com)
- # [04:03] * Joins: estellevw_ (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
- # [04:06] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Ping timeout: 264 seconds)
- # [04:06] * estellevw_ is now known as estellevw
- # [04:20] * heycam|away is now known as heycam
- # [04:25] * Joins: weinig (~weinig@98.234.191.242)
- # [04:25] * Quits: weinig (~weinig@98.234.191.242) (Client Quit)
- # [04:36] * Joins: Mso150 (~ctlM@80.83.239.72)
- # [04:41] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [04:49] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [04:50] * Krinkle is now known as Krinkle|detached
- # [05:00] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 250 seconds)
- # [05:02] * Quits: rektide_ (~rektide@eldergods.com) (Ping timeout: 240 seconds)
- # [05:02] * Quits: rektide (~rektide@eldergods.com) (Ping timeout: 245 seconds)
- # [05:08] * Joins: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net)
- # [05:10] * Joins: rektide_ (~rektide@eldergods.com)
- # [05:10] * Joins: rektide (~rektide@eldergods.com)
- # [05:10] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
- # [05:13] * Quits: jochen__ (jochen@nat/google/x-iblvefwpfmmtxlbm) (Ping timeout: 255 seconds)
- # [05:13] * Joins: jochen__ (jochen@nat/google/x-okksvymufqffzlkj)
- # [05:16] * Quits: Mso150 (~ctlM@80.83.239.72) (Ping timeout: 264 seconds)
- # [05:17] * Joins: enaqx (~enaqx@user-206.98.infomir.com.ua)
- # [05:23] <jamesr_> JonathanNeal: how do you avoid creating cycles?
- # [05:25] * Joins: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net)
- # [05:30] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
- # [06:09] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
- # [06:09] * Joins: CvP (~CvP@203.76.123.238)
- # [06:14] * Quits: eric_carlson (~ericc@24.6.239.9) (Quit: eric_carlson)
- # [06:24] * Quits: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net) (Quit: haydogsup)
- # [06:25] * Quits: woebtz (~woebtz@cpe-172-250-93-102.socal.res.rr.com)
- # [06:27] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
- # [06:28] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
- # [06:32] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
- # [06:33] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
- # [06:35] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
- # [06:35] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
- # [06:36] * Joins: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net)
- # [06:41] * Quits: tav (~tav`@host86-185-186-215.range86-185.btcentralplus.com) (Quit: tav)
- # [06:44] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
- # [06:44] * Joins: CvP (~CvP@203.76.123.238)
- # [06:51] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [06:52] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
- # [06:52] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [06:54] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
- # [06:56] * Quits: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net) (Quit: haydogsup)
- # [06:57] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Ping timeout: 256 seconds)
- # [06:58] * Joins: lerc (~quassel@121-74-5-229.telstraclear.net)
- # [07:01] * Quits: roc (~chatzilla@203.192.141.163) (Remote host closed the connection)
- # [07:14] * Quits: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [07:18] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [07:45] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [07:48] * Joins: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net)
- # [07:52] * Joins: zdobersek (~zan@46.166.188.198)
- # [07:55] * Quits: bengl (~bengl@2001:4c48:2:8400:2197:a078:580a:4d16) (Ping timeout: 244 seconds)
- # [08:01] * Quits: Bass10_ (Bass10@c-73-37-130-61.hsd1.mn.comcast.net) (Ping timeout: 245 seconds)
- # [08:07] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
- # [08:07] * Joins: bengl (~bengl@2001:4c48:2:8400:795e:295b:25c5:9c85)
- # [08:07] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [08:09] * Joins: rniwa (~rniwa@17.202.43.222)
- # [08:11] <jamesheston> Can anyone recommend any alternatives to Filezilla for OSX? Want to try something different.
- # [08:14] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [08:26] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
- # [08:28] * heycam is now known as heycam|away
- # [08:29] * Quits: hsivonen (~hsivonen@bugzilla.validator.nu) (Remote host closed the connection)
- # [08:34] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
- # [08:36] * Joins: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff)
- # [08:42] * Joins: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch)
- # [08:46] * Joins: annevk (~annevk@213.55.184.186)
- # [08:47] * Joins: roc (~chatzilla@121-99-82-169.bng1.tvc.orcon.net.nz)
- # [08:49] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Quit: estellevw)
- # [08:49] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
- # [08:49] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
- # [08:51] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
- # [08:52] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
- # [09:01] * Joins: hsivonen (~hsivonen@fsf/member/hsivonen)
- # [09:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 258 seconds)
- # [09:02] <zcorpan> TabAtkins: is bikeshed responsible for this URL? https://github.com/whatwg/url/blob/bd3f0ce38f61db5cfa2c485fef7aec2e4bdb0182/url.html#L26
- # [09:06] <annevk> Hixie: https://github.com/whatwg/platform.html5.org/pull/7
- # [09:23] * Joins: Mso150 (~ctlM@80.83.238.77)
- # [09:28] * Joins: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr)
- # [09:36] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
- # [09:36] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 250 seconds)
- # [09:38] * Joins: pfefferle (~pfefferle@213.144.11.136)
- # [09:48] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Ping timeout: 265 seconds)
- # [09:52] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [09:52] * Quits: annevk (~annevk@213.55.184.186) (Read error: Connection reset by peer)
- # [09:55] * Quits: zdobersek (~zan@46.166.188.198) (Ping timeout: 255 seconds)
- # [09:58] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [10:00] * Livadaw is now known as Livadi
- # [10:00] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
- # [10:00] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Client Quit)
- # [10:01] * Joins: laurensclaessen (~laurenscl@91.183.84.141)
- # [10:01] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
- # [10:02] * Joins: pfefferle_ (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de)
- # [10:03] * Quits: pfefferle (~pfefferle@213.144.11.136) (Ping timeout: 272 seconds)
- # [10:03] * pfefferle_ is now known as pfefferle
- # [10:07] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
- # [10:07] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Ping timeout: 245 seconds)
- # [10:07] * Joins: annevk (~annevk@213.55.184.186)
- # [10:08] * Quits: laurensclaessen (~laurenscl@91.183.84.141)
- # [10:10] * Quits: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff) (Ping timeout: 258 seconds)
- # [10:12] * Quits: annevk (~annevk@213.55.184.186) (Read error: Connection reset by peer)
- # [10:13] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
- # [10:26] * Joins: WesleyCrushed (~WesleyCru@host54-94-dynamic.59-82-r.retail.telecomitalia.it)
- # [10:26] * Joins: Lachy (~Lachy@213.166.174.2)
- # [10:27] * Quits: WesleyCrushed_ (~WesleyCru@host249-94-dynamic.59-82-r.retail.telecomitalia.it) (Read error: Connection reset by peer)
- # [10:33] * Quits: Mso150 (~ctlM@80.83.238.77) (Read error: Connection reset by peer)
- # [10:38] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
- # [10:38] * Joins: rubys1 (~rubys@cpe-098-027-051-253.nc.res.rr.com)
- # [10:39] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
- # [10:39] * Joins: CvP (~CvP@203.76.123.238)
- # [10:42] * Joins: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038)
- # [10:44] * Joins: annevk (~annevk@213.55.184.186)
- # [10:47] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [10:58] * Joins: espadrine_ (~ttyl@LMontsouris-656-1-02-84.w80-12.abo.wanadoo.fr)
- # [11:02] * Joins: charl (~charl@524A9047.cm-4-3c.dynamic.ziggo.nl)
- # [11:17] * Joins: darobin (~darobin@78.109.80.74)
- # [11:18] <annevk> rubys1: "If the @ flag is set, parse error, prepend "%40" to buffer." does not cause reordering...
- # [11:19] * rubys1 is now known as rubys
- # [11:20] <rubys> annevk: can you explain? If buffer has characters, and you put another character in front of those characters, doesn't that re-order?
- # [11:20] * Quits: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr) (Ping timeout: 264 seconds)
- # [11:20] <annevk> rubys: it only puts it in front if the flag was set, meaning it has to be in front
- # [11:21] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [11:21] <rubys> https://url.spec.whatwg.org/#authority-state
- # [11:22] <rubys> step 1.1; prepend. step 1.2, sets the flag. Next time through the loop, the flag is still set?
- # [11:22] * Joins: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr)
- # [11:23] <rubys> by the way, testing with chrome and firefox shows that re-ordering does occur.
- # [11:25] <rubys> (it also shows that browsers don't implement this interoperably)
- # [11:25] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
- # [11:29] <annevk> hmm, yeah, there's a bug there, I can't reproduce reordering in Firefox
- # [11:30] <rubys> ah, cool!. I'll change mine to simply string.replace('@', '%40')
- # [11:30] * Quits: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [11:30] <rubys> er, /@/g
- # [11:30] <annevk> rubys: btw, we say that diagrams are non-normative, yet you want to introduce normative ones...
- # [11:31] <annevk> rubys: and that spec is still lacking normative statements, and has some normative statements in notes, doesn't really seem ready
- # [11:31] <rubys> ack
- # [11:31] <rubys> I still have that on the todo list. I also don't really understand the comment, so some concrete suggestions would be helpful.
- # [11:32] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Remote host closed the connection)
- # [11:35] * Joins: tav (~tav`@host86-185-186-215.range86-185.btcentralplus.com)
- # [11:35] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
- # [11:35] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Client Quit)
- # [11:36] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [11:36] * Joins: cheron (~cheron@unaffiliated/cheron)
- # [11:38] <annevk> Also, a concern was raised that these productions are not accessible and that therefore it's hard to treat them as normative
- # [11:39] <annevk> s/productions/diagrams/
- # [11:39] <annevk> rubys: what is unclear about the comment?
- # [11:40] <rubys> valid concern. I can provide BNF-like notation as an alternate. Might need to work with TabAtkins to make that so.
- # [11:40] <MikeSmith> yeah seems like the CSS spec has the same issue if so
- # [11:40] <MikeSmith> specs
- # [11:41] <rubys> First, I don't understand how you have normative statements that say that you MUST do x, and then follow up with a statement that you don't need to do x, you just need to produce the same results as x.
- # [11:41] <MikeSmith> or are the railroad diagrams in the CSS specs never normative?
- # [11:41] <rubys> in CSS, they are not normative
- # [11:41] <MikeSmith> ok
- # [11:42] <rubys> MikeSmith: even so, it probably would be good if they were accessible.
- # [11:43] <MikeSmith> trueーunless it's clear from the context that they're simply illustrating some normative part of the spec
- # [11:44] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
- # [11:45] <rubys> MikeSmith: my understanding is that the normative part describes the full grammar (with error correction), and the non-normative diagrams are a simplified form explaining correct usage.
- # [11:45] <MikeSmith> ok
- # [11:45] <MikeSmith> makes sense
- # [11:45] <rubys> In the URL space, the grammar is much smaller
- # [11:47] <MikeSmith> sure
- # [11:47] * Joins: Lachy (~Lachy@213.166.174.2)
- # [11:50] <annevk> rubys: you MUST do x or equivalent and for brevity "or equivalent" is omitted and expanded upon elsewhere; that's pretty normal
- # [11:50] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [11:51] <rubys> annevk: can you identify a case where a MUST is missing? I work best from examples.
- # [11:52] <annevk> rubys: I thought you wanted to do the heavy lifting
- # [11:52] <annevk> rubys: if I still have to shift through everything and explain how to write a specification, I'm not sure it's going to be much quicker than just doing it myself
- # [11:53] <rubys> I didn't think asking for a single example was asking too much.
- # [11:53] <annevk> rubys: well currently the only places the spec uses MUST is in the conformance section and parse exceptions
- # [11:53] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
- # [11:54] <annevk> rubys: it seems pretty self-evident that requirements are missing in that case
- # [11:55] <annevk> rubys: it's not entirely clear to me currently what the entry point is
- # [11:55] <rubys> annevk: ok. It is still on the todo list (as listed in the spec). I fear that I'm playing "fetch me a rock", but I'll try.
- # [11:55] <annevk> rubys: I have the same feeling, whenever I point out something that's wrong, I get asked for examples, tests, and demonstrations
- # [11:55] * Joins: SkireM (~skirem@static.161.53.4.46.clients.your-server.de)
- # [11:56] <MikeSmith> incidentally, looking back at the CSS Syntax spec now, I wonder if I'm the only only who doesn't find it so useful that following a hyperlink for, e.g., "<string-token>" doesn't actually take me to any kind of definition of what a <string-token> isーnot even to an (informative) railroad diagram; instead it takes to me to... I don't know what http://dev.w3.org/csswg/css-syntax/#typedef-string-token And i
- # [11:56] <MikeSmith> f I want the actual normative definition of what a <string-token> is, there's nothing directly hyperlinked toーI just have to somehow know I need to read "Consume a string token" http://dev.w3.org/csswg/css-syntax/#consume-string-token
- # [11:57] <annevk> MikeSmith: that is pretty confusing
- # [11:58] <MikeSmith> annevk: yeah I am recalling now just how confusing I really find it when I was trying to understand the formalism for the "sizes" attribute value (which normatively refers to the CSS specs)
- # [11:58] <MikeSmith> *found it
- # [12:03] <annevk> rubys: I guess I should also say that I'm not okay with encouraging the W3C to fork whatwg/url
- # [12:03] <annevk> rubys: that happening just after I accepted working with you is rather surprising and discomforting, I'm not entirely sure if I want to proceed
- # [12:05] <rubys> annevk: two things. (1) I intend to work with everybody and anybody; and (2) I am entirely unimpressed with the lack of response by the webapps (in particular, the webapps chairs).
- # [12:06] <rubys> If Mike cares to, he can confirm that I have expressed my displeasure on this matter to all levels of W3C management.
- # [12:09] <rubys> regarding the timing, I had published my plan to do exactly what I am doing three weeks ago
- # [12:10] <rubys> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html
- # [12:10] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [12:11] <rubys> My experience is that when I ask questions in the WHATWG, I get answers. When I ask questions in WebApps, I get... silence.
- # [12:11] <MikeSmith> rubys: You may have noticed that I've stayed completely out of that conversation. Also I can imagine that Anne probably couldn't care less about the lack of response from the the webapps chairs or the WG on this because I can imagine he doesn't see what problem needs to be solved here, and he clearly doesn't think the solution is for the webapps WG to publish a copy of the URL spec
- # [12:12] <rubys> MikeSmith: ack
- # [12:12] <rubys> I do think that's a discussion we ought to have. Meanwhile, I plan to make my work available to everybody who might be interested.
- # [12:13] <rubys> My making it available to the WHATWG is not meant to be an exclusive arrangement.
- # [12:13] <MikeSmith> rubys: you're making to available to everybody simply by it being published at url.spec.whatwg.org under cc0
- # [12:14] <rubys> MikeSmith: actually, I'm making it available to everybody simply by publishing it at intertwingly.net under cc0.
- # [12:14] <MikeSmith> that works too
- # [12:14] <annevk> rubys: euhm, whatwg/url is not your work
- # [12:15] <rubys> I'm going back to working on code. I will arrange to have the proper people in this discussion, including the Director.
- # [12:16] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [12:16] <annevk> rubys: W3C's the Director has not written whatwg/url either
- # [12:17] <MikeSmith> rubys: the discussion you seemed to be having here seemed to be a useful one for you and anne to have as co-editors and seems like it could be had separately from any other people or from the W3C Director
- # [12:19] * jgraham wonders if MikeSmith has "W3C Director" as an irc keyword ;)
- # [12:23] * Quits: annevk (~annevk@213.55.184.186) (Remote host closed the connection)
- # [12:23] * Joins: annevk (~annevk@80-218-216-100.dclient.hispeed.ch)
- # [12:23] <rubys> annevk: an example of my confusion: I don't see a single "MUST" here: https://url.spec.whatwg.org/#percent-decode
- # [12:24] <annevk> rubys: as I said, it depends on the entry point
- # [12:26] <rubys> entry point? The only other mention to this is in the index.
- # [12:26] <annevk> rubys: that's not true
- # [12:26] <annevk> rubys: click on it
- # [12:27] <rubys> weird. firefox couldn't find that.
- # [12:27] <rubys> ah, "percent decoding"
- # [12:27] <rubys> "Let domain be the result of utf-8 decode without BOM on the percent decoding of utf-8 encode on input. "
- # [12:27] <rubys> Still no must
- # [12:28] <annevk> rubys: still no entry point :-) it's mostly the API that requires things
- # [12:28] <annevk> rubys: and other specs that reference these algorithms
- # [12:28] * Joins: Lachy (~Lachy@213.166.174.2)
- # [12:28] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
- # [12:28] <rubys> what I have is a spec fragment, rewriting the parsing logic. Logic that doesn't have musts in either the current url standard or in my proposed replacement.
- # [12:29] <jgraham> annevk: I can't see any text in url that explicitly says that when you are asked to run an algorithm only black-box indistinguishability matters
- # [12:29] <annevk> jgraham: "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)"
- # [12:29] <rubys> jgraham: https://url.spec.whatwg.org/#conformance
- # [12:29] * Quits: Lachy (~Lachy@213.166.174.2) (Client Quit)
- # [12:30] <jgraham> Oh, that's at the bottom now? How very confusing
- # [12:30] <annevk> rubys: it might be okay, though then that lone MUST is confusing
- # [12:31] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
- # [12:31] <rubys> jgraham: bikeshed templates do that, not sure why.
- # [12:31] <annevk> jgraham: blame TabAtkins
- # [12:32] <rubys> perhaps we need to add "This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references."
- # [12:32] <jgraham> I guess someone thought that getting to the actual spec without the boilerplate stuff was a good idea. But having the "important stuff you need to know to understand the spec" at the top of the spec rather than at the bottom does seem to make more sense
- # [12:34] <jgraham> Or there could be a meta-specification and the top of the spec could just say "this spec must be read according to the WHATWG specification specification"
- # [12:34] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [12:34] <jgraham> (that is essentially what RFC 2119 is ofc)
- # [12:34] <annevk> jgraham: I have at times wanted to write the "Boilerplate Standard" that also includes common terminology
- # [12:38] * Quits: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr) (Ping timeout: 265 seconds)
- # [12:40] <rubys> MikeSmith, annevk: since you are both here, I appear to have update access to web-platform-tests; should I still do pull requests for changes to url/urltestdata.txt?
- # [12:40] <jgraham> rubys: Yes, see my message to whatwg
- # [12:41] <rubys> jgraham: ok, I can work with that.
- # [12:41] <rubys> jgraham: should I do one pull request or three?
- # [12:44] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-rliacfmcozzecuth)
- # [12:44] * Joins: danbri (Adium@nat/google/x-gilinxmbxlhzhajg)
- # [12:47] * Quits: annevk (~annevk@80-218-216-100.dclient.hispeed.ch) (Quit: Leaving...)
- # [12:47] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [12:48] <jgraham> rubys: That's up to you
- # [12:48] * Joins: hasather_ (~hasather@guest.schibsted.no)
- # [12:48] * Joins: Lachy (~Lachy@213.166.174.2)
- # [12:49] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
- # [12:50] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
- # [12:50] * Joins: calvaris (~calvaris@fanzine.igalia.com)
- # [12:51] * Joins: annevk (~annevk@80-218-216-100.dclient.hispeed.ch)
- # [12:54] * Joins: pfefferle_ (~pfefferle@213.144.11.130)
- # [12:55] * Quits: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
- # [12:55] * pfefferle_ is now known as pfefferle
- # [13:00] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
- # [13:00] * Joins: CvP (~CvP@203.76.123.238)
- # [13:05] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [13:17] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-swjhadjcwscivfdo) (Quit: Connection closed for inactivity)
- # [13:20] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
- # [13:24] * Joins: jahman (~woops@129.175.204.73)
- # [13:39] * Quits: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038) (Ping timeout: 272 seconds)
- # [13:39] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [13:40] * Joins: Lachy (~Lachy@213.166.174.2)
- # [13:40] * Joins: Smylers (~smylers@81.143.60.194)
- # [13:43] * Joins: plutoniix (~plutoniix@node-3su.pool-125-25.dynamic.totbb.net)
- # [13:43] * Quits: SkireM (~skirem@static.161.53.4.46.clients.your-server.de) (Quit: Nettalk6 - www.ntalk.de)
- # [13:45] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [13:46] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
- # [13:48] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [13:55] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
- # [13:55] * Quits: hasather_ (~hasather@guest.schibsted.no) (Remote host closed the connection)
- # [13:55] * Joins: eBureau (~Bruno@181.164.77.172)
- # [13:56] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Client Quit)
- # [13:57] * Joins: hasather (~hasather@guest.schibsted.no)
- # [14:03] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
- # [14:13] <annevk> hsivonen: https://news.ycombinator.com/item?id=8624160 is terrible
- # [14:13] <annevk> hsivonen: trying very hard to not 386 the entire thread
- # [14:15] <annevk> hsivonen: it has everything, praising EV, dissing DV, suggestions to replace the entire crypto stack because it's too complicated, ...
- # [14:15] * Joins: samn (~samn@gateway.creuna.se)
- # [14:15] * Quits: samn (~samn@gateway.creuna.se) (Remote host closed the connection)
- # [14:16] * Joins: tripu (~tripu@ANice-653-1-606-231.w86-205.abo.wanadoo.fr)
- # [14:18] <annevk> hsivonen: I was going to tweet HN jumped the shark, but then I found https://news.ycombinator.com/item?id=1339857
- # [14:18] * Joins: ^esc (~esc-ape@178.115.131.113.wireless.dyn.drei.com)
- # [14:23] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [14:27] <jgraham> The other possible response is to assume that this represents the real opinions of a subset of the relatively-tech-literate population and work out how to fix that, if necessary
- # [14:29] * Joins: eric_carlson (~ericc@38.104.134.62)
- # [14:29] <jgraham> I'm guessing a post suggesting that forum jumped the shark isn't going to help (c.f. the fact that post got modded into grey). I'm guessing a more informative post written there would help more, but not that much, since it comes across as no more authoratative than any other post
- # [14:30] * Joins: Ms2ger (~Ms2ger@nata206.ugent.be)
- # [14:35] <Ms2ger> MikeSmith, thanks again :)
- # [14:36] <MikeSmith> Ms2ger: happy to help
- # [14:39] * Joins: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038)
- # [14:39] * Joins: tj_vantoll (~Adium@2601:4:5380:2ec:b89e:8f5:9b67:d34c)
- # [14:46] * Quits: eric_carlson (~ericc@38.104.134.62) (Quit: eric_carlson)
- # [14:47] <rubys> annevk: OK, I've had my coffee. If you want to talk about copying, let me know if you are available.
- # [14:49] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [14:51] <MikeSmith> rubys: see critic for comments on the urltestdata.txt PR
- # [14:51] * Joins: zdobersek (~zan@185.3.135.138)
- # [14:53] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-wnbhcvapczrffanx)
- # [14:53] <rubys> MikeSmith: wierd. I copy and pasted from working code. Odd that I lost spaces in that process. Good catch!
- # [14:53] <MikeSmith> rubys: and btw thanks extremely much for providing the relevant citations/links for the changes. I wish everybody would do that, and I hope you keep doing it. It saves a lot of reviewing time.
- # [14:53] <rubys> MikeSmith: yw. It is second nature to me to do so, and I plan to continue.
- # [14:54] <MikeSmith> cool
- # [14:56] <MikeSmith> rubys: btw I notice also that there's some unrelated borkedness in the expected behavior of the harness in Chrome at least. Compare the results for the last test (Parsing: <x> against <test:test>) in Chrome and Firefox
- # [14:56] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
- # [14:57] * Joins: CvP (~CvP@203.76.123.238)
- # [14:57] <MikeSmith> rubys: in my Chromium build at least, it says 'assert_equals: href expected "x" but got ""' but that's clearly not what the test is actually saying
- # [14:57] * MikeSmith re-checks it in stable Chrome
- # [14:58] <MikeSmith> yeah, same thing in stable Chrome
- # [14:59] <rubys> MikeSmith: try it here: https://url.spec.whatwg.org/reference-implementation/liveview2.html (it isn't just the harness)
- # [14:59] <MikeSmith> rubys: also, in all UAs, the "assert_unreached: Expected URL to fail parsing Reached unreachable code" fails are all wrong. They should all be passes.
- # [14:59] <MikeSmith> rubys: looking now
- # [15:01] <rubys> MikeSmith: FYI, I haven't actually looked at test harness. Ever. I've only "adopted" the test data.
- # [15:02] <rubys> MikeSmith: OK, I've updated the pull request. What do I need to do with the critic comments?
- # [15:02] <MikeSmith> rubys: OK. and yeah of course I didn't mean to suggest that the harness problems were something for you to fix
- # [15:02] <MikeSmith> rubys: they should be resolved automatically
- # [15:03] <MikeSmith> that's one of the nice features of critic
- # [15:03] <rubys> MikeSmith: it seems possible that there isn't a harness problem; as a "black box", Chrome behaves a bit unpredictably when dealing with unknown url schemes.
- # [15:04] <MikeSmith> ah
- # [15:04] <MikeSmith> yeah that makes sense
- # [15:05] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 245 seconds)
- # [15:06] * Quits: tj_vantoll (~Adium@2601:4:5380:2ec:b89e:8f5:9b67:d34c) (Read error: Connection reset by peer)
- # [15:08] <MikeSmith> rubys: I can't tell from https://url.spec.whatwg.org/reference-implementation/liveview2.html whether I'm seeing the expected result for the "Parsing: <x> against <test:test>" case
- # [15:08] * Joins: sarri (~sari@unaffiliated/sarri)
- # [15:08] <rubys> do you see any red?
- # [15:08] <MikeSmith> rubys: no but I guess I expect it would clearly say "Parsing failed as expected" or something
- # [15:09] <MikeSmith> instead it says "href https://url.spec.whatwg.org/reference-implementation/liveview2.html" and "hostname url.spec.whatwg.org" etc.
- # [15:09] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
- # [15:09] * Joins: jdaggett (~jdaggett@ae031063.dynamic.ppp.asahi-net.or.jp)
- # [15:09] <MikeSmith> which to mean implies that it's successfully parsing a URL, though not the URL I asked it to parse
- # [15:09] <rubys> MikeSmith: you are using chrome?
- # [15:10] <MikeSmith> I see the same thing in both Firefox and Chrome for this
- # [15:10] <rubys> MikeSmith: In Chrome do exactly what I say, in this order:
- # [15:10] * MikeSmith nods
- # [15:10] <rubys> 1) refresh. 2) enter test:test in base, 3) enter x in the first input field
- # [15:10] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ulqtiktvsjlvioun)
- # [15:11] <rubys> my conclusion: order matters, and this "black box" is unpredictable.
- # [15:12] <rubys> when parsing fails, you shouldn't see https://url.spec.whatwg.org/reference-implementation/liveview2.html, you should see ":" for protocol, what you specified in href, and nothing else different.
- # [15:12] <rubys> s/else different/else/
- # [15:13] <rubys> For example, try http://foo:x/ as the input, which fails predictably.
- # [15:13] <rubys> Chrome gives a port number of 0 in that case, which is out of spec, but at least sane.
- # [15:14] <MikeSmith> rubys: OK yeah I see different results now when I fill in the base URL field first, then the URL field
- # [15:14] <MikeSmith> rubys: but I see different results in Firefox also, when I change the order
- # [15:14] * Joins: prosper (~prosper@142.150.23.90)
- # [15:15] * prosper is now known as Guest27368
- # [15:15] <rubys> frameworks don't always do well when the function they are testing behave unpredictably :-)
- # [15:15] <MikeSmith> sure
- # [15:15] <rubys> MikeSmith: see pm
- # [15:17] * Quits: Ms2ger (~Ms2ger@nata206.ugent.be) (Ping timeout: 250 seconds)
- # [15:19] <annevk> MikeSmith: the test format is very peculiar, I can take a look later
- # [15:21] * Quits: Guest27368 (~prosper@142.150.23.90) (Ping timeout: 258 seconds)
- # [15:21] * Quits: CvP (~CvP@203.76.123.238) (Ping timeout: 272 seconds)
- # [15:23] * Joins: CvP (~CvP@203.76.123.238)
- # [15:25] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
- # [15:30] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [15:30] <annevk> rubys: I'm mostly available now, is there anything more to say?
- # [15:31] <rubys> I have plenty to say. How would you like to have the discussion? PM, here, email, ... ?
- # [15:31] * Joins: TallTed (~Thud@63.119.36.36)
- # [15:33] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [15:34] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 272 seconds)
- # [15:34] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
- # [15:35] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [15:35] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [15:36] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Client Quit)
- # [15:36] * Joins: boogyman (~boogyman@38.88.11.131)
- # [15:36] * Quits: boogyman (~boogyman@38.88.11.131) (Changing host)
- # [15:36] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
- # [15:37] * Joins: haydogsup (~haydogsup@rrcs-97-77-44-2.sw.biz.rr.com)
- # [15:44] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [15:46] * Joins: hasather_ (~hasather@80.91.33.141)
- # [15:47] * Quits: jahman (~woops@129.175.204.73) (Read error: Connection reset by peer)
- # [15:48] * Joins: jahman (~woops@129.175.204.73)
- # [15:48] * Quits: haydogsup (~haydogsup@rrcs-97-77-44-2.sw.biz.rr.com) (Quit: haydogsup)
- # [15:49] <annevk> rubys: www-archive or here would be fine
- # [15:50] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
- # [15:50] <rubys> annevk: give me a sec, I'll post to www-archive, and then we can discuss here (it is a half-dozen paragraphs+ of material at this point)
- # [15:51] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
- # [15:54] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [15:55] <rubys> http://lists.w3.org/Archives/Public/www-archive/2014Nov/0023.html
- # [15:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
- # [15:57] * Quits: TallTed (~Thud@63.119.36.36)
- # [16:01] * Joins: Ms2ger (~Ms2ger@nata200.ugent.be)
- # [16:05] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [16:06] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
- # [16:11] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
- # [16:11] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [16:12] * Joins: mven (~textual@32.97.110.57)
- # [16:13] * Joins: Una (~Una@32.97.110.57)
- # [16:15] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
- # [16:21] * Quits: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch) (Quit: cbr_)
- # [16:22] * Joins: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch)
- # [16:26] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Quit: shepazu)
- # [16:28] * Joins: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
- # [16:34] * Joins: jyasskin (~jyasskin@207.198.105.19)
- # [16:37] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [16:42] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [16:43] <annevk> rubys: I don't really see it addresses the point, other than you disagreeing with my position
- # [16:44] * Joins: TallTed (~Thud@63.119.36.36)
- # [16:46] * Joins: thinkxl (~thinkxl@2602:30a:c00c:59:c4d8:6c61:a169:d57d)
- # [16:47] <rubys> annevk: I would be sad if the only solution I had available to fixing the problems I see in the URL spec is to rewrite everything myself.
- # [16:48] <annevk> rubys: that seems like a non-sequitur given that I gave you commit access
- # [16:48] <rubys> annevk: It seems that commit access was given with a string that I wasn't aware of. And that you are reconsidering that. I'd like to discuss.
- # [16:49] <rubys> we clearly have philosophical differences; but I'm convinced that operationally they don't matter.
- # [16:50] <rubys> you'd prefer an approach which actively denies WebApps the ability to work on the URL spec; I'd prefer an approach which gives them the opportunity to do so, with the expectation that they won't.
- # [16:50] <Ms2ger> rubys, nobody denies anyone any ability
- # [16:50] <Ms2ger> rubys, that doesn't mean it's a good idea
- # [16:51] <annevk> rubys: you offered to be editor
- # [16:51] <annevk> rubys: and I don't think that is what I prefer as "approach"
- # [16:51] <rubys> annevk: I made that offer to both the W3C and the WHATWG
- # [16:53] <annevk> rubys: what I prefer is that we have a single version of the specification, available under CC0; and I want that idea to be shared by any active collaborators (e.g. those that commit)
- # [16:54] <annevk> rubys: it was not clear to me what upon getting commit access you would ship the repository around to other standards bodies
- # [16:55] <rubys> annevk: I agree with that goal. The proposal to update the WebApps version predated my contributions and eventual acceptance as editor.
- # [16:55] <annevk> rubys: that is in your right of course, but then I would prefer that we go back to the PR-style way of working together
- # [16:55] * Domenic reminds everyone to assume good intent...
- # [16:55] <rubys> I will state that I agree with "a single version of the specification, available under CC0; and I want that idea to be shared by any active collaborators (e.g. those that commit)"
- # [16:56] <rubys> I will also state that I don't think it quite is there yet, but I am hopeful that it will be.
- # [16:56] <annevk> rubys: given point bad-3 in your email that seems untrue
- # [16:56] * Joins: newtron (~newtron@199.71.174.203)
- # [16:56] <rubys> annevk: ok, then let me explain
- # [16:56] <annevk> rubys: unless my sentence was not specific enough...
- # [16:57] <Domenic> (I didn't interpret bad-3 that way.)
- # [16:57] <annevk> Domenic: how did you interpret it?
- # [16:57] <rubys> I believe that the barrier to entry for participation is too high on some specs at the WHATWG. Dominic's spec work is an example that others should follow.
- # [16:58] <rubys> What I see in streams is a signs of a true meritocracy, much like I see at the Apache Software Foundation.
- # [16:58] <Domenic> annevk: I interpreted bad-3 as he does not agree with the general WHATWG stance on copying in principle, but in combination with good-3, rubys seems fine going along with that stance in practice.
- # [16:58] <rubys> The fact that I am able to scale that barrier to entry isn't evidence that the barrier to entry is too high.
- # [16:59] <rubys> If the barrier remains too high, I'll eventually decide to work elsewhere and accept a suboptimal license.
- # [17:00] <rubys> And that would make me sad.
- # [17:00] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
- # [17:00] <annevk> rubys: how is Streams different?
- # [17:01] <rubys> https://github.com/whatwg/streams - 8 contributors. https://github.com/whatwg/url - 2 contributors.
- # [17:02] <rubys> I will state this: if you allow me to continue to co-edit, I WILL build a community. I WILL have the meeting with the W3C Director and actively challenge the need for a copy.
- # [17:03] <rubys> And I will do that based on evidence, not philosophy.
- # [17:03] * Quits: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038) (Ping timeout: 258 seconds)
- # [17:04] <annevk> rubys: okay, sounds good, make it happen
- # [17:04] <rubys> sweet!
- # [17:05] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
- # [17:05] <annevk> Looking at https://github.com/whatwg/streams/graphs/contributors though it's not that diverse, but at least the number is higher :-)
- # [17:05] <rubys> Note: this conversation is publicly archived. If I don't follow through, feel free to call me on it.
- # [17:06] <Domenic> streams has good diversity in the issue tracker. the actual contributions are mostly takeshi and I, plus a few editorial corrections.
- # [17:06] <Domenic> also lol how you can see when i joined google from that graph :P
- # [17:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
- # [17:07] * Quits: Una (~Una@32.97.110.57) (Read error: Connection reset by peer)
- # [17:13] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
- # [17:13] <hsivonen> jgraham: do you have ideas how to make the relatively tech literate crowd see that certifying the binding between a public key and a host name has value?
- # [17:15] * Quits: markkes (~markkes@62.207.90.201) (Quit: markkes)
- # [17:17] <wilhelm> hsivonen: Which additional attack vectors are possible without that certification?
- # [17:17] * Quits: Ms2ger (~Ms2ger@nata200.ugent.be) (Ping timeout: 250 seconds)
- # [17:17] * Joins: jwalden (~waldo@2620:101:80fb:224:7e7a:91ff:fe25:a5a3)
- # [17:18] <hsivonen> wilhelm: a MITM establishing an encrypted connection with the browser and another with the origin server and either reading or modifying the traffic as the MITM moves it from one pipe into the other
- # [17:18] <hsivonen> wilhelm: (or the MITM establishing an encrypted connection with the browser and not even bothering with taking any data from the real server)
- # [17:19] <hsivonen> wilhelm: so without authenticity, a MITM can compromise both integrity and confidentiality
- # [17:20] <hsivonen> on the topic of https, an https-enabled validator.nu exist but DNS doesn't point to it yet, because I want to avoid breaking legacy API clients
- # [17:20] <hsivonen> so I want a redirect from http to https that only happens if the method is GET and there is no query string
- # [17:20] <hsivonen> can someone teach me how to do that in nginx?
- # [17:21] <hsivonen> I can do a redirect conditional on the method being GET
- # [17:21] * Joins: jsx (uid48919@fsf/intern/jsx)
- # [17:21] <hsivonen> and I can do a redirect conditional on the query string being empty
- # [17:21] <hsivonen> but I don't know how to check for both conditions at the same time
- # [17:23] <wilhelm> hsivonen: That's the attack vector I assumed. Wouldn't merely pointing to that convince the audience?
- # [17:25] * Quits: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch) (Quit: cbr_)
- # [17:25] * Quits: jyasskin (~jyasskin@207.198.105.19) (Ping timeout: 255 seconds)
- # [17:27] <hsivonen> wilhelm: apparently not. people seem to assume that the set of MITMs that can only read and not write is significant
- # [17:27] * Joins: jyasskin (~jyasskin@207.198.105.19)
- # [17:28] <annevk> hsivonen: it seems to me so much that's like flipping a switch, maybe not quite right now, but definitely down the line
- # [17:30] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [17:38] <hsivonen> annevk: the notion that backbone MITMs can't write *as much* data at a given time as they can read seems believable
- # [17:38] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
- # [17:38] <hsivonen> annevk: so it's probably not a flip of the switch for equal amounts of MITMing in all cases
- # [17:39] <hsivonen> annevk: but it does seem naive to assume that a MITM who can read can't write at all
- # [17:39] <hsivonen> annevk: and then you don't know when the MITM is writing
- # [17:40] <annevk> hsivonen: was it claimed that you could detect MITM?
- # [17:40] <hsivonen> annevk: with TOFU, you can detect if your first connection happened to be clean
- # [17:42] <hsivonen> of course, with TOFU, people just assume that the key changed for benign reasons
- # [17:45] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
- # [17:45] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [17:46] <hsivonen> nginx is usually awesome, but the redirect stuff is remarkably inflexible (likely to be very fast)
- # [17:47] * Quits: jyasskin (~jyasskin@207.198.105.19) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [17:47] * Joins: jernoble (~jernoble@76.74.153.49)
- # [17:52] <jgraham> hsivonen: publicise a tool that makes MITMing a site served using a self-signed cert trivial (c.f. firesheep)?
- # [17:55] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
- # [17:57] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [17:59] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [18:05] <TabAtkins> jgraham: Don't blame me, it's a result of the boilerplate that Domenic wrote for WHATWG specs. (Which he partially based on the CSSWG boilerplate, probably.)
- # [18:07] * Joins: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se)
- # [18:11] * Joins: thinkxl_ (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
- # [18:13] * Quits: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se) (Ping timeout: 265 seconds)
- # [18:13] * Joins: Una (~Una@32.97.110.57)
- # [18:14] * Quits: thinkxl (~thinkxl@2602:30a:c00c:59:c4d8:6c61:a169:d57d) (Ping timeout: 258 seconds)
- # [18:14] * Joins: Ms2ger (~Ms2ger@8.210-242-81.adsl-dyn.isp.belgacom.be)
- # [18:14] * thinkxl_ is now known as thinkxl
- # [18:14] * Joins: zcorpan (~zcorpan@81-231-171-143-no135.tbcn.telia.com)
- # [18:15] * Quits: pfefferle (~pfefferle@213.144.11.130) (Ping timeout: 255 seconds)
- # [18:15] * Joins: Maurice` (copyman@unaffiliated/maurice)
- # [18:15] * Joins: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de)
- # [18:15] * Joins: jyasskin (~jyasskin@216.239.45.222)
- # [18:16] * Joins: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net)
- # [18:19] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
- # [18:29] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 272 seconds)
- # [18:30] * Krinkle|detached is now known as Krinkle
- # [18:36] * Quits: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
- # [18:39] * Quits: hasather_ (~hasather@80.91.33.141) (Remote host closed the connection)
- # [18:40] * Joins: hasather (~hasather@80.91.33.141)
- # [18:40] <gsnedders> zcorpan: grattis!
- # [18:40] <zcorpan> gsnedders: tack!
- # [18:41] <TabAtkins> jgraham: But it's also a good idea, in general, to move that crap out of the top of the spec. You read it once, you internalize it, you're done. Requiring people to scroll past it every time is a bit reader-hostile. (At least, that was our reasoning in the CSSWG when we rejiggered our boilerplate.)
- # [18:43] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
- # [18:44] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Ping timeout: 265 seconds)
- # [18:45] <TabAtkins> zcorpan: That url comes from WHATWG's boilerplate files in Bikeshed. If something's wrong with it, it can be corrected.
- # [18:45] * Quits: CvP (~CvP@203.76.123.238) (Quit: [ UPP ] > all)
- # [18:45] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [18:46] <zcorpan> TabAtkins: it should be https://whatwg.org/
- # [18:46] <wilhelm> hsivonen: Setting up a rogue access point just to MITM people is trivial.
- # [18:47] * Joins: CvP (~CvP@203.76.123.238)
- # [18:47] <TabAtkins> zcorpan: Fixed.
- # [18:48] <TabAtkins> rubys: What's this about BNF-like notation?
- # [18:48] <zcorpan> TabAtkins: thx
- # [18:48] <rubys> TabAtkins: there needs to be an accessible alternative to the railroad diagrams
- # [18:48] <TabAtkins> rubys: If I'm understanding correctly, it's about you wanting to define some things in terms of a normative railroad diagram?
- # [18:49] <rubys> whether it is normative or not, if it is useful, it should be accessible
- # [18:49] <TabAtkins> Ah, kk. I'd like to have such a thing, so I can add a <title> to the SVG.
- # [18:49] * Quits: eric_carlson (~ericc@156.39.191.244) (Client Quit)
- # [18:49] <TabAtkins> I'll bet I could auto-generate BNF from the diagram code.
- # [18:49] * Quits: jernoble (~jernoble@76.74.153.49) (Quit: Computer has gone to sleep.)
- # [18:50] <rubys> I also can meet you half way if you like. I generate the Railroad diagrams from peg.js input, so if you provide me a means to provide extra input, I can likely do so in a few lines of code.
- # [18:50] <zcorpan> i recall a proposal at tpac about an svg <connector> or something, to connect things in a way that can be communicated to AT
- # [18:51] <rubys> TabAtkins: very low on the priority list, but I've seen a few cases where the vertical alignment is off. I've rejiggered some to avoid the problem, but a few remain.
- # [18:51] <TabAtkins> Yes.
- # [18:51] <TabAtkins> rubys: Ooh, point out when you find them.
- # [18:51] <rubys> http://intertwingly.net/projects/pegurl/url.html#host
- # [18:52] <rubys> File had a vertical gap (extra whitespace) and overlap. By reordering, I made that go away.
- # [18:53] * Quits: Ducki (~Ducki@191.233.66.1) (Ping timeout: 244 seconds)
- # [18:55] <TabAtkins> rubys: Hmm, I see.
- # [18:57] <rubys> I'll open two issues to track this? Make railroad diagrams accessible, and fix vertical alignment? Or is that unnecessary/unhelpful?
- # [18:57] <TabAtkins> Go for it!
- # [18:57] <TabAtkins> Issues are always good.
- # [18:58] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [18:58] * Joins: Jirka (~Jirka@95.85.233.233)
- # [19:01] <rubys> done
- # [19:07] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [19:08] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [19:08] * Quits: zcorpan (~zcorpan@81-231-171-143-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
- # [19:08] * Joins: jarek (~jarek@unaffiliated/jarek)
- # [19:08] <jarek> Hi
- # [19:08] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [19:08] <jarek> What is the difference between node.prototype.querySelector() and node.prototype.query() ?
- # [19:09] <Domenic> jarek: query() isn't implemented yet, but when it is, it'll be better in a few ways:
- # [19:09] <Domenic> 1) it'll work with selector strings like "> div", which QS fails on
- # [19:09] <Domenic> oh wait I think that's most of it because you asked about query vs. querySelector not queryAll vs. querySelectorAll
- # [19:09] <jarek> Domenic: what about queryAll? How is it better than querySelectorAll?
- # [19:10] <Domenic> jarek: it returns an instance of Elements, which is a proper Array subclass, which is awesome.
- # [19:10] <terinjokes> Domenic: you mean qS(A) doesn't support the exact string of "> div"?
- # [19:11] <Domenic> terinjokes: yeah it uses "selector" instead of "relative selector"
- # [19:11] <jarek> Domenic: is it safe to shim query()/queryAll() by just aliasing it to querySelector()/querySelectorAll()?
- # [19:11] <Domenic> jarek: no, definitely not.
- # [19:11] <Domenic> jarek: use https://github.com/barberboy/dom-elements, it's pretty OK
- # [19:12] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [19:12] <jarek> there was another collection class introduced in DOM? Why not just make NodeList inherit from Array?
- # [19:13] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
- # [19:14] <annevk> jarek: there's no "just"
- # [19:14] <Domenic> jarek: that breaks the web... lemme find the bug
- # [19:14] <Domenic> wow all of these answers are wrong http://stackoverflow.com/questions/13433799/why-doesnt-nodelist-have-foreach
- # [19:15] <Domenic> ah here we go https://esdiscuss.org/topic/why-does-legacy-content-break-when-making-array-likes-real-arrays
- # [19:15] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Ping timeout: 256 seconds)
- # [19:15] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [19:17] <caitp> it's hard not to be wrong when talking about js
- # [19:17] <jarek> is there also some alternative to node.children that would give Elements instance instead of NodeList?
- # [19:18] <Domenic> node.queryAll("> *")
- # [19:18] <jarek> Domenic: uhm... for (let child of this.queryAll("> *")) doesn't look very readable
- # [19:19] <Domenic> seems fine to me
- # [19:20] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [19:20] <jarek> I think I'm sticking with NodeList, with ES6 it will be very easy to convert NodeList to Array, e.g. let childrenArray = [...element.children]
- # [19:20] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [19:20] <Domenic> *shrug*
- # [19:20] <jarek> [...this.children].forEach( (child) => console.log(child))
- # [19:21] <Domenic> You can't convert children to an array unless we make children iterable
- # [19:21] <Domenic> s/children iterable/NodeList iterable/
- # [19:21] <caitp> which would probably be a good idea, I mean
- # [19:21] <Domenic> yeah
- # [19:21] <TabAtkins> Domenic: Which I assume we'd do, since it's a symbol property and so won't be problematic int he same way.
- # [19:21] <jarek> Domenic: I can make NodeList iterable myself :P
- # [19:21] <Domenic> in which case it's just for (const child of this.children) { ... }
- # [19:22] <caitp> it would kind of suck to have to manually polyfill NodeList / HTMLCollection / etc to be iterable
- # [19:26] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [19:29] <annevk> jgraham: specification authors not maintaining their specification is also bad, though ;-)
- # [19:29] <annevk> NodeList is already iterable
- # [19:31] <Hixie> not that my opinion matters on this, but fwiw, i prefer conformance at the top, and for the bottom to be indices, references, acks, in that order.
- # [19:31] <Hixie> conformance at the bottom in particular is quite confusing to me at first :-)
- # [19:31] <TabAtkins> Hixie: I can definitely say I'm happy that our conformance moved to the bottom, because it means less PgDn necessary to get to the spec text.
- # [19:32] <jgraham> annevk: Right, but most bugs in implementations aren't bugs in specifications
- # [19:32] <Hixie> tab: yeah, i guess it depends on the spec. when you have the table of contents and then a multipage intro before anything else, the issue of whether the conformance section is before or after the rest of the spec text is pretty moot.
- # [19:32] <annevk> jgraham: do we have data on that? Often a clearer specification would help
- # [19:33] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [19:33] <Hixie> tab: (and HTML's conformance section is pretty big in practice, it's not really just boilerplate)
- # [19:33] <annevk> jgraham: oops, I don't have data either, so I should not have said that second thing :-)
- # [19:33] <jgraham> annevk: I have a hard time believing that most platform bugs in Gecko (for example) were actually spec bugs
- # [19:34] <jgraham> It's certainly *sometimes* true, but you have a huge observer bias since you almost only see bugs where it is true
- # [19:34] * Joins: ap_ (~ap@17.202.44.214)
- # [19:34] * Ms2ger must be missing context
- # [19:34] <jgraham> But yeah I can't prove it
- # [19:34] <jgraham> Ms2ger: whatwg@
- # [19:35] <jgraham> Well I assume, either that or I have no idea waht annevk is on about :)
- # [19:35] * Quits: tripu (~tripu@ANice-653-1-606-231.w86-205.abo.wanadoo.fr) (Quit: Leaving)
- # [19:35] * annevk isn't sure what jgraham is on about either
- # [19:35] <Ms2ger> Ha
- # [19:35] * Joins: eBureau (~Bruno@181.164.77.172)
- # [19:37] <annevk> Hixie: it certainly seems that in practice "Conformance" being boilerplate would help implementers, as they are unlikely to read the whole document
- # [19:37] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
- # [19:37] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
- # [19:37] <annevk> Hixie: not that I'm particularly happy about the new section ordering, but I haven't really put time into appreciating it either
- # [19:38] <jarek> I recall there were some plans to introduce document.createElement("svg:rect") in place of document.createElement("http://www.w3.org/2000/svg", "rect")
- # [19:38] <Hixie> my "conformance" section includes pages and pages of terminology definitions that other specs rely on, as well as references to other specs that i rely on, a long description of all the conformance classes which is pretty html-specific, etc.
- # [19:38] <jarek> ^ is this standarized anywhere already?
- # [19:38] <TabAtkins> jarek: No.
- # [19:38] <Ms2ger> No
- # [19:38] <Hixie> the actual boilerplate is only a few paragraphs but having that specifically moved elsewhere would be really weird and wouldn't really help tab's page-down-count issue.
- # [19:38] <jarek> it should be document.createElementNS("http://www.w3.org/2000/svg", "rect")
- # [19:38] <tantek> qnames lol
- # [19:39] <jarek> TabAtkins: how likely is this proposal to get accepted? Would it be reasonable to shim it already?
- # [19:39] <jarek> createElementNS feels out of place in HTML5, there has to be better API introduced
- # [19:39] <Ms2ger> Quite unlikely
- # [19:40] <TabAtkins> Nobody's really picked it up after the initial thread wound down, so no clue what it'll eventually look like. Do whatever you want for your own APIs, though. No need to shim document.createElement(), that's a terrible long name anyway.
- # [19:40] <tantek> you had me at NS feels out of place in HTML5
- # [19:40] <Hixie> document.createElementNetscape() ? :-)
- # [19:40] <TabAtkins> In my Python code I have an E class, so I can write `E.div({"class":"foo"}, "some text")`
- # [19:41] * Joins: Mso150 (~ctlM@80.83.239.11)
- # [19:41] <TabAtkins> Making your own element-creation helper in that vein would be better.
- # [19:41] * Hixie uses an E function, as in E('div', {class:'foo'}, 'some text', ...)
- # [19:41] <Hixie> where "some text" is any child elements
- # [19:41] <Hixie> including further nested E()s
- # [19:41] <Hixie> better than DOM, but still worse than E4H
- # [19:42] <jarek> Hixie: did you mean E4X?
- # [19:43] <jarek> Hixie: with ES6 E4X-like element creation is already possible
- # [19:43] <Hixie> i meant http://hixie.ch/specs/e4h/strawman
- # [19:44] <Hixie> as far as i can tell, that is incorrect. es6 lacks the key feature that i need, compile-time syntax checking.
- # [19:44] <jarek> Hixie: I see, I hope this was proposed before work on ES6 started?
- # [19:44] <Hixie> it was proposed in 2012ish
- # [19:44] <Hixie> but based on e4x which long predates es6
- # [19:45] * Quits: danbri (Adium@nat/google/x-gilinxmbxlhzhajg) (Quit: Leaving.)
- # [19:46] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [19:48] <annevk> jarek: Hixie also proposed Element.create()
- # [19:48] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Read error: Connection reset by peer)
- # [19:48] <annevk> jarek: there's also some push for new HTMLDivElement() and friends
- # [19:49] <jarek> annevk: yeah, that would make a lot of sense since custom elements can be already "newed"
- # [19:49] <annevk> jarek: none have made it far enough so far
- # [19:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
- # [19:51] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
- # [19:51] <terinjokes> what's the browser interest in sendBeacon?
- # [19:51] <jarek> let element = new SVGComponentTransferFunctionElement();
- # [19:52] <jarek> feels very semantic and obvious, but verbose
- # [19:52] * Quits: espadrine_ (~ttyl@LMontsouris-656-1-02-84.w80-12.abo.wanadoo.fr) (Ping timeout: 240 seconds)
- # [19:52] * Joins: Una (~Una@32.97.110.57)
- # [19:53] <Ms2ger> jarek, new HTMLHeadingElement()?
- # [19:54] * Joins: jernoble (~jernoble@17.202.49.229)
- # [19:55] <jarek> Ms2ger: I believe both verbose semantic syntax and shorthand concise E4X-like syntax are needed
- # [19:56] <jarek> depending on context in which elements are created
- # [19:59] <jarek> I would expect abstract interfaces like HTMLHeadingElement to just throw an error when used with "new"
- # [20:04] * Quits: jyasskin (~jyasskin@216.239.45.222) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [20:05] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [20:07] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
- # [20:08] <Domenic> terinjokes: landed in CHrome 39
- # [20:08] <Domenic> terinjokes: I think Mozilla is on track to ship too?
- # [20:10] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
- # [20:10] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
- # [20:15] <wanderview> Domenic: terinjokes: looks like it shipped if FF30: https://bugzilla.mozilla.org/show_bug.cgi?id=936340
- # [20:15] <wanderview> ah, not enabled until FF31
- # [20:17] * Joins: ambv (~ambv@206.108.217.134)
- # [20:19] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
- # [20:19] * Quits: jernoble (~jernoble@17.202.49.229) (Quit: Textual IRC Client: www.textualapp.com)
- # [20:20] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
- # [20:23] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [20:23] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [20:24] * Joins: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net)
- # [20:25] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
- # [20:25] * Quits: Mso150 (~ctlM@80.83.239.11) (Ping timeout: 240 seconds)
- # [20:26] * Joins: Una (~Una@32.97.110.57)
- # [20:27] * Joins: Mso150 (~ctlM@80.83.239.56)
- # [20:28] * Quits: CvP (~CvP@203.76.123.238) (Disconnected by services)
- # [20:28] * Joins: xCG (~CvP@sgp.sin.winterei.se)
- # [20:29] * Joins: jyasskin (~jyasskin@216.239.45.222)
- # [20:29] * Quits: Una (~Una@32.97.110.57) (Client Quit)
- # [20:29] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [20:29] * xCG is now known as CvP
- # [20:30] * Joins: mko (~mko@50.240.205.146)
- # [20:33] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
- # [20:33] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [20:35] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [20:36] * Joins: Una (~Una@32.97.110.57)
- # [20:36] * Joins: ehynds (~ehynds@64.206.121.41)
- # [20:38] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
- # [20:39] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
- # [20:44] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
- # [20:44] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
- # [20:46] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
- # [20:47] <terinjokes> Domenic: Chrome/40 seems non-compliant
- # [20:47] <terinjokes> at least w/r/t Blob
- # [20:57] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # [21:00] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 240 seconds)
- # [21:06] * Joins: eBureau (~Bruno@181.164.77.172)
- # [21:13] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
- # [21:14] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [21:15] * Joins: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a)
- # [21:26] * Quits: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net) (Ping timeout: 255 seconds)
- # [21:26] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
- # [21:26] <zcorpan> jarek: i think changing document.createElement("svg:rect") might not be possible but we could use a space or so instead of colon
- # [21:28] <Hixie> oh hey, a zcorpan
- # [21:28] <zcorpan> sup Hixie
- # [21:28] <Hixie> zcorpan: one sec, loading conversation
- # [21:28] <Hixie> zcorpan: https://html.spec.whatwg.org/#processing-model-9
- # [21:29] <Hixie> zcorpan: note step 8's new steps (work in progress, not yet checked in)
- # [21:29] <Hixie> zcorpan: i'm interested in your input on how you'd like to integrate this into cssom-view
- # [21:29] <Hixie> zcorpan: basically, this provides a specific place for scroll and resize events
- # [21:29] <Hixie> zcorpan: (and many other things)
- # [21:29] <zcorpan> Hixie: multipage is up to date?
- # [21:29] <Hixie> zcorpan: so that we don't have to use tasks for things that are rendering-specific
- # [21:29] <Hixie> yes
- # [21:29] <Hixie> multipage updates with single page now
- # [21:29] <Hixie> same tool outputs both at once
- # [21:32] <zcorpan> Hixie: this looks great
- # [21:33] * Joins: calvaris (~calvaris@158.124.27.77.dynamic.mundo-r.com)
- # [21:33] <Hixie> cool
- # [21:34] <Hixie> zcorpan: let me know if you think anything should change, i'm completely open to doing this however you want
- # [21:35] <zcorpan> Hixie: i guess "Evaluate media queries and report changes" is something that HTML in turn hooks into for <link media>, <source media> etc?
- # [21:36] <zcorpan> Hixie: did you base the order on something or is it arbitrary?
- # [21:36] <Hixie> zcorpan: mostly that was intended for MediaQueryList's events, but I hadn't thought of <link> and <source> etc
- # [21:36] * Quits: roc (~chatzilla@121-99-82-169.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
- # [21:36] <Hixie> zcorpan: it's more or less the superset of the orders that people seemed to give in various e-mails and specs I found
- # [21:37] <Hixie> zcorpan: mostly the order is arbitrary except that: resize is before scroll, animation frame callbacks are the last script thing in the list
- # [21:37] <zcorpan> ok. might be interesting to check what order e.g. Blink uses. i think blink syncs some of these things with rAF these days
- # [21:38] <Hixie> step 6 is rAF
- # [21:38] <Hixie> i spoke to one of the blink guys about this, and to dbaron
- # [21:38] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [21:38] <zcorpan> ok
- # [21:38] <Hixie> i believe it's consistent with what they said
- # [21:38] <Hixie> though mistakes are always possible!
- # [21:42] <zcorpan> Hixie: ok so let me think out loud about how to spec the resize event...
- # [21:42] <Hixie> shoot
- # [21:47] <zcorpan> Run the resize steps are as follows: for each browsing context associated with the given event loop, if it has a viewport and it has had its width or height changed since the last time these steps were run, fire an event named resize at the Window object associated with that viewport.
- # [21:48] <zcorpan> except maybe resize events need to be throttled
- # [21:50] <Hixie> seems reasonable
- # [21:51] <Hixie> no need for throttling; this only happens at 60Hz anyway
- # [21:51] <Hixie> or rather, the throttling is taken care of on my side
- # [21:52] <zcorpan> if we want 60Hz for resize, sure
- # [21:53] <zcorpan> but if there are sites doing expensive things in onresize, might want to throttle more than that
- # [21:53] <zcorpan> i'll have to check what browsers do
- # [21:53] * Krinkle is now known as Krinkle|detached
- # [21:54] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
- # [21:54] <Hixie> well you want it to be possible to resize at 60Hz, otherwise it'll be impossible for a web app to have clean resize behaviour
- # [21:54] <Hixie> but sure
- # [21:55] <Hixie> that's why browsers are allowed to throttle the whole rendering loop further
- # [21:55] <astearns_> "...if it has a viewport and that viewport has had..."
- # [21:55] * Quits: jyasskin (~jyasskin@216.239.45.222) (Quit: My computer has gone to sleep. ZZZzzz…)
- # [21:57] * Joins: newtron (~newtron@199.71.174.203)
- # [22:00] <annevk> zcorpan: happy b-day
- # [22:01] <Hixie> anyone know if https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html is the latest version of that spec?
- # [22:02] <Hixie> http://www.w3.org/TR/hr-time/ is dated later, but presumably if an error was found that's not hte spec that would be updated..
- # [22:02] <Hixie> gah, w3c doc policy grr
- # [22:02] <annevk> I recommend emailing the WG
- # [22:03] * Quits: ehynds (~ehynds@64.206.121.41)
- # [22:03] <zcorpan> annevk: thanks!
- # [22:04] <Hixie> annevk: i've never had any luck mailing that wg
- # [22:04] <zcorpan> Hixie: actually i'd like the "for each browsing context" to be on your side, so that these things get consistent order across browsing contexts
- # [22:04] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Quit: Leaving.)
- # [22:04] <annevk> Hixie: email plh directly?
- # [22:04] <Hixie> zcorpan: fair enough
- # [22:04] <annevk> Web Performance is not particularly great indeed :/
- # [22:05] <zcorpan> Hixie: and maybe say what the order should be (creation order?)
- # [22:05] * Quits: Mso150 (~ctlM@80.83.239.56) (Ping timeout: 250 seconds)
- # [22:05] <Hixie> zcorpan: what do you want to be called for? Documents? browsing contexts? does it differ based on which hook we're talking about?
- # [22:05] <Hixie> for rAF i want to be called for documents
- # [22:06] * Joins: Mso150 (~ctlM@217.118.64.42)
- # [22:07] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [22:08] <zcorpan> Hixie: i think document works for scroll/resize/matchMedia. i can always get the viewport or browsing context from a document if i need it, right?
- # [22:08] <Hixie> yup
- # [22:08] <Hixie> do you want to be called with a list, or called once for each doc? (if you're doing anything per top-level-b-c, you'll have to track which you've done)
- # [22:09] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
- # [22:09] <Hixie> i think for rAF i'm going to have the event loop loop over docs, and the rAF handling be per-doc
- # [22:11] * Joins: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net)
- # [22:11] <zcorpan> per-doc is OK
- # [22:13] * Joins: xiinotulp (~plutoniix@node-1cbm.pool-101-108.dynamic.totbb.net)
- # [22:14] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
- # [22:16] * Joins: danbri (~Adium@87.113.221.2)
- # [22:16] * Quits: plutoniix (~plutoniix@node-3su.pool-125-25.dynamic.totbb.net) (Ping timeout: 264 seconds)
- # [22:18] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Ping timeout: 255 seconds)
- # [22:21] <terinjokes> xhr.send(blob) is supposed to send the contents of the blob, correct?
- # [22:23] <annevk> terinjokes: yes
- # [22:24] <terinjokes> any ideas why I might be doing wrong if instead Chrome/40 serializes/stringifies the blob instance?
- # [22:25] <annevk> terinjokes: Chrome might not support it
- # [22:27] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
- # [22:27] <annevk> terinjokes: we still haven't really clarified what happens if someone closed the blob I think
- # [22:28] <annevk> terinjokes: could be that by not addressing that quickly enough I delayed implementation, I was trying to get answers elsewhere, but no luck thus far, I should probably just decide on something
- # [22:29] * terinjokes smashes head against desk
- # [22:29] <terinjokes> i found the error was between the chair and the keyboard
- # [22:30] * Quits: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net) (Ping timeout: 264 seconds)
- # [22:30] <Domenic> ah phew i was scared
- # [22:30] <terinjokes> i was as well
- # [22:30] <annevk> hmm okay
- # [22:31] <terinjokes> forgot that there was stupid serialization code happening elsewhere
- # [22:31] <annevk> if you find out how the dealt with that case I'd be interested in specifying it :-)
- # [22:31] <annevk> they*
- # [22:31] * Joins: rniwa (~rniwa@17.202.43.222)
- # [22:32] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
- # [22:35] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [22:37] <Hixie> zcorpan: reload html spec for new hooks
- # [22:37] * Joins: ambv (~ambv@206.108.217.134)
- # [22:42] * Joins: laurensclaessen (~laurenscl@2a02:1810:1005:2600:3048:d4:786d:84a9)
- # [22:42] <zcorpan> Hixie: looks good
- # [22:44] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [22:46] * Quits: zdobersek (~zan@185.3.135.138) (Quit: Leaving.)
- # [22:48] * Krinkle|detached is now known as Krinkle
- # [22:52] * Quits: Jirka (~Jirka@95.85.233.233) (Ping timeout: 245 seconds)
- # [22:52] * Joins: Una (~Una@32.97.110.57)
- # [22:53] * Quits: danbri (~Adium@87.113.221.2) (Quit: Leaving.)
- # [22:57] <Hixie> ok rAF is specced in HTML now
- # [22:57] <Hixie> annevk: see the event loop section for stuff you probably want to use for fullscreen
- # [22:58] <annevk> Hixie: oh cool
- # [22:58] <annevk> Hixie++
- # [22:59] * Joins: eric_carlson (~ericc@156.39.191.244)
- # [23:01] * Quits: ambv (~ambv@206.108.217.134) (Read error: Connection reset by peer)
- # [23:01] * Joins: ambv (~ambv@206.108.217.134)
- # [23:03] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
- # [23:05] * heycam|away is now known as heycam
- # [23:05] * Quits: TallTed (~Thud@63.119.36.36)
- # [23:06] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 255 seconds)
- # [23:08] * Joins: Una_ (~Una@32.97.110.57)
- # [23:08] * Quits: Una (~Una@32.97.110.57) (Read error: Connection reset by peer)
- # [23:09] <jamesr_> Hixie: the storage mutex text is all dead code, but you know that
- # [23:09] * Joins: Una (~Una@32.97.110.55)
- # [23:09] <Hixie> jamesr_: one day browsers will realise that data corruption is bad :-P
- # [23:10] <jamesr_> that's a guess on your part :)
- # [23:10] <jamesr_> Hixie: the "update the rendering" step will in practice happen independently of any explicitly queued "task" running
- # [23:10] <gsnedders> it's a nice guess :)
- # [23:11] <Hixie> jamesr_: not sure what you mean by your last comment, can you elaborate?
- # [23:11] * Quits: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [23:11] <jamesr_> i.e. if the only thing on your page is a rAF() loop, it never puts a 'task' into any queue
- # [23:11] <jamesr_> it adds things to the raf list
- # [23:11] <jamesr_> so you basically want to run step 8 of the event loop processing model
- # [23:11] <jamesr_> without having anything in 1
- # [23:12] <jamesr_> Hixie: your spec for requestAnimationFrame() simply adds an entry to the list (which is correct, it doesn't really queue a task) but there's nothing that explicitly says "the browser then has to go and run through the processing model"
- # [23:13] <jamesr_> and i don't see a way to get to step 8 in that algorithm without a task around to run step 3
- # [23:13] * Quits: Una_ (~Una@32.97.110.57) (Ping timeout: 255 seconds)
- # [23:14] <Hixie> jamesr_: oh, right, that's the long-standing issue that step 1 should happen even if it's got no tasks to run
- # [23:14] <Hixie> jamesr_: yeah, i should fix that
- # [23:15] <Hixie> step 6 already admits that no task might be run
- # [23:15] <jamesr_> yeah
- # [23:15] <jamesr_> just need to teach steps 2-4 about that factoid
- # [23:15] <jamesr_> each of the "For each Document in docs" should go in the same order, right?
- # [23:15] <Hixie> yeah
- # [23:16] <Hixie> see the last paragraph of 8.2
- # [23:16] <jamesr_> what happens if you add or remove a new document in one of the step 8 substeps?
- # [23:16] <Hixie> that doc is ignored
- # [23:16] <Hixie> for that rendering loop
- # [23:16] <jamesr_> and if you remove one?
- # [23:16] <jamesr_> i guess it's pretty clearly not run
- # [23:17] <jamesr_> less obvious is what happens if you rejigger the tree such that the invariants in step 8.1 no longer hold for the list you generated
- # [23:17] <Hixie> i guess removing it would still run the steps, hmm
- # [23:17] <Hixie> the order is maintained for all the steps regardless of what you do
- # [23:17] <jamesr_> like the event chain?
- # [23:17] <Hixie> yeah
- # [23:17] <jamesr_> makes sense
- # [23:17] * Quits: Maurice` (copyman@unaffiliated/maurice)
- # [23:18] <Hixie> i didn't add in any of the "hidden" logic from your draft btw
- # [23:18] <Hixie> i suppose i should have that too
- # [23:18] <Hixie> does that handle "the document is removed from the dom"?
- # [23:18] <jamesr_> hmm, not sure if that is covered
- # [23:18] <jamesr_> but it should
- # [23:18] <jamesr_> a document that isn't in the dom isn't visible
- # [23:19] <jamesr_> Hixie: i think it'd be reasonable for a UA to handle "hidden" under the "run these steps if necessary" clause
- # [23:19] <jamesr_> and choose not to run step 8 at all if it decided that the things it cared about were not visible
- # [23:19] <jamesr_> that determination can be tricky sometimes
- # [23:20] <jamesr_> for instance we have a feature in chrome where we can "cast" a tab to a remote screen
- # [23:20] <jamesr_> and that works even if you "background" the tab
- # [23:20] <Hixie> instead of "For each document" i'll say "For each visible document", which will handle removing documents. Need to define "visible" somehow.
- # [23:20] <jamesr_> so if you're looking at the computer screen it appears to be not visible, but it is
- # [23:20] <jamesr_> somewhere else
- # [23:20] <jamesr_> Hixie: that's not what you want actually
- # [23:20] <jamesr_> raf runs in frames that are not "visible" by a reasonable definition if the parent frame is
- # [23:21] <Hixie> s/visible/relevant/
- # [23:21] <jamesr_> the defiintion of "hidden" that the w3c RAF spec used defers to the top-level document or some such
- # [23:21] <jamesr_> i think boris disagrees with me here on the desirable behavior here
- # [23:22] <jamesr_> but there are common cases like "you load all your JS code in a same-origin 0x0 iframe and drive the parent frame from it" where you want the behavior the w3c spec specifies
- # [23:22] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
- # [23:23] * Quits: Mso150 (~ctlM@217.118.64.42) (Ping timeout: 255 seconds)
- # [23:23] <Hixie> how about: a document is "relevant" if it is a fully active document that the user agent believes would benefit from having its rendering updated?
- # [23:26] <jamesr_> i think you do want to specify the set of documents exactly, since at least in the same origin case it's very easy to detect whether things happened in different documents in the same context
- # [23:26] * Joins: roc (~chatzilla@203.192.141.163)
- # [23:27] <zcorpan> Hixie: timers should also be slower in background tabs iirc
- # [23:28] * Joins: saba (~foo@unaffiliated/saba)
- # [23:29] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [23:30] * Hixie tries a different approach
- # [23:33] * Joins: Smylers (~smylers@host86-147-46-136.range86-147.btcentralplus.com)
- # [23:33] <jamesr_> zcorpan: they are. the timer spec allows the UA to add whatever delay they want, which allows the slower in background tabs behavior
- # [23:34] <jamesr_> but i think browsers have roughly stabilized
- # [23:34] <Hixie> jamesr_, zcorpan: ok look now. https://html.spec.whatwg.org/multipage/#processing-model-9
- # [23:35] <jamesr_> hah - why does #processing-model-9 go to step 8.1.4.2?
- # [23:35] <Hixie> cos there's 8 earlier sections titled "processing model" :-)
- # [23:36] <jamesr_> hm, so you null out the docs list as a way to skip the rest of the steps?
- # [23:37] <Hixie> not null out necessarily
- # [23:37] <zcorpan> Hixie: doesn't rAF drop to 0Hz for background tabs? while timers are 1Hz. and i don't know about scroll/resize/etc
- # [23:37] <Hixie> if there's two tabs, and one is to be updated and the other not, then only the background tab's docs get removed
- # [23:37] <Hixie> zcorpan: the spec leaves this open to the browser
- # [23:38] <Hixie> zcorpan: (i hate how chrome doesn't update background tabs, it means that when i switch to a tab, i get the old picture for a frame and then i see the new frame, it's ugly)
- # [23:38] <jamesr_> the timers spec says "take the |timeout| value from script. if you feel like it, add an arbitrary amount to |timeout|"
- # [23:39] <jamesr_> Hixie: that's a slightly different issue
- # [23:39] <jamesr_> you wouldn't want the background tab to be continuously rendering as if it was visible
- # [23:39] <jamesr_> but when you do decide to switch to the tab, there's a choice a browser can make between janking the tab switch until the tab's new contents is ready or showing you whatever it has
- # [23:39] <zcorpan> Hixie: the spec seems to require the same interval for resize/scroll/MQ/fullscreen/rAF
- # [23:40] * Quits: laurensclaessen (~laurenscl@2a02:1810:1005:2600:3048:d4:786d:84a9)
- # [23:40] <Hixie> no, but you might want to update all the tabs once as soon as the user hits command, in case the user then hits tab to switch to the other tabs, or something
- # [23:40] <Hixie> anyway the point is the browser just allows it
- # [23:40] <Hixie> zcorpan: right.
- # [23:40] <Hixie> zcorpan: that's what we want, no?
- # [23:40] <jamesr_> in practice we've been moving to that in blink and been pretty happy
- # [23:41] <jamesr_> Hixie: yeah or start rendering the new tab on the mouse/touch-down even though the switch doesn't happen until the -up
- # [23:41] <jamesr_> Hixie: or start rendering when you over or whatever
- # [23:41] <Hixie> yeah
- # [23:41] <jamesr_> there's a lot we could do predictively
- # [23:41] <zcorpan> Hixie: i don't know. maybe
- # [23:41] <jamesr_> but #lifeishard
- # [23:41] <Hixie> jamesr_: i just want to make sure we don't prevent those. especially since there's no obvious interop need for a particular speed here.
- # [23:42] * Quits: Una (~Una@32.97.110.55) (Read error: Connection reset by peer)
- # [23:42] <Hixie> zcorpan: seems like it's a much better authoring experience if you can rely on all of these happening in order together every time
- # [23:42] * Joins: Una (~Una@32.97.110.55)
- # [23:43] <Hixie> i'm amused at https://www.w3.org/Bugs/Public/show_bug.cgi?id=27347, which says a majority of browsers (browser a, browser b) do one thing and a minority of browsers (browser c, browser d) do another
- # [23:43] <jamesr_> sure
- # [23:43] <jamesr_> heh
- # [23:43] <jamesr_> browser counting
- # [23:43] <jamesr_> hard to do
- # [23:43] <Hixie> i think they meant majority by usage share
- # [23:43] <Hixie> but still, it reads funny
- # [23:44] <Hixie> ok, event loop updates are committed
- # [23:45] <Hixie> i've no idea what https://www.w3.org/Bugs/Public/show_bug.cgi?id=27367 means
- # [23:46] <zcorpan> Hixie: looks like chrome and firefox don't fire resize until the tab is activated again, so that one seems OK
- # [23:46] <Hixie> do they fire anything else?
- # [23:47] <zcorpan> i can try testing the other things tomorrow
- # [23:47] <zcorpan> right now i need to get some sleep :-)
- # [23:48] <Hixie> nn!
- # [23:48] <zcorpan> thanks for fixing this btw
- # [23:48] <Hixie> np
- # [23:49] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 244 seconds)
- # [23:50] <zcorpan> i've sent an email to www-style about this btw for cssom-view and animations
- # [23:52] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 244 seconds)
- # [23:56] * Joins: weinig (~weinig@17.245.26.114)
- # [23:56] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
- # [23:58] * Quits: jdaggett (~jdaggett@ae031063.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
- # [23:59] * Quits: Una (~Una@32.97.110.55) (Quit: My Mac has gone to sleep. ZZZzzz…)
- # Session Close: Thu Nov 20 00:00:00 2014
Previous day, Next day
Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn