/irc-logs / freenode / #whatwg / 2012-05-11 / end

Options:

  1. # Session Start: Fri May 11 00:00:00 2012
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: danielfilho (~daniel@187.31.77.7) (Quit: </html>)
  4. # [00:00] * Joins: ap (~ap@2620:149:4:1b01:fd04:1149:612c:9c40)
  5. # [00:02] <shepazu> paul_irish: it's where you just pointed
  6. # [00:02] <shepazu> :|
  7. # [00:02] <paul_irish> :)
  8. # [00:03] <timeless> ok, i've sent off minutes for webapps
  9. # [00:03] <timeless> i'll try to deal w/ html tomorrow
  10. # [00:03] <timeless> maybe. i have other things to worry about tomorrow
  11. # [00:03] <timeless> they're in www-archive for now
  12. # [00:04] * Quits: izhak (~izhak@188.244.177.185) (Remote host closed the connection)
  13. # [00:04] <timeless> if people ( Velmont, shepazu , odinho , anne, ...) could review them
  14. # [00:04] <timeless> i'd appreciate it
  15. # [00:05] * jonlee is now known as jonlee|afk
  16. # [00:05] * jonlee|afk is now known as jonlee
  17. # [00:06] * Quits: gwicke (~gabriel@212.255.28.33) (Ping timeout: 260 seconds)
  18. # [00:12] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
  19. # [00:13] <Velmont> timeless: Velmont === odinho
  20. # [00:15] <rniwa> timeless: sorry, i was away from keyboard
  21. # [00:15] <rniwa> timeless: did you need me for something?
  22. # [00:19] * Quits: Zauberfisch (Zauberfisc@venus.zauberfisch.at) (Read error: Connection reset by peer)
  23. # [00:20] * Quits: decadance (~decadance@204.93.201.197) (Ping timeout: 260 seconds)
  24. # [00:20] * Joins: decadance (~decadance@204.93.201.197)
  25. # [00:22] * jonlee is now known as jonlee|afk
  26. # [00:23] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
  27. # [00:23] * jonlee|afk is now known as jonlee
  28. # [00:25] * Quits: chriseppstein (~chrisepps@99-6-85-4.lightspeed.sntcca.sbcglobal.net) (Quit: chriseppstein)
  29. # [00:27] * Quits: richardschwerdtf (~RichS@32.97.110.65) (Quit: richardschwerdtf)
  30. # [00:30] * Quits: twisted` (~twisted@p5DDB90AB.dip.t-dialin.net) (Ping timeout: 265 seconds)
  31. # [00:31] * Joins: twisted` (~twisted@p5DDBB4BC.dip.t-dialin.net)
  32. # [00:38] * Quits: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net) (Remote host closed the connection)
  33. # [00:39] * Quits: PalleZingmark (~Adium@c83-250-135-157.bredband.comhem.se) (Quit: Leaving.)
  34. # [00:41] * Joins: Druide__ (~Druid@p5B05D4AD.dip.t-dialin.net)
  35. # [00:42] * Joins: Zauberfisch (Zauberfisc@venus.zauberfisch.at)
  36. # [00:43] * Quits: Druide_ (~Druid@p5B05DC78.dip.t-dialin.net) (Ping timeout: 265 seconds)
  37. # [00:45] * Quits: necolas (~necolas@8.25.195.26) (Remote host closed the connection)
  38. # [00:46] * Joins: cbright6062 (~cbright60@c-76-116-83-148.hsd1.nj.comcast.net)
  39. # [00:46] <cbright6062> sigh. the busyness of work.
  40. # [00:46] * Joins: necolas (~necolas@8.25.195.26)
  41. # [00:47] * Quits: necolas (~necolas@8.25.195.26) (Read error: Connection reset by peer)
  42. # [00:47] * Joins: necolas (~necolas@8.25.195.26)
  43. # [00:51] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  44. # [00:56] * Joins: padenot (~paul@li421-75.members.linode.com)
  45. # [01:05] <smaug____> seriously, linking to dart code for use cases for the web...
  46. # [01:11] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  47. # [01:11] * Quits: tomasf (~tom@c-dedbe555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
  48. # [01:18] * ojan is now known as ojan_away
  49. # [01:19] * Joins: necolas_ (~necolas@8.25.195.26)
  50. # [01:19] * Quits: necolas (~necolas@8.25.195.26) (Read error: Connection reset by peer)
  51. # [01:23] * Joins: nesta_ (~nesta_@77.208.2.38)
  52. # [01:28] <tabatkins> smaug____: Dart is almost JS. Seems legit.
  53. # [01:29] <smaug____> Dart code is like Java
  54. # [01:29] <smaug____> as much webby
  55. # [01:38] * Joins: ap_ (~ap@17.245.107.164)
  56. # [01:39] * Quits: ap_ (~ap@17.245.107.164) (Client Quit)
  57. # [01:40] * Quits: othermaciej (~mjs@17.245.106.253) (Quit: othermaciej)
  58. # [01:40] * Quits: ap (~ap@2620:149:4:1b01:fd04:1149:612c:9c40) (Ping timeout: 245 seconds)
  59. # [01:43] * Joins: othermaciej (~mjs@17.245.106.253)
  60. # [01:44] <arv> smaug____: The Dart library uses the same DOM APIs as JS.
  61. # [01:44] * Joins: seventh (seventh@207.207.28.74)
  62. # [01:45] <smaug____> arv: the API is quite different
  63. # [01:45] <smaug____> and Java uses the same APIs too
  64. # [01:45] <arv> smaug____: it is irrelevant which language someone uses when the underlying capabilities is just DOM4
  65. # [01:45] <arv> smaug____: yes, and java has the same issue regarding context less parsing
  66. # [01:45] <smaug____> actually, there isn't any webidl spec for Dart
  67. # [01:46] <arv> smaug____: so?
  68. # [01:46] <smaug____> and my main point is that it is very un-webby and silly to demonstrate anything on a research language and not using JS
  69. # [01:46] <arv> smaug____: there isn't one for cs eitehr
  70. # [01:46] <smaug____> arv: where is the webidl spec for Dart?
  71. # [01:47] <arv> smaug____: see above. the langiuage is irrelevant
  72. # [01:47] * Quits: necolas_ (~necolas@8.25.195.26) (Remote host closed the connection)
  73. # [01:47] <smaug____> ok. I use Perl next time in my examples :/
  74. # [01:48] <arv> sgtm
  75. # [01:52] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  76. # [01:52] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
  77. # [02:09] * Quits: nessy (~Adium@124-149-96-148.dyn.iinet.net.au) (Quit: Leaving.)
  78. # [02:10] * Joins: nessy (~Adium@124-149-96-148.dyn.iinet.net.au)
  79. # [02:14] * Quits: nessy (~Adium@124-149-96-148.dyn.iinet.net.au) (Client Quit)
  80. # [02:25] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Quit: tantek)
  81. # [02:26] * Quits: pablof (~pablof@144.189.101.1) (Quit: ^z)
  82. # [02:30] * Quits: jsbell (jsbell@nat/google/x-tmaqhmkjjkihorns) (Quit: There's no place like home...)
  83. # [02:35] * Quits: mven (~mven__@169.241.49.57) (Ping timeout: 265 seconds)
  84. # [02:46] * jonlee is now known as jonlee|afk
  85. # [02:49] * Quits: smaug____ (~chatzilla@212-226-73-225-nat.elisa-mobile.fi) (Ping timeout: 252 seconds)
  86. # [02:56] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
  87. # [03:03] * Quits: othermaciej (~mjs@17.245.106.253) (Quit: othermaciej)
  88. # [03:06] * Joins: othermaciej (~mjs@17.245.106.253)
  89. # [03:09] * Quits: tabatkins (~jackalmag@80.187.201.88) (Ping timeout: 240 seconds)
  90. # [03:11] * Joins: KevinMarks (~KevinMark@204.14.239.221)
  91. # [03:13] * Joins: davidb (~davidb@bas1-toronto06-2925210142.dsl.bell.ca)
  92. # [03:14] * Quits: isherman (isherman@nat/google/x-bnbnbrzqhqjyghyh) (Quit: Leaving.)
  93. # [03:16] * Joins: isherman (isherman@nat/google/x-uczcwkmrgewebvbb)
  94. # [03:16] * jernoble is now known as jernoble|afk
  95. # [03:25] * Quits: davidb (~davidb@bas1-toronto06-2925210142.dsl.bell.ca) (Quit: blast off!)
  96. # [03:30] * Quits: othermaciej (~mjs@17.245.106.253) (Quit: othermaciej)
  97. # [03:44] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  98. # [03:49] * Joins: wakaba_ (~wakaba_@203-140-91-62f1.kyt1.eonet.ne.jp)
  99. # [03:53] * Joins: wakaba_0 (~wakaba_@203-140-91-62f1.kyt1.eonet.ne.jp)
  100. # [03:53] * Quits: wakaba_ (~wakaba_@203-140-91-62f1.kyt1.eonet.ne.jp) (Ping timeout: 245 seconds)
  101. # [04:05] * Joins: krit (~krit@dslb-088-071-076-002.pools.arcor-ip.net)
  102. # [04:12] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
  103. # [04:21] * Quits: rniwa (rniwa@nat/google/x-olgyujkrggeabmcd) (Quit: rniwa)
  104. # [04:36] * Joins: JVoracek (~J_Voracek@cpe-70-123-106-75.tx.res.rr.com)
  105. # [04:37] * Quits: kenneth__ (kenneth@nat/nokia/x-mzgurmbmykxvhzpd) (Read error: Connection reset by peer)
  106. # [04:37] * Joins: kenneth__ (kenneth@nat/nokia/x-mtlrcdgdqlndvrge)
  107. # [04:41] * Quits: krit (~krit@dslb-088-071-076-002.pools.arcor-ip.net) (Quit: Leaving.)
  108. # [04:43] * Quits: JVoracek (~J_Voracek@cpe-70-123-106-75.tx.res.rr.com) (Ping timeout: 240 seconds)
  109. # [04:46] * Joins: MikeSmith_ (~MikeSmith@s1106167.xgsspn.imtp.tachikawa.spmode.ne.jp)
  110. # [04:49] * Quits: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp) (Ping timeout: 240 seconds)
  111. # [04:49] * MikeSmith_ is now known as MikeSmith
  112. # [04:50] * Joins: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
  113. # [04:51] * Joins: myakura (~myakura@FL1-221-171-5-98.tky.mesh.ad.jp)
  114. # [04:53] * Quits: jwalden (~waldo@nat/mozilla/x-wcdonnjuxssgsuam) (Ping timeout: 256 seconds)
  115. # [04:53] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  116. # [05:01] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  117. # [05:13] * Quits: nesta_ (~nesta_@77.208.2.38) (Quit: nesta_)
  118. # [05:15] * Joins: nonge (~nonge@p50829430.dip.t-dialin.net)
  119. # [05:20] * Quits: KevinMarks (~KevinMark@204.14.239.221) (Quit: The computer fell asleep)
  120. # [05:20] * Joins: KevinMarks (~KevinMark@204.14.239.221)
  121. # [05:25] * Quits: KevinMarks (~KevinMark@204.14.239.221) (Client Quit)
  122. # [05:25] * Joins: KevinMarks (~KevinMark@204.14.239.221)
  123. # [05:26] * Joins: krit (~krit@dslb-088-071-076-002.pools.arcor-ip.net)
  124. # [05:29] * Quits: KevinMarks (~KevinMark@204.14.239.221) (Read error: Operation timed out)
  125. # [05:35] * Joins: [[zzz]] (~q@125.25.230.147.adsl.dynamic.totbb.net)
  126. # [05:36] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
  127. # [05:38] * Quits: [[zz]] (~q@125.25.55.147.adsl.dynamic.totbb.net) (Ping timeout: 245 seconds)
  128. # [05:41] * [[zzz]] is now known as [[zz]]
  129. # [05:46] * Joins: ehsan (~ehsan@209.20.29.228)
  130. # [05:53] * Joins: benvie (~brandon@cpe-174-097-187-248.nc.res.rr.com)
  131. # [06:01] * Quits: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Quit: disconnected: Jace Voracek - Jace@Jace-Place.com)
  132. # [06:22] * Joins: tantek (~tantek@173-228-80-252.dsl.static.sonic.net)
  133. # [06:25] * blahblah123 is now known as niftylettuce
  134. # [06:38] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
  135. # [06:49] * Joins: LBP (~Mirc@pD9EB1A88.dip0.t-ipconnect.de)
  136. # [06:49] * Quits: gavinc (~gavin@barad-dur.carothers.name) (Quit: Konversation terminated!)
  137. # [06:53] * Joins: niloy (~niloy@61.12.96.242)
  138. # [07:02] * Joins: vanson2012 (~vanson201@061093228142.ctinets.com)
  139. # [07:05] * Joins: skylamer` (cgskylamer@78.90.213.55)
  140. # [07:10] * Quits: myakura (~myakura@FL1-221-171-5-98.tky.mesh.ad.jp) (Remote host closed the connection)
  141. # [07:11] * Quits: tantek (~tantek@173-228-80-252.dsl.static.sonic.net) (Quit: tantek)
  142. # [07:16] * Quits: jahman (~woops@129.175.204.73) (Ping timeout: 252 seconds)
  143. # [07:16] * Quits: kinetik (~kinetik@121.98.132.55) (Ping timeout: 252 seconds)
  144. # [07:17] * Quits: Jedi_ (~Jedi@jedi.org) (Remote host closed the connection)
  145. # [07:17] * Joins: Jedi_ (~Jedi@jedi.org)
  146. # [07:17] * Joins: kinetik (~kinetik@121.98.132.55)
  147. # [07:21] * Joins: Areks (~Areks@rs.gridnine.com)
  148. # [07:27] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  149. # [07:28] * Joins: jahman (~woops@129.175.204.73)
  150. # [07:30] * Quits: Taggnostr (~quassel@dyn57-365.yok.fi) (Remote host closed the connection)
  151. # [07:35] * Quits: cpearce (~cpearce@60.234.54.74) (Ping timeout: 265 seconds)
  152. # [07:36] * Quits: krit (~krit@dslb-088-071-076-002.pools.arcor-ip.net) (Quit: Leaving.)
  153. # [07:36] * Joins: myakura (~myakura@FL1-221-171-5-98.tky.mesh.ad.jp)
  154. # [07:36] * Joins: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com)
  155. # [07:36] * Joins: ehsan_ (~ehsan@209.20.29.228)
  156. # [07:37] * Joins: myndzi (myndzi@c-67-168-184-168.hsd1.wa.comcast.net)
  157. # [07:39] * Quits: ehsan (~ehsan@209.20.29.228) (Read error: Connection reset by peer)
  158. # [07:40] * Joins: Taggnostr (~quassel@dyn57-365.yok.fi)
  159. # [07:40] * Quits: myndzi\ (myndzi@c-67-168-184-168.hsd1.wa.comcast.net) (Ping timeout: 252 seconds)
  160. # [07:45] * Joins: alystair (~alystair@108.162.155.35)
  161. # [07:59] * Joins: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se)
  162. # [08:01] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
  163. # [08:01] * Joins: tantek (~tantek@66-87-4-208.pools.spcsdns.net)
  164. # [08:09] * Joins: cpearce (~cpearce@ip-118-90-120-55.xdsl.xnet.co.nz)
  165. # [08:17] <AryehGregor> <eighty4> anyone happen to know if you can redefine how contenteditable inserts <br>s and <div>s and so on? <-- What behavior do you want?
  166. # [08:18] * Quits: tantek (~tantek@66-87-4-208.pools.spcsdns.net) (Quit: tantek)
  167. # [08:20] * Joins: tantek (~tantek@66-87-4-208.pools.spcsdns.net)
  168. # [08:20] * Quits: tantek (~tantek@66-87-4-208.pools.spcsdns.net) (Client Quit)
  169. # [08:21] * Quits: macpherson (~macpherso@2401:fa00::ea06:88ff:fecc:9412) (Quit: macpherson)
  170. # [08:24] * Joins: tabatkins (~jackalmag@80.187.201.88)
  171. # [08:26] <AryehGregor> eighty4, currently IE/Opera wrap everything in <p> on Enter, Firefox inserts <br>, WebKit uses <div> for line breaks but very recently added support to opt in to <p> instead (defaultparagraphseparator command). I'm currently working on a patch for Gecko to more closely match IE/Opera behavior, which is what the editing spec requires.
  172. # [08:26] * Joins: nesta_ (~nesta_@70.Red-83-58-95.dynamicIP.rima-tde.net)
  173. # [08:26] <AryehGregor> So once that patch lands, the most recent version of everything will do <p> (at least if you opt in with defaultparagraphseparator, for WebKit).
  174. # [08:27] <AryehGregor> Although the exact places they create the separator will still vary -- e.g., "foo\nbar" in an empty editable div should create "<p>foo</p><p>bar</p>" per spec, but in WebKit probably produces "foo<p>bar</p>", browsers might leave useless trailing <br>'s, etc.
  175. # [08:27] <AryehGregor> Any questions? :)
  176. # [08:28] <AryehGregor> (there are a lot more details here, FWIW, I'm just talking about the most basic case; what happens if you hit Enter in an <li>, <h#>, etc. is a different story)
  177. # [08:38] * Joins: ehsan (~ehsan@209.20.29.228)
  178. # [08:39] * Quits: ehsan_ (~ehsan@209.20.29.228) (Read error: No route to host)
  179. # [08:44] * Quits: isherman (isherman@nat/google/x-uczcwkmrgewebvbb) (Ping timeout: 264 seconds)
  180. # [08:44] * Joins: isherman (isherman@nat/google/x-zpjcugxevsyrmdnk)
  181. # [08:50] * Quits: ehsan (~ehsan@209.20.29.228) (Ping timeout: 240 seconds)
  182. # [09:01] * Quits: nesta_ (~nesta_@70.Red-83-58-95.dynamicIP.rima-tde.net) (Remote host closed the connection)
  183. # [09:01] * Joins: nesta_ (~nesta_@149.Red-81-44-192.dynamicIP.rima-tde.net)
  184. # [09:05] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  185. # [09:07] * Joins: dbaron (~dbaron@193.105.139.140)
  186. # [09:07] * Quits: JohnAlbin (~JohnAlbin@114-42-62-166.dynamic.hinet.net) (Quit: HTTP/1.1 404 JohnAlbin Not Found)
  187. # [09:08] * Joins: krit (~krit@sjfw1-a.adobe.com)
  188. # [09:11] * Joins: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net)
  189. # [09:16] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  190. # [09:17] * Joins: Kolombiken (~Adium@217.13.228.226)
  191. # [09:17] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
  192. # [09:36] * Joins: jdaggett (~jdaggett@193.105.139.140)
  193. # [09:42] <jgraham> zcorpan: Compile errors don't have a stack either
  194. # [09:45] <zcorpan> jgraham: indeed
  195. # [09:45] <zcorpan> jgraham: but they have a column number
  196. # [09:45] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Quit: hij1nx)
  197. # [09:47] * Quits: ben_alman (~cowboy@awesome.benalman.com) (Excess Flood)
  198. # [09:48] <jgraham> Weren't you proposing passing in both?
  199. # [09:49] * Joins: ben_alman (~cowboy@awesome.benalman.com)
  200. # [09:50] <zcorpan> yes. but he suggested dropping column and replacing it with Error
  201. # [09:50] <zcorpan> and putting column on Error
  202. # [09:50] * hober catches up on the backlog
  203. # [09:51] <hober> not being in pacific time can be inconvenient
  204. # [09:52] <jgraham> zcorpan: That doesn't sound very compatible
  205. # [09:53] <zcorpan> jgraham: column is a new thing, though
  206. # [09:53] <jgraham> hober: You are living in the silicon valley bubble :p
  207. # [09:53] <hober> :)
  208. # [09:54] <jgraham> zcorpan: No one supports it?
  209. # [09:54] <zcorpan> right
  210. # [09:54] <jgraham> I see
  211. # [09:54] <zcorpan> maybe ie10, dunno
  212. # [09:54] * Joins: pyrsmk (~pyrsmk@84.6.46.4)
  213. # [09:54] <zcorpan> ms proposed it
  214. # [09:55] <jgraham> Well I think passing in the error object somewhere (when it exists) is a good idea
  215. # [09:55] <hober> Wilto othermaciej tantek et al.: sorry I missed your discussion last night.
  216. # [09:55] <hober> i'll write up my thoughts on <picture> and why i prefer <img srcset> for the Retina/non-Retina use case soon, but i'm at the css f2f and don't have the time for it right now
  217. # [09:56] <hober> [i had the time to "write up" <img srcset> because i had already written the email, just hadn't sent it. :)]
  218. # [09:57] <hober> Wilto: I was aware of the CG and the various conversations online that preceded it (on ALA, the etherpad, the june 2007 thread on public-html, etc.)
  219. # [09:57] <zcorpan> i prefer an attribute because it makes the processing much simpler. <source> is hard
  220. # [09:57] * Joins: yarco (~yarco_wan@115.215.98.122)
  221. # [09:58] <gsnedders> zcorpan: Is there any reason why we can't just pass in the exception value?
  222. # [09:58] <hober> Wilto: and reviewing all of that most definitely influenced the design of my proposal
  223. # [09:58] <gsnedders> I mean, we can always create SyntaxError objects aside from the eval case
  224. # [09:58] <zcorpan> gsnedders: no reason, i'm just trying to figure out what information he wants
  225. # [09:58] <hober> Wilto: <img srcset> isn't a panacea; it's intended to solve some of the problems identified under the umbrella term "responsive images"
  226. # [09:58] <zcorpan> gsnedders: oh you mean for compile errors?
  227. # [09:59] <zcorpan> gsnedders: yeah we could create an exception object for that case
  228. # [09:59] <gsnedders> zcorpan: Nah, I mean in general, and suggesting how we handle the compile-error case
  229. # [09:59] <hober> zcorpan: indeed
  230. # [10:01] <hober> Wilto: anyway, i'm sorry if you interpreted my email as ignoring the hard work that the cg has done
  231. # [10:03] * Joins: smaug____ (~chatzilla@212-226-73-225-nat.elisa-mobile.fi)
  232. # [10:03] <hober> Wilto: what happened was quite the opposite; i went over many of the discussions (both in the cg, on the whatwg and html wg mailing lists, and in the wider community prior to the cg's formation) while working on the problem
  233. # [10:05] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
  234. # [10:10] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 260 seconds)
  235. # [10:15] * Joins: cheron (~cheron@unaffiliated/cheron)
  236. # [10:15] * Joins: gwicke (~gabriel@212.255.28.33)
  237. # [10:15] * Joins: drdt (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net)
  238. # [10:22] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  239. # [10:22] * Joins: karlcow (~karl@nerval.la-grange.net)
  240. # [10:27] * Quits: tabatkins (~jackalmag@80.187.201.88) (Ping timeout: 265 seconds)
  241. # [10:32] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  242. # [10:45] * Joins: tabatkins (~jackalmag@193.105.139.140)
  243. # [10:46] * Quits: Lachy (~Lachy@cm-84.215.193.30.getinternet.no) (Quit: Computer has gone to sleep.)
  244. # [10:46] * Joins: Ms2ger (~Ms2ger@91.181.124.114)
  245. # [10:48] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
  246. # [10:50] <smaug____> hmm, whether or not un-prefix MutationObserver now
  247. # [10:50] <smaug____> perhaps I should test the implementations some more
  248. # [10:50] <annevk> if you unprefix it now and there's edge case bugs you should still have time to fix them
  249. # [10:50] <smaug____> or anyone else willing to test the implementations? ;)
  250. # [10:51] <smaug____> annevk: true
  251. # [10:51] * Joins: broquain1 (~dbrook@static.94.217.47.78.clients.your-server.de)
  252. # [10:51] * Quits: broquain1 (~dbrook@static.94.217.47.78.clients.your-server.de) (Client Quit)
  253. # [10:51] <annevk> it's more about whether you trust the general design enough I guess
  254. # [10:51] <zcorpan> UNPREFIX ALL THE THINGS!
  255. # [10:51] <annevk> but given that there's now blog posts advocating people to use it, I'd prefer we just went with it
  256. # [10:51] <smaug____> it is perfect design. design by me (and others) ;)
  257. # [10:51] <Ms2ger> Hah
  258. # [10:52] <Ms2ger> It's in a spec, surely it isn't perfect
  259. # [10:52] * Quits: broquaint (~dbrook@78.47.79.137) (Quit: leaving)
  260. # [10:52] <smaug____> that is true. should we take it out from the spec :)
  261. # [10:52] * Joins: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de)
  262. # [10:52] <jgraham> Didn't the link to "spec" in the blogpost go to an email?
  263. # [10:53] <annevk> yeah so no problems there
  264. # [10:53] <smaug____> jgraham: in mozilla hacks=
  265. # [10:53] <smaug____> s/=/?/
  266. # [10:53] <annevk> yup
  267. # [10:53] <smaug____> jgraham: I posted a comment about that
  268. # [10:53] <smaug____> with the right link
  269. # [10:53] <jgraham> Oh, I saw it on planet mozilla, so no comments
  270. # [10:54] <smaug____> I just posted my comment
  271. # [10:54] <smaug____> annevk: jgraham: but in general Opera doesn't see anything hugely wrong with the API ?
  272. # [10:54] * smaug____ should ask MS
  273. # [10:55] <Ms2ger> Land it
  274. # [10:55] <Ms2ger> Oh, other MS
  275. # [10:57] * Quits: drdt (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net) (Quit: drdt)
  276. # [10:58] <jgraham> smaug____: I haven't studied it in detail. I thought annevk was following it more closely. But I asked some of our developers and I think their opinion was roughly "it can't be worse than mutation events" mixed with a little "we are probably stuck with mutation events, so is having an extra API here a good idea"
  277. # [10:58] <jgraham> +?
  278. # [10:59] <annevk> yeah
  279. # [10:59] <annevk> though also combined with if we can get rid of mutation events that'd be really awesome...
  280. # [11:00] <smaug____> jgraham: well, we at least should try to get rid of mutation events
  281. # [11:00] <annevk> I'd hate having to define them in DOM
  282. # [11:00] <smaug____> MutationObserver is 5-10 faster than MutationEvents (both in Gecko and Webkit), and it is 'safe'
  283. # [11:01] <jgraham> Well sure, if we can kill mutation events there will be rejoicing in the streets of Oslo
  284. # [11:01] <smaug____> I would assume mutation events have caused crashes also in Opera
  285. # [11:01] <smaug____> :)
  286. # [11:01] <jgraham> (or Linköping, but everyone thinks Opera == Oslo)
  287. # [11:01] <smaug____> (Hmm, have I been in Linköping)
  288. # [11:02] <smaug____> (probably just passed by)
  289. # [11:03] * Joins: graememcc (~chatzilla@host86-150-90-27.range86-150.btcentralplus.com)
  290. # [11:04] * Joins: Lachy (~Lachy@guest.opera.com)
  291. # [11:05] * Joins: niloy (~niloy@61.12.96.242)
  292. # [11:07] <gsnedders> (Probably just passed by, it's not like anything ever happens here.)
  293. # [11:10] <smaug____> (I've been often in places where nothing really happens. Silicon Valley is one such place.)
  294. # [11:11] <jgraham> gsnedders: You were talking just last night about Judas Priest playing here!
  295. # [11:11] <jgraham> If you want to see 60 year old men in bondage gear, this is the town for you!
  296. # [11:12] <gsnedders> Well, by Lkpg's scale, that's an unprecidented event.
  297. # [11:12] <gsnedders> I never said in more ordinary terms it was notable.
  298. # [11:12] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 252 seconds)
  299. # [11:13] * Joins: espadrine (~thaddee_t@AMontsouris-157-1-90-43.w90-46.abo.wanadoo.fr)
  300. # [11:20] * Joins: GPHemsley (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net)
  301. # [11:20] * Quits: GPHemsley (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net) (Changing host)
  302. # [11:20] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  303. # [11:28] * Quits: wakaba_0 (~wakaba_@203-140-91-62f1.kyt1.eonet.ne.jp) (Quit: Leaving...)
  304. # [11:35] * Joins: graememcc_ (~chatzilla@host86-148-141-179.range86-148.btcentralplus.com)
  305. # [11:37] * Quits: graememcc (~chatzilla@host86-150-90-27.range86-150.btcentralplus.com) (Ping timeout: 272 seconds)
  306. # [11:37] * graememcc_ is now known as graememcc
  307. # [11:41] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
  308. # [11:45] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  309. # [11:47] * Quits: nonge (~nonge@p50829430.dip.t-dialin.net) (Read error: Operation timed out)
  310. # [11:48] * Quits: smaug____ (~chatzilla@212-226-73-225-nat.elisa-mobile.fi) (Ping timeout: 244 seconds)
  311. # [11:49] * Quits: Moo^ (~quassel@herd37.twinapex.fi) (Remote host closed the connection)
  312. # [11:53] <Ms2ger> "we are close to closing the XSL WG. The XSL FO WG is going to be closed in the next 6 months."
  313. # [11:53] <Ms2ger> Hear, hear
  314. # [11:57] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  315. # [11:58] * Joins: jarib (~jarib@unaffiliated/jarib)
  316. # [11:58] <jgraham> UPDATE W3C.groups SET status='inactive' WHERE name LIKE 'X%';
  317. # [11:59] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 255 seconds)
  318. # [12:02] * Joins: nonge (~nonge@91.50.103.22)
  319. # [12:14] * Joins: drublic (~drublic@frbg-5f732145.pool.mediaWays.net)
  320. # [12:17] <charlvn> lol jgraham
  321. # [12:20] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  322. # [12:22] * Quits: LBP (~Mirc@pD9EB1A88.dip0.t-ipconnect.de) (Quit: Bye, bye! See you on http://leanbackplayer.com)
  323. # [12:24] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  324. # [12:30] * Joins: karlcow (~karl@nerval.la-grange.net)
  325. # [12:31] * Quits: cpearce (~cpearce@ip-118-90-120-55.xdsl.xnet.co.nz) (Ping timeout: 248 seconds)
  326. # [12:31] * Joins: temp02 (~temp01@unaffiliated/temp01)
  327. # [12:32] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 252 seconds)
  328. # [12:38] * Joins: Obvious (tachikoma@188.226.74.2)
  329. # [12:38] * Quits: Obvious_MkII (tachikoma@188.226.74.2) (Ping timeout: 250 seconds)
  330. # [12:42] * Quits: richt (richt@nat/opera/x-seobmhpsznedeyvw) (Read error: Connection reset by peer)
  331. # [12:42] <zcorpan> tabatkins: hsivonen's proposal makes <set> and <image> svg elements
  332. # [12:42] * Joins: richt (richt@nat/opera/x-cddvplkbghseomcj)
  333. # [12:44] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 245 seconds)
  334. # [12:45] * Quits: jondong (~jondong@123.126.22.58) (Remote host closed the connection)
  335. # [12:45] * Quits: temp02 (~temp01@unaffiliated/temp01) (Read error: Connection reset by peer)
  336. # [12:47] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  337. # [12:50] * Joins: temp01 (~temp01@unaffiliated/temp01)
  338. # [12:54] * Quits: drublic (~drublic@frbg-5f732145.pool.mediaWays.net) (Remote host closed the connection)
  339. # [13:14] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  340. # [13:22] * Quits: seventh (seventh@207.207.28.74) (Remote host closed the connection)
  341. # [13:26] * Quits: nesta_ (~nesta_@149.Red-81-44-192.dynamicIP.rima-tde.net) (Quit: nesta_)
  342. # [13:29] <tabatkins> zcorpan: Yeah, misread. Sorry, hsivonen!
  343. # [13:30] * Joins: jdaggett_ (~jdaggett@193.105.139.140)
  344. # [13:30] * Quits: jdaggett (~jdaggett@193.105.139.140) (Read error: Connection reset by peer)
  345. # [13:30] * jdaggett_ is now known as jdaggett
  346. # [13:32] * Quits: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de) (Quit: leaving)
  347. # [13:32] * Quits: jdaggett (~jdaggett@193.105.139.140) (Read error: Connection reset by peer)
  348. # [13:32] * Joins: jdaggett (~jdaggett@193.105.139.140)
  349. # [13:32] * Joins: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de)
  350. # [13:34] * Quits: yarco (~yarco_wan@115.215.98.122) (Quit: Leaving.)
  351. # [13:36] * Joins: jdong_bot_ (~jdong_bot@117.79.232.159)
  352. # [13:40] <benvie> seeing all the svg property interfaces blink into existence 5-10 at a time when setting one property due to mutation observers and svg's late init is pretty funny
  353. # [13:42] * Joins: moo-_- (miohtama@lakka.kapsi.fi)
  354. # [13:44] * Joins: nesta_ (~nesta_@70.Red-83-58-95.dynamicIP.rima-tde.net)
  355. # [13:45] * Joins: PalleZingmark (~Adium@c83-250-135-157.bredband.comhem.se)
  356. # [13:46] * Quits: jochen__ (jochen@nat/google/x-uvqahbvzyjugmoyy) (Remote host closed the connection)
  357. # [13:47] * Joins: jochen__ (jochen@nat/google/x-ftsducsopxoefxom)
  358. # [13:51] * Joins: jarek (~jarek@aean56.neoplus.adsl.tpnet.pl)
  359. # [13:51] * Quits: jarek (~jarek@aean56.neoplus.adsl.tpnet.pl) (Changing host)
  360. # [13:51] * Joins: jarek (~jarek@unaffiliated/jarek)
  361. # [13:52] <tabatkins> SVG has late init?
  362. # [14:00] * Joins: niloy (~niloy@61.12.96.242)
  363. # [14:04] * Joins: yarco (~yarco_wan@115.215.98.122)
  364. # [14:10] * Quits: nesta_ (~nesta_@70.Red-83-58-95.dynamicIP.rima-tde.net) (Quit: nesta_)
  365. # [14:13] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
  366. # [14:20] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  367. # [14:21] * Joins: nesta_ (~nesta_@149.Red-81-44-192.dynamicIP.rima-tde.net)
  368. # [14:25] * toyoshim is now known as toyoshiAw
  369. # [14:43] <jarek> btw, would it be suitable to use mutation observers for implementation of undo manager in SVG editor?
  370. # [14:44] <jarek> I have noticed that SVG-edit is registering undo operations manually which is a bit complicated
  371. # [14:49] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 245 seconds)
  372. # [14:49] <zcorpan> hey everyone! check out the new DOM Parsing spec at http://www.w3.org/TBD
  373. # [14:49] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  374. # [14:50] * Joins: nessy (~Adium@124-149-96-148.dyn.iinet.net.au)
  375. # [14:59] * Quits: Lachy (~Lachy@guest.opera.com) (Quit: Textual IRC Client: http://www.textualapp.com/)
  376. # [15:00] * Joins: Lachy (Lachy@nat/opera/x-ijdbwespaxeyvejp)
  377. # [15:02] * Quits: Lachy (Lachy@nat/opera/x-ijdbwespaxeyvejp) (Client Quit)
  378. # [15:02] * Joins: Lachy (Lachy@nat/opera/x-mmifznbsuxajqzlk)
  379. # [15:06] * Joins: snowfox (~benschaaf@50-77-199-197-static.hfc.comcastbusiness.net)
  380. # [15:12] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
  381. # [15:13] * Quits: nessy (~Adium@124-149-96-148.dyn.iinet.net.au) (Quit: Leaving.)
  382. # [15:13] * Quits: Lachy (Lachy@nat/opera/x-mmifznbsuxajqzlk) (Read error: Connection reset by peer)
  383. # [15:13] * Quits: nesta_ (~nesta_@149.Red-81-44-192.dynamicIP.rima-tde.net) (Quit: nesta_)
  384. # [15:14] * Joins: Lachy (Lachy@nat/opera/x-hespsssvoeovustv)
  385. # [15:19] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
  386. # [15:19] <kennyluck> Hmm.. I don't get that joke.
  387. # [15:20] * Joins: danja (~danny@host94-204-dynamic.13-79-r.retail.telecomitalia.it)
  388. # [15:21] * Joins: davidb (~davidb@66.207.208.98)
  389. # [15:22] <hober> kennyluck: it's no joke
  390. # [15:22] <hober> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204
  391. # [15:24] * Quits: yarco (~yarco_wan@115.215.98.122) (Quit: Leaving.)
  392. # [15:25] <jgraham> hober: Well it is. Just the other kind of joke
  393. # [15:25] <hober> jgraham: indeed.
  394. # [15:26] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Quit: Verlassend)
  395. # [15:26] <zcorpan> jgraham: what's the idea with setup()? what's supposed to happen when it fails?
  396. # [15:27] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  397. # [15:27] <jgraham> zcorpan: In theory the idea is that you put any pre-test setup in that function and testharness.js will report to a higher layer if it fails
  398. # [15:28] * Quits: yutak (~yutak@74.125.56.33) (Quit: Ex-Chat)
  399. # [15:28] * Joins: MacTed (~Thud@63.119.36.36)
  400. # [15:32] <zcorpan> yeah, that's what i thought. it just doesn't seem to work
  401. # [15:33] <zcorpan> my tests still time out even if setup throws
  402. # [15:33] <jgraham> Oh. Well it might be broken in some way I guess
  403. # [15:36] <kennyluck> lol
  404. # [15:39] <jgraham> zcorpan: If you put the test somewhere I can see it I will look
  405. # [15:42] * Joins: ehsan (~ehsan@209.20.29.228)
  406. # [15:48] * Joins: graememcc_ (~chatzilla@host86-162-163-170.range86-162.btcentralplus.com)
  407. # [15:49] * Quits: graememcc (~chatzilla@host86-148-141-179.range86-148.btcentralplus.com) (Ping timeout: 245 seconds)
  408. # [15:49] * graememcc_ is now known as graememcc
  409. # [15:53] * Joins: sarro (~sarro@i5E864E59.versanet.de)
  410. # [15:54] * Joins: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se)
  411. # [15:55] * Joins: erichynds (~ehynds@64.206.121.41)
  412. # [16:00] * Joins: MikeSmith_ (~MikeSmith@s1106167.xgsspn.imtp.tachikawa.spmode.ne.jp)
  413. # [16:00] * Quits: MikeSmith (~MikeSmith@s1106167.xgsspn.imtp.tachikawa.spmode.ne.jp) (Read error: Connection reset by peer)
  414. # [16:00] * MikeSmith_ is now known as MikeSmith
  415. # [16:03] * Quits: Druide__ (~Druid@p5B05D4AD.dip.t-dialin.net)
  416. # [16:04] * Joins: Druide_ (~Druid@p5B05D4AD.dip.t-dialin.net)
  417. # [16:05] <Wilto> hober: So you’re saying that imgset does not preclude <picture>.
  418. # [16:05] <Wilto> Despite there being some overlap in the concerns they address?
  419. # [16:09] <Wilto> …No, actually, these address the same concerns.
  420. # [16:10] <Wilto> In different ways, but the same core issues. Just, one uses a syntax arrived upon through the consensus of the Community Group, countless blog posts, comments—hell, _tweets_—and one was arrived at after a cursory glance at the CG.
  421. # [16:11] * Quits: sarro (~sarro@i5E864E59.versanet.de) (Read error: Connection reset by peer)
  422. # [16:11] <Wilto> I’m not some especially irritating kid with an opinion here, guys.
  423. # [16:11] <Wilto> I’m representing the developers’ consensus.
  424. # [16:11] * Joins: sarro (~sarro@i5E864E59.versanet.de)
  425. # [16:12] <Wilto> So when you say “this syntax is better for authors,” here, in a vacuum, I am here to inform you that we considered something just like this already and nobody liked it.
  426. # [16:12] <hober> I think "a cursory glance" is an unfair characterization of the work that went in here.
  427. # [16:12] <Wilto> Take it or leave it, sure, but don’t pretend the developer consensus is the reasoning behind this proposed syntax when _getting that consensus has been my job_.
  428. # [16:12] <jgraham> Wilto: You would be much more convincing with citations
  429. # [16:13] <jgraham> Specifically to citations to problems with the syntax
  430. # [16:13] <jgraham> Rather than making an argument from authority
  431. # [16:13] * Joins: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com)
  432. # [16:14] <Wilto> Sure. Happy to collect those for you.
  433. # [16:15] <hober> I don't understand what you think I'm pretending.
  434. # [16:15] * Quits: PalleZingmark (~Adium@c83-250-135-157.bredband.comhem.se) (Quit: Leaving.)
  435. # [16:15] <Wilto> You can understand where I’m irritated, when the CH was posed as a place to give developers a voice in the creation and adoption of standards, and the _good news_ is that people had a look at it before starting to make decisions.
  436. # [16:15] <hober> (i'm not being intentionally obtuse, btw, i really didn't understand that last line)
  437. # [16:16] <hober> I certainly understand your irritation.
  438. # [16:16] * Joins: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
  439. # [16:16] <hober> That said, how some people described a community group isn't something I have any control over
  440. # [16:16] * Parts: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
  441. # [16:16] <Wilto> No, of course not.
  442. # [16:17] <Wilto> But like… you saw the number of folks involved in the discussion in the CG, the ALA article, the .net article, likely some of the chatter on Twitter, etc. etc.
  443. # [16:17] <Wilto> Even if the others missed it somehow, man, you’ve seen that this is a big deal.
  444. # [16:17] <Wilto> And no small amount of work has been done.
  445. # [16:18] <hober> is anyone saying that that work hasn't been done?
  446. # [16:18] <Wilto> Hell, not even asking me to get involved—someone could have mentioned that these discussions were kicking off in IRC.
  447. # [16:18] <Wilto> No, not at all.
  448. # [16:18] <Wilto> I’m saying that despite all that, the discussion kicked off in a vacuum.
  449. # [16:19] <hober> (sorry if i'm coming across as short, btw; it's day 3 of the css wg and it's getting kinda punchy in here. good thing the room is padded.)
  450. # [16:19] <Wilto> You’re not working with developers on this. You’re “considering” us.
  451. # [16:19] <Wilto> We planned on working with the WHATWG.
  452. # [16:19] <hober> aren't we working together right now?
  453. # [16:19] <hober> i don't understand "the discussion kicked off in a vacuum"
  454. # [16:20] <Wilto> Hixie already “proposed a solution.”
  455. # [16:20] <hober> there have been many threads on whatwg@ (and elsewhere, obv.) about this
  456. # [16:20] <Wilto> Which is fine, don’t misunderstand.
  457. # [16:20] <hober> yeah, and when he described it i recalled that i had a pending draft email about that, so i dug it up and hit send
  458. # [16:21] <hober> i'm not at the machine that i usually use for email, so it didn't get property threaded as a reply on one of the existing threads
  459. # [16:21] <Wilto> But that’s where I get irritated. So he just whipped that up, and I’m guessing from the responses in general that he had no idea the CG existed, and hasn’t paid much attention to the internet at large talking about respimg.
  460. # [16:22] <Wilto> But that syntax is “better for authors?” What I’m getting at is I’ve, y’know, _asked_ the developers.
  461. # [16:22] <hober> i don't see how you can assert that he "just whipped that up"
  462. # [16:22] <jgraham> Wilto: I don't think getting irritated is going to help you at all
  463. # [16:22] <jgraham> If you have concrete objections to that syntax
  464. # [16:22] <jgraham> make them
  465. # [16:22] <hober> i don't know how much time he spent on it, so i avoid aserting that he spent a lot of time or not much time
  466. # [16:22] <jgraham> Cite the developers
  467. # [16:22] <Wilto> jgraham: Yeah, guess I’m spinning my wheels here.
  468. # [16:23] <Wilto> jgraham: Before I do, are there any citations that Hixie’s proposal is preferred by developers?
  469. # [16:24] <zcorpan> an attribute would be better for *implementors* (because it makes the processing orders of magnitude simpler (which in turn means fewer bugs))
  470. # [16:24] <Wilto> zcorpan: Citations?
  471. # [16:24] <Wilto> zcorpan: By which I mean, has this been discussed with implementers?
  472. # [16:25] <jgraham> Wilto: zcorpan is an implementor
  473. # [16:25] <zcorpan> Wilto: i've QA'd <video><source> for opera, i know it is orders of magniture more complex than an attribute would be
  474. # [16:26] <jgraham> (it's rather easy to understand why; if you have multiple elements, you can get things like <script> in the middle that add or remove things in real time, whereas attributes can be processed atomically)
  475. # [16:26] <Wilto> Cool. The order of operations for benefit is “users -> developers -> implementors” though, yeah?
  476. # [16:26] <jgraham> Yes
  477. # [16:26] <Wilto> I’m not dismissing what you’re saying, mind. Again, I’ve been working with browser devs right along, and this is important stuff.
  478. # [16:26] <kennyluck> Wilto, I would strongly suggest you write an email to whatwg@whatwg.org, even just a mail with a pointer to the discussion on CG. No body can read every mail on every mailing list.
  479. # [16:26] <zcorpan> yes. but if the implementors get riddled with bugs, that's not useful for developers either
  480. # [16:27] <jgraham> If you can prove that multiple elements addresses use cases better than a single attribute, that makes a difference
  481. # [16:27] * Quits: twisted` (~twisted@p5DDBB4BC.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
  482. # [16:27] <Wilto> Has this been discussed with reps from any other UAs?
  483. # [16:27] <jgraham> But yeah, all things being equal, avoiding interoperability problems before they have the chance to occur is a win for everyone
  484. # [16:28] <Wilto> Opera doesn’t do anything—or have anything planned—in the way of image prefetching, correct?
  485. # [16:28] <hober> Wilto: when you say "browser devs", do you mean implementors? dev rel? other browser-affiliate people?
  486. # [16:28] <Wilto> Implementors and a few devrel folks.
  487. # [16:28] <jgraham> Wilto: We generally don't talk about the roadmap
  488. # [16:28] <jgraham> Except when we do
  489. # [16:28] <zcorpan> jgraham: you got the meme wrong :-P
  490. # [16:29] <jgraham> zcorpan: I don't know all the memes
  491. # [16:30] <gsnedders> Object.getPrototypeOf(xOriginWindow) doesn't throw anywhere…
  492. # [16:30] <Wilto> jgraham: Well, that’s a pretty major factor in implementation across all the browsers.
  493. # [16:30] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
  494. # [16:30] <zcorpan> Wilto: i haven't discussed this really until now. but i'm happy to write down the complexity differences between an attribute and elements sometime next week
  495. # [16:31] <Wilto> zcorpan: I’d like to see that, yes.
  496. # [16:31] <jgraham> Wilto: It doesn't seem like it's that complicated really
  497. # [16:31] <jgraham> Wilto: You can DNS prefetch
  498. # [16:31] <jgraham> But you can't speculatively grab the resources in a bandwidth-efficient way
  499. # [16:31] <jgraham> Because it depends on layout which one you pick
  500. # [16:31] <Wilto> jgraham: I can’t speak to that complexity, but I know it has been a major factor in discussions with Chrome.
  501. # [16:32] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
  502. # [16:32] <hober> jgraham: in my proposal, asset choice doesn't depend on layout.
  503. # [16:32] <Wilto> I’m happy to revisit that and post the results—or the discussion itself—publicly.
  504. # [16:32] <hober> jgraham: one of the differences between hixie's and mine
  505. # [16:32] <jgraham> hober: Oh.
  506. # [16:32] <jgraham> That seems to address fewer use cases?
  507. # [16:32] <hober> yup
  508. # [16:32] <zcorpan> now, nice weekend everyone :-)
  509. # [16:33] <hober> jgraham: the perfect is the enemy of the good :)
  510. # [16:33] <hober> jgraham: baby steps and all
  511. # [16:33] <jgraham> OK, I guess you can always ditch use cases in order to get prefetching working
  512. # [16:33] * Quits: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  513. # [16:33] * Joins: twisted` (~twisted@p5DDBB4BC.dip.t-dialin.net)
  514. # [16:33] * Quits: erichynds (~ehynds@64.206.121.41)
  515. # [16:33] * Quits: twisted` (~twisted@p5DDBB4BC.dip.t-dialin.net) (Client Quit)
  516. # [16:33] <jgraham> hober: Sure, I don't know what the right compromise is, exactly
  517. # [16:35] * Joins: tomasf_ (~tom@2002:55e5:dbde:0:503:7117:f427:86df)
  518. # [16:37] <Wilto> The idea for a new element came about because we were looking for a way to preserve prefetching—or at least sandbox any custom prefetching behavior—without abandoning functionality.
  519. # [16:39] <jgraham> I don't understand how element vs attribute can affect prefetching. I understand that not depending on layout can affect what prefetching you can do at the expense of not meeting all the use cases
  520. # [16:40] * Quits: MikeSmith (~MikeSmith@s1106167.xgsspn.imtp.tachikawa.spmode.ne.jp) (Quit: MikeSmith)
  521. # [16:41] * Quits: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net) (Quit: leaving)
  522. # [16:43] <Wilto> jgraham: I’ll gather more information on that.
  523. # [16:48] <Wilto> I’m going to post these discussions to the Community Group; just a heads-up.
  524. # [16:48] * Joins: MikeSmith (~MikeSmith@s1106027.xgsspn.imtp.tachikawa.spmode.ne.jp)
  525. # [16:49] <Wilto> And the associated proposals.
  526. # [16:49] <Wilto> And reach out to the developer community to voice their preference. Would anyone like to be the primary point of contact for that, or should I direct them to the WHATWG at large?
  527. # [16:50] <jgraham> To the WHATWG
  528. # [16:51] <hober> whatwg@whagwg.org is the right place. n.b. "+1" posts (posts which express a preference but do not make a novel point) are discouraged on the whatwg list.
  529. # [16:51] <jgraham> If you email the WHATWG list then nothing will get lost
  530. # [16:55] <Wilto> Sure; sounds good.
  531. # [16:55] <kennyluck> Seriouly, I don't quite buy any "theories" with bikeshedding issues and in that case voting just helps.
  532. # [16:56] <Wilto> I’ll encourage people to sound off with their +1s in another forum, since a big part of this discussion seems to be developer preference.
  533. # [16:56] <Wilto> The list may not be the right place for it, but it should be recorded.
  534. # [16:59] <kennyluck> Wilto, agreed. Hixie ought to consider a poll as "data", but I think he prefers to call it "usability research". I don't quite know the difference but he might be able to give you some hints.
  535. # [17:01] * Philip` guesses the difference is that polls are usually biased towards groups with the strongest opinions and with the widest ability to convince other people to vote, whereas usability research tries to get a smaller but more representative sample
  536. # [17:03] <jgraham> If developers have a preference, they should articulate *why* they prefer one form over another
  537. # [17:03] * Joins: ehsan (~ehsan@66.207.208.98)
  538. # [17:05] <Wilto> Well, I’ve been taking on a firehose of developer opinions on this subject for months. Which is not so much like “herding cats” as it is “herding YouTube commenters.”
  539. # [17:06] <hober> wheee! :)
  540. # [17:06] <Wilto> I could cite all the discussions on the CG, and gather up links to offsite stuff, or I can just tell them to get involved in these discussions. You’re gonna get some +1s—and naturally a reasoned argument would be preferable—but they shouldn’t be discounted entirely either.
  541. # [17:07] <Wilto> hober: Man oh man, do folks have Opinions on the Internet.
  542. # [17:09] * Quits: jdaggett (~jdaggett@193.105.139.140) (Quit: jdaggett)
  543. # [17:10] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  544. # [17:11] * Quits: Ms2ger (~Ms2ger@91.181.124.114) (Ping timeout: 245 seconds)
  545. # [17:13] * Quits: skylamer` (cgskylamer@78.90.213.55)
  546. # [17:15] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
  547. # [17:22] * Quits: nonge (~nonge@91.50.103.22) (Quit: Verlassend)
  548. # [17:26] * Joins: ehsan (~ehsan@66.207.208.98)
  549. # [17:37] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Quit: tantek)
  550. # [17:45] * Joins: Maurice` (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  551. # [17:50] * Quits: Kolombiken (~Adium@217.13.228.226) (Quit: Leaving.)
  552. # [17:52] <karlcow> +1 to the above
  553. # [17:53] <hober> Wilto: indeed. http://xkcd.com/386
  554. # [17:54] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Quit: hij1nx)
  555. # [17:58] * Quits: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Quit: tomasf)
  556. # [17:58] * tomasf_ is now known as tomasf
  557. # [18:07] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
  558. # [18:08] * Joins: hij1nx (~hij1nx@mobile-166-137-137-190.mycingular.net)
  559. # [18:10] * Joins: mven (~mven__@169.241.49.57)
  560. # [18:11] * Joins: mpt (~mpt@canonical/mpt)
  561. # [18:14] * jonlee|afk is now known as jonlee
  562. # [18:19] * Joins: lorin (~alystair@108.162.155.35)
  563. # [18:19] <dglazkov> good morning, Whatwg!
  564. # [18:21] * Quits: alystair (~alystair@108.162.155.35) (Ping timeout: 255 seconds)
  565. # [18:26] * jonlee is now known as jonlee|afk
  566. # [18:26] * Quits: hij1nx (~hij1nx@mobile-166-137-137-190.mycingular.net) (Read error: Connection reset by peer)
  567. # [18:28] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  568. # [18:28] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  569. # [18:30] * Quits: krit (~krit@sjfw1-a.adobe.com) (Read error: Connection reset by peer)
  570. # [18:31] * Joins: hij1nx (~hij1nx@206.sub-166-248-1.myvzw.com)
  571. # [18:33] * Quits: dbaron (~dbaron@193.105.139.140) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  572. # [18:35] * Joins: weinig (~weinig@2620:149:4:1b01:b189:6b7c:b8ed:8923)
  573. # [18:37] * Joins: necolas (~necolas@108-233-85-186.lightspeed.sntcca.sbcglobal.net)
  574. # [18:39] * Joins: pablof (~pablof@144.189.101.1)
  575. # [18:41] * Quits: tabatkins (~jackalmag@193.105.139.140) (Ping timeout: 265 seconds)
  576. # [18:48] * Quits: hij1nx (~hij1nx@206.sub-166-248-1.myvzw.com) (Quit: hij1nx)
  577. # [18:52] * Joins: jsbell (jsbell@nat/google/x-sjxxiyftitssttkc)
  578. # [18:52] * Joins: ap (~ap@2620:149:4:1b01:b90c:29da:aa95:663d)
  579. # [19:04] * Joins: FredB (~chatzilla@ip-50-21-130-214.dsl.netrevolution.com)
  580. # [19:05] * Joins: jklm313 (65d40601@gateway/web/freenode/ip.101.212.6.1)
  581. # [19:07] * Joins: barnabywalters (~barnabywa@host-92-28-214-253.as13285.net)
  582. # [19:07] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  583. # [19:10] * Joins: Craig___ (ad323006@gateway/web/freenode/ip.173.50.48.6)
  584. # [19:10] * Joins: alexlande (43b04e33@gateway/web/freenode/ip.67.176.78.51)
  585. # [19:11] * Quits: myakura (~myakura@FL1-221-171-5-98.tky.mesh.ad.jp) (Remote host closed the connection)
  586. # [19:11] * Joins: yodasw16 (~dgillhesp@ql1fwhide.rockfin.com)
  587. # [19:11] * Joins: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se)
  588. # [19:12] * Quits: Craig___ (ad323006@gateway/web/freenode/ip.173.50.48.6) (Client Quit)
  589. # [19:12] * Quits: pyrsmk (~pyrsmk@84.6.46.4) (Read error: Operation timed out)
  590. # [19:15] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  591. # [19:18] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
  592. # [19:20] * Joins: staydecent (80bdcc0b@gateway/web/freenode/ip.128.189.204.11)
  593. # [19:21] <staydecent> <source src="... looks redundant
  594. # [19:22] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  595. # [19:22] * Quits: Lachy (Lachy@nat/opera/x-hespsssvoeovustv) (Quit: Computer has gone to sleep.)
  596. # [19:23] <barnabywalters> staydecent: what would you suggest?
  597. # [19:24] * Joins: ShaneHudson (~sh548@raptor.ukc.ac.uk)
  598. # [19:24] * Parts: alexlande (43b04e33@gateway/web/freenode/ip.67.176.78.51)
  599. # [19:25] * Quits: jklm313 (65d40601@gateway/web/freenode/ip.101.212.6.1) (Ping timeout: 245 seconds)
  600. # [19:26] <staydecent> Why not have all elements within <picture> be <img>?
  601. # [19:27] <barnabywalters> could that not cause serious backwards compatibility problems?
  602. # [19:27] <staydecent> ah.. right. Old browser would just ignore the <source> elements?
  603. # [19:28] <barnabywalters> yep
  604. # [19:28] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
  605. # [19:28] <barnabywalters> that's the beauty of the <picture> element + fallback (although I hate the name. It's like calling <video> <film>)
  606. # [19:28] <Wilto> staydecent: Current browser behavior is just to find the src, and then “case closed.” Old browsers would ignore them, but so would new ones without some major parsing changes.
  607. # [19:29] <Wilto> barnabywalters: Hah, I don’t love `picture` either, truth be told. Every time we raise the issue, though, no one has anything better.
  608. # [19:30] <staydecent> Yeah. i agree I find the <picture> element much more readable for developing than the set attr. But, the naming is a little off. But again, I have no suggestions atm
  609. # [19:30] <barnabywalters> hmmm... I read <image> is an alias for <img>, so if that's true that wouldn't work
  610. # [19:30] <ShaneHudson> Somebody mentioned in the comments about calling it <image>... I think it would work, more consistant without being confusing
  611. # [19:30] <Wilto> barnabywalters: Yeah, a lot of older browsers treat img and image the same.
  612. # [19:30] <zcorpan> s/a lot of older//
  613. # [19:30] <othermaciej> barnabywalters: I think <movie> and <sound> might have been fine names for <video> and <audio>
  614. # [19:30] <Wilto> Which stands to introduce Troubles.
  615. # [19:30] <staydecent> how much older?
  616. # [19:31] <zcorpan> the html spec requires <image> to be parsed as <img>
  617. # [19:31] <Wilto> zcorpan: Is that right—current, too? Admittedly, someone else ran those tests and reported back.
  618. # [19:31] <staydecent> ah
  619. # [19:31] <barnabywalters> <sound> might have been alright, but I don't like <movie>
  620. # [19:31] <zcorpan> Wilto: current too, yeah. pages depend on it. :(
  621. # [19:32] <Wilto> “Oh, what a tangled web we weave.”
  622. # [19:32] <ShaneHudson> How about <responsive> since <picture> includes <img> inside of it, rather than replacing
  623. # [19:32] <barnabywalters> that's a bit ambiguous
  624. # [19:33] <Wilto> Yeah—and kind of hitches our horses to that term. I loves me some RWD of course, but…
  625. # [19:33] <ShaneHudson> True, it is too much of a buzzword as it is
  626. # [19:33] * Quits: staydecent (80bdcc0b@gateway/web/freenode/ip.128.189.204.11) (Quit: Page closed)
  627. # [19:34] * Joins: staydecent (80bdcc0b@gateway/web/freenode/ip.128.189.204.11)
  628. # [19:34] <staydecent> This is a bit of a braindump, but: what about <media> which could expand to have <source>...etc. and then either <img> or <video>?
  629. # [19:35] <barnabywalters> staydecent: so you'd have something like <media type="video">
  630. # [19:35] <staydecent> Maybe that conflicts with media-queries tho.
  631. # [19:35] <staydecent> yeah
  632. # [19:35] <zcorpan> let's not complicate <video>
  633. # [19:35] <ShaneHudson> I like the idea of giving chance for <video> as well as <img> but I am not sure if there would be troubles with implementations
  634. # [19:35] <othermaciej> <video> already has media-query-based responsiveness
  635. # [19:36] <Wilto> I’m with zcorpan there.
  636. # [19:36] <othermaciej> also, the <element type=actual-element> pattern is kinda lame
  637. # [19:36] <ShaneHudson> Would it be completely stupid to have <img> as the main element with optional sources inside? <img src="default"><source></img>
  638. # [19:36] <othermaciej> it's only really useful for <input> since it falls back to a text input, which is often a reasonable choice
  639. # [19:36] <barnabywalters> yeah, agreed. Doesn't seem very stable
  640. # [19:36] <Wilto> It’s tough because this topic feels like an opportunity to address so many other, related issues.
  641. # [19:36] <zcorpan> othermaciej: i argued on the list that <source media> is the wrong solution and maybe should be dropped :-)
  642. # [19:36] <zcorpan> (for video)
  643. # [19:36] <Wilto> But we can’t, y’know?
  644. # [19:36] <othermaciej> zcorpan: I do wonder if anyone is using it
  645. # [19:37] <othermaciej> zcorpan: the original purpose was for (rather hypothetical) accessibility-related and bandwidth-related additions to media queries
  646. # [19:37] <othermaciej> <source> mainly seems useful only for content type selection
  647. # [19:37] <zcorpan> othermaciej: indeed
  648. # [19:38] * Quits: Necrathex (~Necrathex@82-170-160-25.ip.telfort.nl) (Quit: Leaving)
  649. # [19:38] <barnabywalters> that's a very good point - using source for images would be inconsistent with video
  650. # [19:38] <zcorpan> othermaciej: i think it makes more sense to use something like "adaptive streaming" with a single <source> URL to switch streams
  651. # [19:38] <zcorpan> since bandwidth and wanted resolution can change over time
  652. # [19:38] <barnabywalters> zcorpan: can you go into more detail about how that would work?
  653. # [19:38] <othermaciej> adaptive streaming does make more sense as an approach to video
  654. # [19:38] <staydecent> Would you need the attr type="video" tho?
  655. # [19:38] <othermaciej> not really as sensible for static images
  656. # [19:39] <Wilto> Let’s not get too bikeshed-y in here though, guys.
  657. # [19:40] <Wilto> The community group is great for this stuff; I’d like to keep the brainstorming in there, if that’s cool.
  658. # [19:40] <zcorpan> barnabywalters: something like apple's "adaptive streaming" thing for mpeg4, but not necessarily exactly that
  659. # [19:40] <barnabywalters> so pushing the responsibility more towards the browser manufacturers?
  660. # [19:41] <zcorpan> compared to what?
  661. # [19:41] <zcorpan> <source media> is the responsibility of the browsers too
  662. # [19:41] <barnabywalters> compared to picture where the authors decide what images they're providing and when to display them
  663. # [19:41] <ShaneHudson> It would make it a lot easier for general users defintely... it is easy to learn about <img> but <picture> (although the best soloution so far) is pretty complicated
  664. # [19:41] <zcorpan> i'm talking about <video> right now :-)
  665. # [19:42] <barnabywalters> ah, my bad :)
  666. # [19:42] * Joins: chriscoyier (~Adium@66.150.243.10)
  667. # [19:42] <ShaneHudson> Hey chriscoyier :)
  668. # [19:42] <zcorpan> for images, adaptive streaming doesn't make much sense, as othermaciej said
  669. # [19:43] <staydecent> What about <picture> -> <imagegroup>?
  670. # [19:43] <zcorpan> i guess i should write that email about complexity with <source> vs an attribute
  671. # [19:43] <barnabywalters> staydecent: to me, imagegroup implies a group of related but distinct images
  672. # [19:43] <othermaciej> for video, you really want to change bandwidth/quality tradeoff in the middle of playback rather than loading a whole new resource
  673. # [19:43] <othermaciej> for still images, you could at most select once
  674. # [19:43] <staydecent> barnabywalters: I feel like you guys have thought on this quite well. Good point.
  675. # [19:44] <othermaciej> for resolution-based decisions, media queries it seems are not really sufficient, given the implied semantic of scaling in accordance with the scale factor used for selection
  676. # [19:44] <zcorpan> othermaciej: yeah. if you chime in and say so on the list, maybe we can kill <source media> now :)
  677. # [19:44] <zcorpan> (i think opera is the only one to have implemented it, though mozilla are apparently working on it right now)
  678. # [19:44] <staydecent> can I check some logs somewhere for alternate suggestions that have been made for <picture>?
  679. # [19:44] <barnabywalters> staydecent: TBH I prefer it to <picture>, but I don't think it's right, as such
  680. # [19:45] <ShaneHudson> I agree that <imagegroup> feels more like a list tag than alternatives
  681. # [19:46] <padenot> zcorpan: I just finished the patch to have <source media>, it is landing today, afaik
  682. # [19:46] <zcorpan> othermaciej: (subject "Re: [whatwg] <source> media attribute behavior, static or dynamic ?" on whatwg)
  683. # [19:46] <zcorpan> padenot: ah
  684. # [19:46] <padenot> zcorpan: in Gecko, that is
  685. # [19:46] <zcorpan> padenot: do you think it is a useful feature?
  686. # [19:46] <othermaciej> zcorpan: I have to think about it more before saying anything definitive
  687. # [19:46] <padenot> zcorpan: it can have its use, but I don't expect a lot of people to use it
  688. # [19:47] <zcorpan> padenot: what would it be useful for?
  689. # [19:47] <padenot> zcorpan: get scaled down video on mobile
  690. # [19:48] <zcorpan> padenot: but it's not really appropriate for that, afaict (as i said on the list)
  691. # [19:48] <padenot> zcorpan: the bandwith problem is likely to be addressed by dash
  692. # [19:48] <zcorpan> dash?
  693. # [19:49] <padenot> zcorpan: http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
  694. # [19:49] <zcorpan> ah. right. why isn't that a better solution to the mobile problem than media=""?
  695. # [19:51] <padenot> zcorpan: i don't know enough about dash yet to provide a good answer, i think
  696. # [19:51] <staydecent> Sorry if this is the wrong place: Where does current support lean regarding <picture> vs set=""?
  697. # [19:52] <padenot> zcorpan: don't know if we can request specifically a resolution or the like
  698. # [19:53] <zcorpan> padenot: but the browser would be able to "adapt" to a resolution that currently fits the viewing device, right?
  699. # [19:53] <jgraham> ~.
  700. # [19:53] <othermaciej> on mobile you may want to serve different size rather than different quality (these are generally separate parameters to the encoding process)
  701. # [19:53] <othermaciej> but generally this is done by UA sniffing
  702. # [19:54] <ShaneHudson> For a renaming of <picture>... what about <quality> or <version>? Too 'meta'?
  703. # [19:54] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
  704. # [19:54] <padenot> zcorpan: I think it is reasonnable to say that, but I don't know for sure
  705. # [19:54] <barnabywalters> shanehudson: you're talking about renaming the <source> child tags?
  706. # [19:55] <barnabywalters> or the <picture> tag it's self?
  707. # [19:55] <ShaneHudson> barnabywalters: I was thinking more of <picture> to <versions> or something
  708. # [19:55] * Joins: Zunflappie (4da9bd61@gateway/web/freenode/ip.77.169.189.97)
  709. # [19:56] <barnabywalters> ShaneHudson: I think the root element should describe the content type. Otherwise things could get sticky later on
  710. # [19:56] <barnabywalters> e.g. for different content types, content types that don't even exist yet, etc
  711. # [19:56] * Joins: tabatkins (~jackalmag@80.187.201.55)
  712. # [19:57] <ShaneHudson> fair enough, in an ideal world it would be nice to be able to work with any content type, but that is of course not the case
  713. # [19:58] <Zunflappie> What about CSS > instead of background-image also a front-image? As a overlay over the image? <img src="small.jpg" style="front-image: url(big.jpg); media=min-400px">
  714. # [19:58] <Zunflappie> I dont know the right syntax for inline style with media-queries, but you got the point?
  715. # [19:58] <staydecent> Zunflappie: that would load both images though?
  716. # [19:59] <Zunflappie> Yeah, but dont need javascript.
  717. # [19:59] <barnabywalters> Can I get people's opinion on this syntax: http://jsfiddle.net/aZ37N/ -- would there be any serious backward compatibility/other problems?
  718. # [20:00] <barnabywalters> the <version> is hypothetical, it's using the <img> tag as a wrapper I'm interested in
  719. # [20:00] <Zunflappie> Look good, only the <version> is strange.
  720. # [20:00] <Zunflappie> </img> isnt needed, but should be a big thing to learn
  721. # [20:00] <barnabywalters> sure, as I say, I think that needs to be given more thought as to naming/exact syntax
  722. # [20:00] <Zunflappie> Indeed, it sounds / reads good
  723. # [20:01] <barnabywalters> Zunflappie: the </img> is the whole point — using the <img> as a fallback and also the wrapper for alternate sources
  724. # [20:01] <barnabywalters> e.g. we change <img> to be a non-self-closing tag (or whatever terminology)
  725. # [20:02] * Joins: David_Bradbury (~chatzilla@75-147-178-254-Washington.hfc.comcastbusiness.net)
  726. # [20:02] <staydecent> barnabywalters: I like your proposition. Having the img element as the parent makes sense to me
  727. # [20:02] <MikeSmith> barnabywalters: there are serious backward-compatibility problems
  728. # [20:02] <Zunflappie> Euh... yeah. Not like <hr> but as <caption>. And maybe <video> also? <video src="normal.avi"><... src="large"></video>
  729. # [20:02] <barnabywalters> MikeSmith: I thought as much ;)
  730. # [20:03] <staydecent> damn, backwards compatibility is no fun.
  731. # [20:03] <MikeSmith> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cimg%20src%3D%22Mobile.jpg%22%20alt%3D%22%22%3E%0A%20%20%20%20%3Cversion%20src%3D%22med-res.jpg%22%20media%3D%22%22%20%2F%3E%0A%20%20%20%20%3Cversion%20src%3D%22hi-res.jpg%22%20media%3D%22%22%20%2F%3E%0A%3C%2Fimg%3E
  732. # [20:03] * Quits: Zunflappie (4da9bd61@gateway/web/freenode/ip.77.169.189.97) (Quit: Page closed)
  733. # [20:04] * Joins: gorh (58aa6460@gateway/web/freenode/ip.88.170.100.96)
  734. # [20:04] <gorh> hi there
  735. # [20:04] * Joins: Zunflappie (4da9bd61@gateway/web/freenode/ip.77.169.189.97)
  736. # [20:04] <barnabywalters> MikeSmith: I'm missing something here — what is the problem you're highlighting in that page?
  737. # [20:05] * Quits: tabatkins (~jackalmag@80.187.201.55) (Ping timeout: 244 seconds)
  738. # [20:05] <Zunflappie> There was nog closing-tag for the option (like </option>)
  739. # [20:05] <MikeSmith> your first version element becomes a sibling of the img, not a child, and the second version element becomes a child of the first one
  740. # [20:05] * Quits: necolas (~necolas@108-233-85-186.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
  741. # [20:06] <Zunflappie> <img src="..."><option src="..."></option></img> could work?
  742. # [20:06] <MikeSmith> we can't change the parsing behavior for img
  743. # [20:06] <barnabywalters> ah, okay
  744. # [20:06] <Zunflappie> So both <options> <captions> are first-generation-children of <img>?
  745. # [20:07] <ShaneHudson> barnabywalters: I *really* like that syntax (<img><version></img) but I expect there would be some major problems wtih compatibility
  746. # [20:07] <barnabywalters> Zunflappie: even if we added closing tags to the source selection tags, they'd still be siblings, not children of <img>
  747. # [20:07] <jgraham> The only solution involving <img> that can work is to put all the sources in an attribute
  748. # [20:07] <jgraham> You *can't* change the parsing of <img>
  749. # [20:08] * Joins: smaug____ (~chatzilla@212-226-65-89-nat.elisa-mobile.fi)
  750. # [20:08] <jgraham> (or <image>)
  751. # [20:08] <Zunflappie> Such as <img src="small.jpg" medium="middle.jpg" large="giant.jpg"> ?
  752. # [20:08] <barnabywalters> jgraham: indeed. Looks like using <img> isn't likely to work
  753. # [20:08] * Joins: Charun (~Charun@unaffiliated/charun)
  754. # [20:08] <Zunflappie> <picture> as alternative/extra is then a good thing?
  755. # [20:08] <gorh> hé hé i see i arrived in the right discution :)
  756. # [20:08] <jgraham> Zunflappie: There is a better proposal (imho) on the whatwg list
  757. # [20:08] * Joins: edwardbc (~edward.ba@186.176.193.20)
  758. # [20:08] <ShaneHudson> It will not work as attributes
  759. # [20:09] <staydecent> Sorry to diverge a bit here, but this article is confusing: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ -- Which group proposed the picture solution?
  760. # [20:09] <jgraham> ShaneHudson: Why not? Did you see the proposal on that whatwg list?
  761. # [20:09] <ShaneHudson> The syntax for set for example looks horrid and would be hard for even us to get to grips with, let alone beginners
  762. # [20:09] <barnabywalters> ShaneHudson: agreed. set="" is horrible
  763. # [20:09] <Zunflappie> Staydecent: thats the page why I turned here in. The <picture> looks good to me, as <img> is still there.
  764. # [20:09] * Quits: MikeSmith (~MikeSmith@s1106027.xgsspn.imtp.tachikawa.spmode.ne.jp) (Quit: MikeSmith)
  765. # [20:10] <gorh> i have to say that i, too would prefer by far <picture><source ... to the attribute way, at least for the sake of my eyes )
  766. # [20:10] <staydecent> I agree as well. I am in favour of <picture> over the set attr. Just confused as to who has proposed what.
  767. # [20:10] <ShaneHudson> Yeah I have been following <picture> for quite a while. I do not believe it is the best soloution, but certainly superior to set=""
  768. # [20:10] <barnabywalters> the tag based approach would also be easier to generate/parse in code
  769. # [20:10] <Zunflappie> Is is possible to work only with <img>'s? <picture><img src="small" media="min-width: 400px;"><img src=""><img src=""></picture>
  770. # [20:11] <ShaneHudson> Nope
  771. # [20:11] <Zunflappie> Or does that render always 3 images (so small, middle and large?)
  772. # [20:11] <staydecent> yeah for older browsers would render all 3
  773. # [20:11] <ShaneHudson> Since that would (on older browsers at least) render all of them
  774. # [20:11] <gorh> tbh i can cope with throwin <img> tag away ;)
  775. # [20:12] * Joins: drublic (~drublic@frbg-5f732145.pool.mediaWays.net)
  776. # [20:12] <barnabywalters> gorh: not if you want to support older browsers, surely?
  777. # [20:12] <ShaneHudson> Wouldn't it be nice to start with a clean slate!
  778. # [20:13] <barnabywalters> ShaneHudson: indeed :( That'd be no fun though :)
  779. # [20:13] <staydecent> Lol, Legacy is never fun. But necessary.
  780. # [20:13] <gorh> yep sure, but this can be coped as well lest say by hiding img via css for regular users
  781. # [20:14] <gorh> but i see the point on keeping the legacy browsers in the scope
  782. # [20:14] <staydecent> gorh: but then the image would still be downloaded by the user
  783. # [20:14] <Zunflappie> Exactly. What about IE6 or 10 year old machines (not callling them phones...). <picture> is like <video>, what is a good point. But i like a 3-letter-shortcut (like IMG for IMAGE) more. <VID> maybe?
  784. # [20:14] <staydecent> gorh: a goal of responsive images is not to force a mobile phone to download more than it needs to
  785. # [20:15] <Zunflappie> Hiding with CSS doesnt prevent downloading its contents!
  786. # [20:15] <barnabywalters> Zunflappie: that's interesting, I prefer full words to the abbreviations
  787. # [20:15] <Zunflappie> So you like <division> and <italic>?
  788. # [20:15] * Joins: tndrH (~Rob@adsl-94-72-219-35.karoo.kcom.com)
  789. # [20:15] <Zunflappie> Or what about <tr>????
  790. # [20:15] <barnabywalters> Zunflappie: within reason :)
  791. # [20:15] <gorh> yep sure, but i say do that by css, but there are plenty of other way to do so
  792. # [20:16] <barnabywalters> okay, <table-row> or <abbreviation> are a bit of a mouthful, but I think <video> is fine
  793. # [20:16] <Zunflappie> Yeah, Server-side. Otherwise it will get a HTTP-request
  794. # [20:16] <staydecent> gorh: CSS can't prevent a device from downloading the orginal image
  795. # [20:16] * Joins: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp)
  796. # [20:16] <gorh> css can't
  797. # [20:16] <gorh> but don't tell me that there is no other way )
  798. # [20:17] <Zunflappie> Javascript either..... only php/ruby on rails >> server, as the html should be altered
  799. # [20:17] <Zunflappie> And then... you must sniff the device first. That's not RESPONSIVE!
  800. # [20:18] * Joins: MikeSmith_ (~MikeSmith@s1106027.xgsspn.imtp.tachikawa.spmode.ne.jp)
  801. # [20:19] <Zunflappie> Hereby its all said?
  802. # [20:20] * Joins: Jayflux (~jay_knows@cpc1-dudl6-0-0-cust1981.wolv.cable.virginmedia.com)
  803. # [20:20] * Quits: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp) (Ping timeout: 244 seconds)
  804. # [20:20] * MikeSmith_ is now known as MikeSmith
  805. # [20:20] * Quits: smaug____ (~chatzilla@212-226-65-89-nat.elisa-mobile.fi) (Ping timeout: 255 seconds)
  806. # [20:20] <ShaneHudson> It is a shame there is not yet anyway to do responsive images without a multitude of them. Keep the original <img> tag and automatically make "responsive"
  807. # [20:21] * Parts: vanson2012 (~vanson201@061093228142.ctinets.com)
  808. # [20:21] <barnabywalters> ShaneHudson: I think someone has done that on the server side with cookies, generating a different copy of the image
  809. # [20:21] <gorh> no but infact i'm not that much attached to the <picture> tag, what annoys me the most is the attribute way
  810. # [20:22] <Zunflappie> <ShaneHudson: There is a manner with Javascript. But it takes also PHP for the correct sizes/urls
  811. # [20:22] <ShaneHudson> I am thinking browser side.. I have seen adaptive images etc. but none of them seem perfect for the job
  812. # [20:22] <ShaneHudson> Maybe it will come when we have bandwidth sniffing or something like that
  813. # [20:22] <Zunflappie> As there cant be a horse.jpg (small), horse.jpg (medium) and a horse.jpg (large)..... Or it must be in folders: .../small/horse.jpg and .../medium/horse.jpg etc
  814. # [20:23] <Zunflappie> that IO.<something) has that sniffing?
  815. # [20:23] <gorh> and, i also realise that it mainly is about code readability ... wile i should focus on the usability
  816. # [20:23] * Joins: sunkube (6cdffd81@gateway/web/freenode/ip.108.223.253.129)
  817. # [20:23] * Quits: sunkube (6cdffd81@gateway/web/freenode/ip.108.223.253.129) (Client Quit)
  818. # [20:23] <ShaneHudson> The only one I know is foresight.js
  819. # [20:23] <Zunflappie> See http://css-tricks.com/which-responsive-images-solution-should-you-use/ >>
  820. # [20:23] <Zunflappie> Sencha.IO (based on foresight.js)
  821. # [20:23] <Jayflux> Can anyone tell me the point of the <embed> tag? all browsers seem to work fine without it when the attributes are put on the object tag instead, it also validates properly.
  822. # [20:24] <ShaneHudson> Jayflux: I believe that was to do with ie5.5? May well be wrong though
  823. # [20:24] <gorh> but, tbh, with daily uses, i prefer from far working on readable code rather than looooooong tags
  824. # [20:24] <ShaneHudson> defintely
  825. # [20:24] <Jayflux> so it may aswell be obsolete ShaneHudson ?
  826. # [20:25] <Jayflux> in terms of today usage
  827. # [20:25] <ShaneHudson> Jayflux: I believe so, but it is not an area I pay much attention to tbh
  828. # [20:26] <Zunflappie> What is 'tbh'? Probaly not The Birthday Hub.... :P
  829. # [20:26] * Joins: saba (~foo@unaffiliated/saba)
  830. # [20:26] <gorh> to be honest
  831. # [20:27] <Zunflappie> ok! When does w3c comes with a poll?
  832. # [20:28] * Joins: jasongoldstein (~jgoldstei@75.87.182.237)
  833. # [20:28] <gorh> what i mean is that, the <picture way is more developer friendly, and the <img set...> one is more browser friendly, and i'm still no sure if i prefer or to have to deal with both syntax and compatibility, and have something easy to read
  834. # [20:28] <gorh> or to have each img tag filling lines and lines of not explicit code
  835. # [20:30] <barnabywalters> gorh: I think one of the great things about HTML is it's ease of use. It's really easy to understand, and it'd be a pity to lose that, especially on something as fundamental as an image
  836. # [20:30] * Joins: accessus (567e00ab@gateway/web/freenode/ip.86.126.0.171)
  837. # [20:31] * Quits: accessus (567e00ab@gateway/web/freenode/ip.86.126.0.171) (Client Quit)
  838. # [20:31] <staydecent> Is there any course of action to help picture get implemented over img set? I guess being in this IRC?
  839. # [20:32] <Zunflappie> Good point barnabywalters! So always maintain current syntaxes
  840. # [20:32] <gorh> barnabywalters: i totaly agree on that this is why i like the <picture> way )
  841. # [20:32] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  842. # [20:32] <Zunflappie> And more: its like the new <video> and <audio>..... make <embed> and <object> the same syntax?
  843. # [20:33] <ShaneHudson> staydecent: http://www.w3.org/community/respimg/
  844. # [20:33] <gorh> Zunflappie: you really find the attribute way more clear ?
  845. # [20:33] <Zunflappie> As a browser supports html5, it can be doen
  846. # [20:33] <staydecent> ShaneHudson: Thanks
  847. # [20:33] <barnabywalters> Zunflappie: actually, the similarity to <video> and <audio> is something I'm uncomfortable about
  848. # [20:33] <Zunflappie> Gorh: like <img src="small.jpg" medium="middle.jpg" .......> atc?
  849. # [20:34] <gorh> as simple as that that would be a dream )
  850. # [20:34] <Zunflappie> <video> <audio> and <picture> are all media? More then text can't video/audio/picture realign or crop. Audio is special (as it doenst need take space in a page)
  851. # [20:34] <barnabywalters> as video and audio's <source> choses different codecs based on browser compatibility, whereas proposed picture <source> choses a different size based on screen size — so very different meanings to the same syntax
  852. # [20:35] <gorh> but what about breakpoint to choose image etc etc
  853. # [20:35] * Joins: jarib (~jarib@unaffiliated/jarib)
  854. # [20:35] <lorin> Zunflappie: xlarge jumbo gojira
  855. # [20:35] <barnabywalters> gorh: Yes, <img src="" medium="" etc is inflexible. In fact, html used to have lowsrc="" or something
  856. # [20:35] <barnabywalters> so that'd almost be a step backwards :)
  857. # [20:35] <Zunflappie> lorin: thats a point. Anno 2012 we want 3 sizes... but what if I want 4 or 5? lowsrc="" works a bit, but aint flexible. It was only a idea.
  858. # [20:36] <gorh> one tag to define 3 or more image path and beahvior ... it implies a tag too long in my opignon
  859. # [20:36] <Zunflappie> <picture> with media-queries are better.... but i hate the syntax of the queries. MIN and MAX could be better for me.
  860. # [20:36] <barnabywalters> Zunflappie: agreed, I'm not sure about using media queries as the syntax
  861. # [20:37] <barnabywalters> as they assume that small screen size = smaller bandwidth
  862. # [20:37] * Joins: necolas (~necolas@8.25.195.27)
  863. # [20:37] <ShaneHudson> which is completely wrong. My home wifi is slower than 3G lol
  864. # [20:37] <Zunflappie> Thats not a problem, but more when i resize my window
  865. # [20:38] <Zunflappie> Shane: haha, fix your Wifi then :P
  866. # [20:38] <ShaneHudson> House is too far away from the exchange sadly. But luckily here at uni I am on fibre :D
  867. # [20:38] <barnabywalters> ShaneHudson: I get that sometimes. Mine has really bad range, I have to use 3G when I'm upstairs sometimes
  868. # [20:39] <Zunflappie> Oke. I hope i haved helped the whatwg to choose for <picture> or something else. Nevermind.... but please: choose fast.
  869. # [20:39] <Zunflappie> Its 20:30... time for Top Gear (and beer and chips)
  870. # [20:40] <staydecent> Zunflappie: Haha, enjoy!
  871. # [20:41] <gorh> long live to the <picture> tag :) i'm off a well )
  872. # [20:41] * Quits: gorh (58aa6460@gateway/web/freenode/ip.88.170.100.96) (Quit: Page closed)
  873. # [20:42] * Joins: tantek (~tantek@nat/mozilla/x-omfcpznlwrsmrrrv)
  874. # [20:43] * Quits: Zunflappie (4da9bd61@gateway/web/freenode/ip.77.169.189.97) (Ping timeout: 245 seconds)
  875. # [20:44] * Quits: chriscoyier (~Adium@66.150.243.10) (Quit: Leaving.)
  876. # [20:44] * Joins: nesta_ (~nesta_@84.122.96.113.dyn.user.ono.com)
  877. # [20:44] * Joins: jarek (~jarek@aean216.neoplus.adsl.tpnet.pl)
  878. # [20:44] * Quits: jarek (~jarek@aean216.neoplus.adsl.tpnet.pl) (Changing host)
  879. # [20:44] * Joins: jarek (~jarek@unaffiliated/jarek)
  880. # [20:45] <staydecent> Anyone willing to recap the issues/limitations of the <picture> tag besides semantics?
  881. # [20:46] <ShaneHudson> http://trac.webkit.org/changeset/111637 Image-Set in webkit
  882. # [20:46] * Joins: ryanlabouve (~ryanlabou@pat-ip-129-15-127-56.fennfwsm.ou.edu)
  883. # [20:47] <barnabywalters> ShaneHudson: I just found a link to that too, I can't really make much sense of how it could be used though
  884. # [20:47] * Quits: ryanlabouve (~ryanlabou@pat-ip-129-15-127-56.fennfwsm.ou.edu) (Client Quit)
  885. # [20:48] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  886. # [20:48] <barnabywalters> ah, http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html explains it better
  887. # [20:48] <ShaneHudson> Hmm yes I see, so it is like <picture> but for css backgrounds
  888. # [20:49] <ShaneHudson> The syntax of that actually looks fairly nice
  889. # [20:49] <barnabywalters> There's some good explanations of why several options wouldn't work (including the one I suggested earlier) here: https://etherpad.mozilla.org/responsive-assets
  890. # [20:50] <ShaneHudson> *bookmarked*
  891. # [20:50] <ShaneHudson> That is a very good article
  892. # [20:50] <ShaneHudson> well, document :O
  893. # [20:50] <barnabywalters> even better, as (I think) we can edit it
  894. # [20:50] <ShaneHudson> yeah
  895. # [20:50] <staydecent> is that content pretty much the same as : http://www.w3.org/community/respimg/wiki/Main_Page
  896. # [20:51] <ShaneHudson> yeah very similar
  897. # [20:52] <staydecent> Shoot, now I'm leaning towards the image-set CSS approach: http://www.w3.org/community/respimg/2012/04/08/using-css-to-control-image-variants/
  898. # [20:53] <staydecent> But, how could that work with CMS's?
  899. # [20:53] * Quits: ap (~ap@2620:149:4:1b01:b90c:29da:aa95:663d) (Quit: ap)
  900. # [20:53] <barnabywalters> staydecent: it looks alright for images specified through css, I can't see anything about using it in markup
  901. # [20:53] <ShaneHudson> image-set is good for backgrounds, but not for images since they are usually part of the content rather than layout, and you would not want css for each and every image!
  902. # [20:54] <staydecent> Good points
  903. # [20:54] <padenot> /b 9
  904. # [20:54] <barnabywalters> I suspect that image-set could work nicely alongside a markup solution though
  905. # [20:55] * Joins: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net)
  906. # [20:57] * Joins: Denis_ (4b9d70bc@gateway/web/freenode/ip.75.157.112.188)
  907. # [20:58] * Parts: Denis_ (4b9d70bc@gateway/web/freenode/ip.75.157.112.188)
  908. # [20:58] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Read error: Connection reset by peer)
  909. # [21:00] * Joins: Matt__ (50e5df36@gateway/web/freenode/ip.80.229.223.54)
  910. # [21:00] <zcorpan> Wilto: ok i've sent an email to whatwg now. lemme know whether it makes sense
  911. # [21:01] <Matt__> Hello
  912. # [21:01] <staydecent> Just found this <picture> Polyfill: https://github.com/scottjehl/picturefill/blob/master/picturefill.js good way to test out how the proposed implementation would "feel"
  913. # [21:01] <Matt__> Sorry, hang on while I drag up my IRC knowledge from the depths of time and figure out how to change my name....
  914. # [21:01] <ShaneHudson> Do /nick "name"
  915. # [21:02] <Matt__> Thanks Shane
  916. # [21:02] <ShaneHudson> I take it we are all agreed that set="" is the wrong way to go?
  917. # [21:02] <Matt__> Set is the wrong way to go
  918. # [21:02] <barnabywalters> ShaneHudson: agreed
  919. # [21:03] <Matt__> Seem /nick "MattWilcox" didn't work ;)
  920. # [21:03] <ShaneHudson> really? strange
  921. # [21:03] <tomasf> try without the quotes
  922. # [21:03] * Quits: nesta_ (~nesta_@84.122.96.113.dyn.user.ono.com) (Quit: nesta_)
  923. # [21:03] <ShaneHudson> I still really like the <img><version></img> idea, shame that it would break everything!
  924. # [21:03] <Matt__> Might be something to do with being on webchat.freenode.net? I don't know, I've not used IRC in a decade or so.
  925. # [21:04] * Matt__ is now known as MattWilcox
  926. # [21:04] <MattWilcox> Ah ha!
  927. # [21:04] <MattWilcox> Thanks
  928. # [21:04] <ShaneHudson> Heh yeah I shouldn't have included the quotes
  929. # [21:05] <staydecent> ShaneHudson: Agreed. I also am against the set attribute.
  930. # [21:05] * Joins: cpearce (~cpearce@ip-118-90-120-55.xdsl.xnet.co.nz)
  931. # [21:05] <MattWilcox> I don't think the picture element is perfect, it needs refinement in another revision really.
  932. # [21:05] <ShaneHudson> MattWilcox: most of us seem to like the <picture> but feel it is the wrong name?
  933. # [21:05] <ShaneHudson> What would you say needs to change about it?
  934. # [21:06] <zcorpan> for people not reading the list, please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035784.html
  935. # [21:06] <MattWilcox> But it's a problem not unique to picture, but to the whole "adaptive" methodology that's in HTML at the moment.
  936. # [21:06] <MattWilcox> Shane: The problem is it being too impractical for real world use *en mass* - my thoughts were written up here: http://mattwilcox.net/archive/entry/id/1081/
  937. # [21:07] <MattWilcox> And I proposed a solution here, which was put the the RespImg group, and HTMLWG mailing list: http://mattwilcox.net/archive/entry/id/1082/
  938. # [21:07] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
  939. # [21:08] <staydecent> zcorpan: Thanks, that's a good writeup.
  940. # [21:08] <ShaneHudson> Hmmm, not entirely sure I like the breakpoint syntax but it certinally does make sense
  941. # [21:08] <zcorpan> staydecent: thanks
  942. # [21:08] * Quits: necolas (~necolas@8.25.195.27) (Remote host closed the connection)
  943. # [21:09] <staydecent> zcorpan: are the issues with <picture> shared with <video>?
  944. # [21:10] <MattWilcox> Shane: I'm open to refinement and ideas, the syntax I put there was literally a first idea.
  945. # [21:10] * Joins: Lachy (Lachy@nat/opera/x-wtqxgmaodhtxedwo)
  946. # [21:10] <MattWilcox> Thing is, what I propose is something that can be factored on-top of the existing <picture> proposal if we're desperate to ship now.
  947. # [21:11] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
  948. # [21:11] <zcorpan> staydecent: <video><source> is very complex for much the same reasons, yes, but is different (maybe even more complex) because the loading algorithm tries to load each <source> in turn, with potential for scripts to change things around at any point
  949. # [21:11] <ShaneHudson> Yeah, I get the idea and am not sure how it could be improved off the top of my head. Seems slightly "clunky" but it would only need to be written once
  950. # [21:12] <MattWilcox> Shane - yep, that's the huge benefit of that approach. And I agree that it's a bit verbose; so is <picture> itself.
  951. # [21:13] <staydecent> zcorpan: do current implementations deal with that in anyway? More so, has work been done already to deal with parsing all the source tags?
  952. # [21:13] <ShaneHudson> Maybe from a naming point of view, case changes to name, and match changes to case?
  953. # [21:13] <zcorpan> staydecent: <picture> would try to find a "best match" source, and could decide to change the source when the environment changes, so it's not the same algorithm as <video><source> at all really
  954. # [21:13] <staydecent> zcorpan: ahhh ok. that makes sense
  955. # [21:13] <MattWilcox> Yeah, perhaps. The naming itself doesn't bother me - that's implementation detail. It's the pattern I like.
  956. # [21:13] <zcorpan> staydecent: we have suffered with bugs with <video><source> because of its complexity
  957. # [21:14] <staydecent> zcorpan: in that case and out of curiousity what is your stance on picture vs img set?
  958. # [21:14] <MattWilcox> zcorpan: Yeah, but it works, right? So why not re-use it.
  959. # [21:14] <zcorpan> staydecent: as i said in the email, i think an attribute is simpler and would be a shorter path to interop
  960. # [21:15] <barnabywalters> MattWilcox: the <video><source> model has a different semantic meaning to the proposed <picture><source>
  961. # [21:15] <barnabywalters> and, as zcorpan says, there have been bugs
  962. # [21:15] <zcorpan> MattWilcox: i doubt all browsers follow the spec to the letter with <video><source> today. i know opera has bugs, and yet i think opera is *most* closely aligned with the spec
  963. # [21:15] <MattWilcox> I am not bothered about the ease with which vendors can implement a feature. That's done *once* in the life of HTML. It is FAR more important the syntax be flexible and easy to understand because millions of authors will learn and use it every day.
  964. # [21:16] <zcorpan> MattWilcox: also, as i said, we can't reuse the same code because <video><source> is not a best match
  965. # [21:16] <staydecent> zcorpan: ah didn't realise that was you. well, this changes my opinion quite a bit. Maybe Ill spend more time thinking about possible improvments to the set attr syntax
  966. # [21:17] <MattWilcox> zcorpan: hmm, not a best match? I have a feeling it's more complex an issue than it seems from my perspective.
  967. # [21:17] <staydecent> have there been any proposals in terms of bandwidth queries? Or is that something for far-off in the future?
  968. # [21:17] <MattWilcox> Bandwidth MQs have been requested for months
  969. # [21:17] <zcorpan> MattWilcox: <video><source> tries to play each <source> in turn, and stops when it has found one that plays
  970. # [21:17] <MattWilcox> But I don't know of any talk about implementation details.
  971. # [21:18] <zcorpan> MattWilcox: <picture> wants to decide which <source> is the best one, and load that
  972. # [21:18] <staydecent> Right, but the img set attr doesn't follow MQ syntax, unless I;m mistaken
  973. # [21:18] <annevk> hober: btw, does viewport width really depend on layout?
  974. # [21:18] <MattWilcox> zcorpan: ah, OK then the beaviour is quite different despite the syntax being similar
  975. # [21:18] <zcorpan> MattWilcox: (and probably do it later again when the environment has changed)
  976. # [21:18] <annevk> hober: because that seems like something that's an input to layout and is therefore already known
  977. # [21:18] <zcorpan> MattWilcox: indeed
  978. # [21:18] <annevk> hober: and can therefore be used at fetching time easily enough
  979. # [21:19] <zcorpan> staydecent: i think using MQ is also inappropriate, but for a different reason
  980. # [21:19] <MattWilcox> zcorpan: would it not be the same if <picture> was extended so that it could deal with requesting different file formats?
  981. # [21:19] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
  982. # [21:20] <MattWilcox> zcorpan: one thing I'd have liked <picture> to adopt is some method of making it much easier for new file formats like WebP to become practically usable - by offering fallbacks.
  983. # [21:20] <staydecent> zcorpan: I agree. I feel MQ should stay within CSS.
  984. # [21:20] * Joins: JT__ (183fb7d0@gateway/web/freenode/ip.24.63.183.208)
  985. # [21:20] <zcorpan> MattWilcox: different file formats isn't the use case we're trying to solve
  986. # [21:20] <staydecent> But I can't stand the <img set> syntax as it stands here: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/
  987. # [21:20] <MattWilcox> zcorpan & staydecent: I thing they should be moved OUT of CSS and put predomenantly into the <head>
  988. # [21:21] <MattWilcox> zcorpan & staydecent: but with CSS having the ability to over-ride as needed. See http://mattwilcox.net/archive/entry/id/1082/ for why
  989. # [21:21] <ShaneHudson> staydecent: Yeah, I can understnd why they thought of it but it would be terrible to add images like that
  990. # [21:21] * Joins: necolas (~necolas@8.25.195.26)
  991. # [21:22] <MattWilcox> I think the RespImg Group would have looked at adapting <img> more if Hicksie hadn't told members that alterations to <img> were impossible.
  992. # [21:22] <staydecent> I'm guessing they went with "600w 200h" instead of "600x200" as to not be confused with the DPI declaration "2x"
  993. # [21:22] <staydecent> ?
  994. # [21:22] * Quits: barnabywalters (~barnabywa@host-92-28-214-253.as13285.net) (Ping timeout: 250 seconds)
  995. # [21:22] <zcorpan> the problem with MQ for the bandwidth/"load the page faster" use case is that the MQ describes a state of the UA, and the author needs to get the query "right", where it is easy to get the behavior backwards (like resulting in a lower resolution image when the user zooms *in*)
  996. # [21:23] <MattWilcox> staydecent: irrelevent. However you look at it that ties adaption to pixel units. Responsive designs do not use pixel units.
  997. # [21:23] <annevk> MattWilcox: where did Hixie say that though?
  998. # [21:23] <MattWilcox> annevk: there are a couple of people trying to find that out because it has been an accepted thing over there, brought up a few times. I've not found the original source yet.
  999. # [21:23] <zcorpan> whereas with the "dpi" syntax, the author just describes information about the image, and the user agent is free to decide which image it deems is most appropriate for the user given the environment (the browser is in a much better position to know this than the author)
  1000. # [21:23] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
  1001. # [21:24] <annevk> MattWilcox: changing the parsing is impossible, adding attributes is not
  1002. # [21:24] <annevk> MattWilcox: maybe there was some confusion about terminology there and what people understand as to what "parsing" means...
  1003. # [21:24] <MattWilcox> See http://www.w3.org/community/respimg/common-questions-and-concerns/ and the section "What about modifying the behaviour of <img>?"
  1004. # [21:25] <annevk> MattWilcox: yeah that seems about parsing
  1005. # [21:25] <annevk> MattWilcox: with the "look ahead" remark
  1006. # [21:25] <ShaneHudson> I agree that we have to be careful about changing <img> due to older (and current) browsers... but that does not mean we cannot touch it
  1007. # [21:25] <annevk> MattWilcox: doesn't really mean you can't add new attributes, in fact, one of the proposals we have does so in a backwards compatible way
  1008. # [21:26] <staydecent> MattWilcox: I don't understand, aren't you using pixel units in your proposal: http://mattwilcox.net/archive/entry/id/1082/
  1009. # [21:26] <MattWilcox> I'm sure there has been some misunderstanding about it, which is incredibly frustraiting. Browser vendor representitives were asked about it, and this is a major reason why editing <img> was ruled out.
  1010. # [21:26] <annevk> Wilto: btw, it would be interesting to know who encouraged you to form a CG
  1011. # [21:26] * Quits: Lachy (Lachy@nat/opera/x-wtqxgmaodhtxedwo) (Quit: Computer has gone to sleep.)
  1012. # [21:27] * Joins: smaug____ (~chatzilla@193-64-20-193-nat.elisa-mobile.fi)
  1013. # [21:27] * Quits: smaug____ (~chatzilla@193-64-20-193-nat.elisa-mobile.fi) (Read error: Connection reset by peer)
  1014. # [21:27] <annevk> Wilto: a CG is a fine place for discussion, but if parallel discussion happens in other groups there's no real guarantee you'll be heard unfortunately
  1015. # [21:27] <MattWilcox> staydecent: I'm using CSS media. That example is pixels, but there is no reason at all why I couldn't have also used %, em, vh or anything else.
  1016. # [21:28] <staydecent> ahh, so how could that flexibility be used in a html attr or element?
  1017. # [21:28] <ShaneHudson> annevk: The CG was the first disccusion group/website I saw on the matter.. except blog psots of course
  1018. # [21:28] <MattWilcox> staydecent: that's the brilliance of MQ. I used pixels in the example because it's easier for people to figure out than introducing stuff like vh or em which they may be less familiar with using in that way.
  1019. # [21:29] <annevk> oh lol, that zeldman guy sure likes drama https://twitter.com/zeldman/status/201019688946384897
  1020. # [21:29] <MattWilcox> staydecent: we're proposing MQ syntax be added to HTML. That's how the <picture> tag works. There's nothing in my proposal that's different to the main <picture> one except I abstract the query away from the code block.
  1021. # [21:29] * Joins: barnabywalters (~barnabywa@host-78-149-39-243.as13285.net)
  1022. # [21:29] <ShaneHudson> annevk: lol
  1023. # [21:30] <staydecent> So, that syntax could be added to the <img set=""> attr?
  1024. # [21:30] <staydecent> *if* one decided to take that route...
  1025. # [21:30] <MattWilcox> I don't know. I can't see how the MQ syntax could be cleanly added into a singular attribute.
  1026. # [21:30] <ShaneHudson> Who proposed set anyway? I have not yet seen anyone who has agreed with it, and I had not heard of it before today
  1027. # [21:31] <annevk> Apple
  1028. # [21:31] <MattWilcox> imgset was from someone at Apple
  1029. # [21:31] <ShaneHudson> Ah, that explains it lol
  1030. # [21:31] <MattWilcox> Intended for CSS, and now being pushed into HTML
  1031. # [21:31] <MattWilcox> It's poor in both cases
  1032. # [21:31] <MattWilcox> But less poor in CSS
  1033. # [21:31] <MattWilcox> Still poor though.
  1034. # [21:31] <ShaneHudson> yeah the css version I mostly agree with, but html I don't
  1035. # [21:31] <annevk> I think it makes sense
  1036. # [21:31] <staydecent> From what I;ve gothered today: <picture> element is easier to read and write for developers, but the implementation within browsers is more complex than the set attr..
  1037. # [21:31] <MattWilcox> staydecent: I'd agree with that summary. And I think that's not a problem.
  1038. # [21:32] <barnabywalters> staydecent: that's my impression too
  1039. # [21:32] <zcorpan> for the record, multiple attributes would be fine from the "impl complexity" perspective
  1040. # [21:32] <annevk> for the case where you just want highres images <img src=lowres set="highres 2x"> is way easier than the alternative
  1041. # [21:32] <MattWilcox> As I've said: vendors only have to worry about doing hard work once. But once it's in HTML, that's millions of people stuck with that syntax, for life.
  1042. # [21:32] <ShaneHudson> Agreed, browser developers are very clever (as opposed to entry-level html) and it only needs to be implemented once
  1043. # [21:32] <MattWilcox> annevk: of course it is, because it's far more targeted and far less useful.
  1044. # [21:33] <zcorpan> MattWilcox: developers need to live with bugs in browsers
  1045. # [21:33] <MattWilcox> annevk: you're not making a fair comparison really.
  1046. # [21:33] <annevk> MattWilcox: did you see the extended version that also deals with width/height or is there some other use case?
  1047. # [21:33] <MattWilcox> zcorpan: bugs get fixed. syntac doesn't.
  1048. # [21:33] <MattWilcox> syntax
  1049. # [21:33] <annevk> MattWilcox: well you have to consider what is going to be the common case and see how that compares
  1050. # [21:33] <MattWilcox> annevk: so many other use cases!
  1051. # [21:34] <MattWilcox> annevk: I know the common case, it's not retina.
  1052. # [21:34] <annevk> MattWilcox: because trying to boil the ocean with a single feature generally does not work very well
  1053. # [21:34] <MattWilcox> annevk: Other ways people wish to implement responsive images include...
  1054. # [21:34] <annevk> see <object>, XML namespaces, ...
  1055. # [21:35] * Parts: JT__ (183fb7d0@gateway/web/freenode/ip.24.63.183.208)
  1056. # [21:35] <MattWilcox> annvek: ... NOT via pixels (layouts are often set in flexible units, and so are pictures) ...
  1057. # [21:35] <ShaneHudson> Speaking of retina... does anyone know a good way to actually test retina without a device?
  1058. # [21:35] <annevk> MattWilcox: yeah so just use SVG...
  1059. # [21:35] <MattWilcox> annevk: ... and responding to screen size is only done because it's a proxy for bandwidth. MQ's are aiming to include bandwidth sensors too. And then <picture> can use them.
  1060. # [21:36] <annevk> how would that work if you switch networks?
  1061. # [21:36] <barnabywalters> MattWilcox: yes, one of the appeals (to me) of the <picture> element is it's extensibility
  1062. # [21:36] <MattWilcox> annevk: SVG is not a raster format. Seriously, it is absolutely inapropriate for the majority of use cases. You can not SVG a photo. You can only SVG mathematically drawn images.
  1063. # [21:37] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
  1064. # [21:37] <shepazu> SVG ALL THE THINGS!!!!!
  1065. # [21:37] <annevk> MattWilcox: I guess I misunderstood what you meant by "NOT via pixels"
  1066. # [21:37] * Quits: cpearce (~cpearce@ip-118-90-120-55.xdsl.xnet.co.nz) (Ping timeout: 260 seconds)
  1067. # [21:37] <zcorpan> MattWilcox: as i've said, the browser is in a better position to know which image is appropriate (if it has information about the available images and their resolutions) than the author writing the MQ, even if MQ gets extended
  1068. # [21:37] <MattWilcox> annvek: that's an implementation detail - but the browser has a recent connection it can query the real throughput on all the time - the last requested asset :)
  1069. # [21:38] <MattWilcox> acorpan: No. The designer knows what is required to meet the requirements of the design. The browser does not.
  1070. # [21:38] <barnabywalters> I'm off for the moment (going to sleep on it). Bye!
  1071. # [21:39] * Quits: barnabywalters (~barnabywa@host-78-149-39-243.as13285.net) (Quit: Back to real life!)
  1072. # [21:39] <MattWilcox> Bye :)
  1073. # [21:39] <zcorpan> MattWilcox: so you care about the adaptive layout use case, basically? not the "save bandwidth"/"load page faster" use case?
  1074. # [21:39] <staydecent> zcorpan: Could developers avoid altering <picture><source> elms by listening to some Event?
  1075. # [21:39] <MattWilcox> annvek: and yeah, I mean using pixel in a MQ is not actually recommended - most responsive designs are not based on pixels. But the assets that get served certainly are pixel based.
  1076. # [21:40] <annevk> MattWilcox: the width/height proposal is not MQ based
  1077. # [21:40] <annevk> which I think is a plus really, not all of MQ makes sense here
  1078. # [21:40] <MattWilcox> zcorpan: I care about both, but the saving bandwidth is done via the design. Not via automated heuristics on the browser.
  1079. # [21:40] <annevk> and putting bandwidth testing in MQ seems certainly way complicated to author
  1080. # [21:40] <zcorpan> staydecent: browsers need to get the edge cases right even if developers could avoid it, because developers could also not avoid it, and on the web scale all edge cases will happen, and browsers must deal
  1081. # [21:41] <zcorpan> MattWilcox: ok. MQ is appropriate for the layout use case. I'm arguing it is *not* appropriate for the bandwidth use case
  1082. # [21:41] <MattWilcox> zcorpan: From the perspective of a designer the process goes like this: Detect the device size -> Design something to fit this device -> Implement this design as HTML/CSS/JS
  1083. # [21:42] <MattWilcox> zcorpan: all the bits that we talk about are the last bits in the stack. It's thought about backwards a lot of the time, and we end up making the tools we have dictate the designs that are applied. It's the wrong way.
  1084. # [21:42] <staydecent> zcorpan: I agree with that sentiment. But with my lack of knowledge, I find I often run into bugs in my scripts by not doing something in the right order or event.
  1085. # [21:43] <MattWilcox> zcorpan: the design is the final experience. Everything else is tooling to achieve the design.
  1086. # [21:43] <MattWilcox> zcorpan: and of course, a good design consideres the users context (device size, connection speed, etc).
  1087. # [21:43] <staydecent> zcorpan: My point being, it's already part of my practice to make sure I do things with proper timing/within proper events.
  1088. # [21:44] * Joins: smaug____ (~chatzilla@193-64-23-62-nat.elisa-mobile.fi)
  1089. # [21:45] <zcorpan> staydecent: not sure i follow how this relates to the topic at hand :)
  1090. # [21:45] <jarek> "SVG is not a raster format. Seriously, it is absolutely inapropriate for the majority of use cases. You can not SVG a photo."
  1091. # [21:45] <jarek> in other words: SVG is suitable for all kinds of graphics on the web except photos
  1092. # [21:45] <staydecent> zcorpan: RE: "browsers need to get the edge cases right even if developers could avoid it"
  1093. # [21:46] <jarek> I mean gradients, buttons, icons, overlays - all this should be done with SVG, not bitmaps (as it is today)
  1094. # [21:47] <jarek> it's sad that there are so many CSS3 fanboys, but nobody cares about SVG
  1095. # [21:48] <staydecent> jarek: do you have any recommneded links/libraries/examples/tutorials for creating those elements with SVG?
  1096. # [21:49] <shepazu> jarek: hey, I care about SVG! and I know 18 other people who do, too
  1097. # [21:49] <ShaneHudson> Do you have any examples of using SVG for those? I must admit I focus much more on css and don't do much with svg
  1098. # [21:49] <MattWilcox> Jarek: I have built websites for the last 8yrs, professionally, for various clients in various sectors with various companies. I can tell you that the vast majority of designed images are not achievable in SVG.
  1099. # [21:49] <shepazu> MattWilcox: that seems like a pretty broad claim
  1100. # [21:50] <MattWilcox> shepazu - look on some websites. Find me 5, just FIVE content images that are vectors. Now do the same but look for photo's.
  1101. # [21:51] <MattWilcox> shepazu: remember we're talking content images here, not site-design elements, which are applied via CSS. We're on about HTML. So, it's stuff that clients add to sites in their CMS's.
  1102. # [21:51] <shepazu> MattWilcox: http://yourlogicalfallacyis.com/burden-of-proof
  1103. # [21:51] <MattWilcox> shepazu: oh grow up.
  1104. # [21:52] <jarek> MattWilcox: with filter effects you can achieve most Photoshop effects
  1105. # [21:52] <shepazu> MattWilcox: http://yourlogicalfallacyis.com/ad-hominem
  1106. # [21:52] <MattWilcox> shepazu: it's not about effects. It's about content type.
  1107. # [21:52] <jarek> MattWilcox: also, gradient meshes are on the roadmap which will allow as to create photo-realistic artworks
  1108. # [21:52] <shepazu> MattWilcox: if it can be done in Illustrator, it can be done in SVG
  1109. # [21:52] <jamesr> SVG is not useful for all icons/buttons/etc
  1110. # [21:52] <jarek> staydecent: they problem with SVG is that we don't even have good authoring tools. Inkscape is a mess, Illustrator... :/
  1111. # [21:52] <MattWilcox> Yes, and most <img> content can not be donein illustraitor
  1112. # [21:53] <MattWilcox> OK, have a look at all img's on the following websites: http://www.flickr.com/
  1113. # [21:53] <shepazu> depends on your design aesthetic
  1114. # [21:53] <MattWilcox> http://en.wikipedia.org/wiki/Motor_racing#Motor_racing
  1115. # [21:53] <MattWilcox> NOT DESIGN. Content.
  1116. # [21:53] <ShaneHudson> shepazu: Design aesthetic has nothing to do with this at all... this is about use cases. SVG is brilliant for a few use cases but not for most
  1117. # [21:53] <MattWilcox> We are doing CONTENT images.
  1118. # [21:54] <MattWilcox> http://www.appliancesonline.co.uk/
  1119. # [21:54] <MattWilcox> http://dashes.com/anil/2011/07/if-your-websites-full-of-assholes-its-your-fault.html
  1120. # [21:54] <shepazu> MattWilcox: nobody was claiming that you should do raster images in SVG, jarek mentioned gradients, buttons, icons, overlays, and other UI elements
  1121. # [21:54] <MattWilcox> These are just some open tabs.
  1122. # [21:54] <MattWilcox> Look at the <img> in them
  1123. # [21:54] <MattWilcox> Almost none are possible in SVG
  1124. # [21:55] <staydecent> MattWilcox: Your ponint makes sense. SVG is a red-herring in this discussion.
  1125. # [21:55] <jamesr> and you frequently want different assets for icons at different resolutions (not just a simple scale up)
  1126. # [21:55] <MattWilcox> UI elements are perfect places for SVG. But UI elements are defined in CSS - they are not embedded assets.
  1127. # [21:55] <MattWilcox> Agreed.
  1128. # [21:55] <shepazu> diagrams, charts, infographics, etc. are also great uses of SVG
  1129. # [21:55] <MattWilcox> Those are not use cases applicable to the <img> tag, which is what we are discussing
  1130. # [21:56] * Joins: mdelcx (~mdelcx@70-89-52-242-smc-pa.hfc.comcastbusiness.net)
  1131. # [21:56] <mdelcx> hey all
  1132. # [21:56] <zcorpan> jamesr: http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-allow-you-to-optimize-svg-icons-for-several-sizes
  1133. # [21:56] * Joins: twisted` (~twisted@p5DDBB4BC.dip.t-dialin.net)
  1134. # [21:56] <shepazu> MattWilcox: well, that's what you were discussing… Jarek brought up another topic that the rest of us were discussing
  1135. # [21:56] <MattWilcox> Content images are <img> - the vast majority of all <img> throughout the web are added via some form of CMS, and are *not* vector based.
  1136. # [21:56] <ShaneHudson> shepazu: diagrams etc are perfect for svg, and most people that know of svg know what it is good for
  1137. # [21:57] <shepazu> and for <img> content that is a UI element, or is a digaram, chart, etc., SVG is reasonable for those use cases
  1138. # [21:57] <jarek> yeah, I did not mean that there should be no support for responsive images
  1139. # [21:58] <MattWilcox> To clarify: SVG is perfect for any vector. But you are not going to apply those as content images ( <img> ) 99% of the time, if only because you have to be a developer to know how to get them in. I don't know of any CMS that allows you to upload a vector image and that then outputs it *as* a vector.
  1140. # [21:58] * Quits: Druide_ (~Druid@p5B05D4AD.dip.t-dialin.net)
  1141. # [21:58] <MattWilcox> Agh, it's late and I must go!
  1142. # [21:58] <shepazu> I strongly believe that we need a responsive image mechanism for rasters
  1143. # [21:58] * Joins: rniwa (rniwa@nat/google/x-gadrdjkhnfpsdjdm)
  1144. # [21:58] <shepazu> s/believe/agree/
  1145. # [21:58] <MattWilcox> I think everyone singing of the same sheet to be honest, bar small nuances that don't matter too much
  1146. # [21:59] <staydecent> Must focus on work. Good discussion :)
  1147. # [21:59] <MattWilcox> Cheers all for the conversation and viewpoints :)
  1148. # [21:59] * Quits: staydecent (80bdcc0b@gateway/web/freenode/ip.128.189.204.11) (Quit: Page closed)
  1149. # [21:59] * Quits: MattWilcox (50e5df36@gateway/web/freenode/ip.80.229.223.54) (Quit: Page closed)
  1150. # [21:59] * Joins: adiabatic (~adiabatic@pool-74-100-20-107.lsanca.fios.verizon.net)
  1151. # [22:00] <mdelcx> I've been mulling this over today... has any thought been given to adding client "metadata" at the request level?
  1152. # [22:01] <mdelcx> handling the serving of assets using the application, rather than repurposing media queries and modifying the markup
  1153. # [22:01] <mdelcx> (in the client)
  1154. # [22:02] <mdelcx> if the client added headers to every request, it would be a snap for the application to handle it
  1155. # [22:02] <zcorpan> mdelcx: so basically conneg?
  1156. # [22:02] <zcorpan> mdelcx: i think someone has considered it and written an email on whatwg explaining why it's a bad idea
  1157. # [22:02] <mdelcx> zcorpan: i haven't been part of the conversation, so I'll have to take a look at that WG
  1158. # [22:03] <zcorpan> mdelcx: basically, it would result in more overhead for all websites, even if only a small fraction would use the information
  1159. # [22:04] <zcorpan> mdelcx: and it would increase finger printing
  1160. # [22:04] <adiabatic> I hear there's a new proposed syntax for responsive images or similar from Hixie that Zeldman doesn't like much. Does anyone know offhand where it might be the whatwg list archives? I'm not exactly sure what I should be plugging into Google to find it
  1161. # [22:04] <mdelcx> overhead, for sure
  1162. # [22:04] <mdelcx> zcorpan: fingerprinting would depend on what the client had access to send
  1163. # [22:05] <mdelcx> it shouldn't be any worse than a cookie
  1164. # [22:05] * Quits: saba (~foo@unaffiliated/saba) (Quit: leaving)
  1165. # [22:05] * Joins: danielfilho (~daniel@187.31.77.7)
  1166. # [22:06] <zcorpan> mdelcx: any new piece of information about the user increases finger printing
  1167. # [22:06] <zcorpan> mdelcx: even if one piece isn't "worse" than a cookie, taken together they easily can identify a single user
  1168. # [22:06] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  1169. # [22:06] <zcorpan> mdelcx: we want to minimize it as much as possible
  1170. # [22:06] <mdelcx> eh, I don't know if some client metadata and a cookie could identify a client
  1171. # [22:06] <mdelcx> but i see you point for sure
  1172. # [22:07] <adiabatic> Sure, but if you can piece together enough sufficiently weird client data…
  1173. # [22:07] <zcorpan> cookie isn't the only thing there is today :-)
  1174. # [22:07] <mdelcx> i know :)
  1175. # [22:07] * Quits: sarro (~sarro@i5E864E59.versanet.de) (Ping timeout: 248 seconds)
  1176. # [22:08] <adiabatic> Incidentally, is there a way to enumerate all the fonts that a user has on a system? I think I'm unique simply based on the fonts I have installed alone
  1177. # [22:09] <zcorpan> adiabatic: you can't enumerate them, but you can list lots of fonts, try to apply them and measure the text width to see if the font was applied or not
  1178. # [22:10] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Client Quit)
  1179. # [22:11] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
  1180. # [22:12] * Joins: chriscoyier (~Adium@c-98-210-101-207.hsd1.ca.comcast.net)
  1181. # [22:13] * Quits: chriscoyier (~Adium@c-98-210-101-207.hsd1.ca.comcast.net) (Client Quit)
  1182. # [22:13] * Joins: MikeSmith_ (~MikeSmith@s1106115.xgsspn.imtp.tachikawa.spmode.ne.jp)
  1183. # [22:14] * Joins: moo (miohtama@lakka.kapsi.fi)
  1184. # [22:14] * moo is now known as Guest33858
  1185. # [22:15] * Quits: MikeSmith (~MikeSmith@s1106027.xgsspn.imtp.tachikawa.spmode.ne.jp) (Ping timeout: 272 seconds)
  1186. # [22:16] * Joins: edwardbc_ (~edward.ba@186.176.193.20)
  1187. # [22:18] * Joins: MikeSmith (~MikeSmith@s1106083.xgsspn.imtp.tachikawa.spmode.ne.jp)
  1188. # [22:18] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
  1189. # [22:18] * Quits: edwardbc (~edward.ba@186.176.193.20) (Ping timeout: 245 seconds)
  1190. # [22:19] * Quits: MikeSmith_ (~MikeSmith@s1106115.xgsspn.imtp.tachikawa.spmode.ne.jp) (Ping timeout: 272 seconds)
  1191. # [22:25] * Joins: sarro (~sarro@i5E864E59.versanet.de)
  1192. # [22:32] * Joins: jcarbaugh (~jcarbaugh@216.59.106.66)
  1193. # [22:37] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  1194. # [22:39] * Quits: jcarbaugh (~jcarbaugh@216.59.106.66) (Ping timeout: 244 seconds)
  1195. # [22:40] <zcorpan> i feel like it's time for a new #csspubquiz but i can't think of anything. maybe i should start with html quizzes instead
  1196. # [22:41] * Quits: moo-_- (miohtama@lakka.kapsi.fi) (Remote host closed the connection)
  1197. # [22:42] * Quits: Guest33858 (miohtama@lakka.kapsi.fi) (Remote host closed the connection)
  1198. # [22:42] * Joins: bradee (~Adium@sjfw1-a.adobe.com)
  1199. # [22:42] * Joins: moo-_- (miohtama@lakka.kapsi.fi)
  1200. # [22:43] * Quits: moo-_- (miohtama@lakka.kapsi.fi) (Read error: Connection reset by peer)
  1201. # [22:43] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
  1202. # [22:44] * Joins: moo-_- (miohtama@lakka.kapsi.fi)
  1203. # [22:48] <benvie> re: fonts that's not even falling back on flash which *will* give you a full list of fonts
  1204. # [22:48] * Quits: drublic (~drublic@frbg-5f732145.pool.mediaWays.net) (Remote host closed the connection)
  1205. # [22:48] * Quits: cheron (~cheron@unaffiliated/cheron) (Quit: Leaving.)
  1206. # [22:49] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
  1207. # [22:50] * Quits: smaug____ (~chatzilla@193-64-23-62-nat.elisa-mobile.fi) (Ping timeout: 272 seconds)
  1208. # [22:55] * Joins: recur (~textual@c-67-180-21-195.hsd1.ca.comcast.net)
  1209. # [22:59] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
  1210. # [22:59] * Quits: recur (~textual@c-67-180-21-195.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
  1211. # [23:00] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
  1212. # [23:01] * Quits: snowfox (~benschaaf@50-77-199-197-static.hfc.comcastbusiness.net) (Quit: snowfox)
  1213. # [23:01] * Joins: recur (~textual@c-67-180-21-195.hsd1.ca.comcast.net)
  1214. # [23:02] * Joins: sarspazam_ (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  1215. # [23:02] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Read error: Connection reset by peer)
  1216. # [23:02] * sarspazam_ is now known as sarspazam
  1217. # [23:05] * Parts: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se)
  1218. # [23:05] * Quits: MacTed (~Thud@63.119.36.36)
  1219. # [23:06] * Quits: lorin (~alystair@108.162.155.35) (Ping timeout: 240 seconds)
  1220. # [23:08] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1221. # [23:08] * Joins: dave_levin (~dave_levi@74.125.59.65)
  1222. # [23:10] * Joins: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se)
  1223. # [23:12] <adiabatic> benvie: heh, one more reason why I'm glad the only Flash I have on my system is bundled with Chrome
  1224. # [23:14] * Quits: necolas (~necolas@8.25.195.26) (Remote host closed the connection)
  1225. # [23:15] <zcorpan> you're glad that flash is bundled with chrome? :-P
  1226. # [23:19] * Joins: nessy (~Adium@124-149-96-148.dyn.iinet.net.au)
  1227. # [23:22] * Joins: Ms2ger (~Ms2ger@91.181.124.114)
  1228. # [23:27] * Joins: othermaciej (~mjs@17.245.106.253)
  1229. # [23:29] * Joins: staydecent (80bdccf4@gateway/web/freenode/ip.128.189.204.244)
  1230. # [23:32] * Quits: Jayflux (~jay_knows@cpc1-dudl6-0-0-cust1981.wolv.cable.virginmedia.com) (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
  1231. # [23:37] * Joins: nonge (~nonge@p5B326716.dip.t-dialin.net)
  1232. # [23:37] * Quits: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  1233. # [23:52] * Quits: sarro (~sarro@i5E864E59.versanet.de)
  1234. # [23:54] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
  1235. # [23:55] * Quits: graememcc (~chatzilla@host86-162-163-170.range86-162.btcentralplus.com) (Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120310193349])
  1236. # [23:55] * Quits: Ms2ger (~Ms2ger@91.181.124.114) (Ping timeout: 272 seconds)
  1237. # [23:56] <benvie> but yeah the amount of vectors towards making a UID for people are multitude =D
  1238. # [23:59] * Joins: smaug____ (~chatzilla@193-64-20-193-nat.elisa-mobile.fi)
  1239. # Session Close: Sat May 12 00:00:00 2012

The end :)