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

Options:

  1. # Session Start: Tue May 15 00:00:00 2012
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  4. # [00:05] * Quits: tomasf (~tom@2002:55e5:dbde:0:b821:7ed1:5147:a7ef) (Quit: tomasf)
  5. # [00:09] <Velmont> So. The Common Crawls dataset, 50TB, 5 billion web pages. -- Are we sometimes using searches through that to see how much people are using stuff we'd want to change?
  6. # [00:10] * Joins: othermaciej (~mjs@17.244.9.246)
  7. # [00:11] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
  8. # [00:12] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
  9. # [00:12] <zcorpan> matjas: https://twitter.com/zcorpan/status/202156793277857794
  10. # [00:15] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  11. # [00:21] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  12. # [00:26] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  13. # [00:26] * Joins: isherman (isherman@nat/google/x-xblgydwaeazbrvzc)
  14. # [00:27] * Quits: necolas (~necolas@5ade1e67.bb.sky.com) (Remote host closed the connection)
  15. # [00:29] * Joins: shepazu (~shepazu@81.253.2.12)
  16. # [00:30] * Quits: twisted` (~twisted@p5DDBAB67.dip.t-dialin.net) (Ping timeout: 265 seconds)
  17. # [00:32] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
  18. # [00:35] * Joins: KevinMarks (~KevinMark@64.65.178.199)
  19. # [00:39] * Joins: cygri (~cygri@089-101-028170.ntlworld.ie)
  20. # [00:42] * Joins: Druide__ (~Druid@p5B05C14C.dip.t-dialin.net)
  21. # [00:44] * Quits: Druide_ (~Druid@p5B137EE6.dip.t-dialin.net) (Ping timeout: 265 seconds)
  22. # [00:44] * jonlee is now known as jonlee|afk
  23. # [00:47] <zcorpan> Hixie: you need to fire 'error' when the fetch fails (srcset)
  24. # [00:48] <Velmont> zcorpan: Where are you reading?
  25. # [00:48] <zcorpan> Velmont: http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#attr-img-srcset
  26. # [00:51] <Velmont> zcorpan: Cool. Sending me to the benchmark page :P
  27. # [00:51] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  28. # [00:51] <zcorpan> at least without running scripts :-)
  29. # [00:51] <Velmont> Oh, it was not as slow as before now. Opera must have fixed a bug or something.
  30. # [00:51] <TabAtkins> Hixie: Why are you making up new units for that?
  31. # [00:53] * jonlee|afk is now known as jonlee
  32. # [00:56] * Joins: onar (~onar@17.216.36.168)
  33. # [00:56] * Quits: onar (~onar@17.216.36.168) (Client Quit)
  34. # [00:56] * Joins: onar (~onar@17.216.36.168)
  35. # [00:57] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
  36. # [00:57] <Hixie> zcorpan: why?
  37. # [00:57] <Hixie> TabAtkins: they're not units, just ways to distinguish which is present
  38. # [00:58] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
  39. # [00:58] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Read error: Connection reset by peer)
  40. # [00:58] <zcorpan> Hixie: you fire load if it's successful. why not error?
  41. # [00:58] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
  42. # [00:58] <Hixie> zcorpan: nothing happens if it's not successful
  43. # [00:58] <Hixie> zcorpan: so why bother telling anyone?
  44. # [00:58] <Hixie> zcorpan: (think of a case like you've gone offline and then resize the window)
  45. # [00:59] <Hixie> (i originally wanted to use another event if the image changed)
  46. # [00:59] <zcorpan> Hixie: hmm. dunno. maybe it's better to just emit a message to the error console...
  47. # [01:00] <Hixie> that's certainly reasonable
  48. # [01:01] * Joins: nessy (Adium@nat/google/x-tigiucgjejqytoey)
  49. # [01:02] <othermaciej> is the use of "breakpoint" in that one proposal a common term of art in web design?
  50. # [01:02] <othermaciej> or design in general?
  51. # [01:03] <TabAtkins> othermaciej: I've heard it commonly, though this could be due to a twitter bubble around me.
  52. # [01:03] <othermaciej> I keep imagining stopping in gdb
  53. # [01:03] <Velmont> Hixie: Actually, why having w and h at all? I mean, do you mean you want to be able to change the size of the picture (and thus it's ratio) and not only resolution? writing 800w and 1600w is certainly nice syntax, as the 0.-numbers can get unweildy. But someone can do <img src=pic.jpg width=800 height=600 srcset="mypic@2x.jpg 2x, strangepic.jpg 200w 200h"> then. What would that actually entail?
  54. # [01:03] * Joins: MikeSmith (~MikeSmith@81.253.8.113)
  55. # [01:03] <Hixie> i don't understand the question
  56. # [01:04] <TabAtkins> Velmont: That would mean that you'd only consider strangepic at all when the screen is smaller than 200px wide and tall.
  57. # [01:04] <Hixie> but maybe it's better if i just reply to the zillions of e-mails already on the list
  58. # [01:04] <Hixie> rather than starting yet another conversation here :-)
  59. # [01:04] * Joins: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  60. # [01:04] <Velmont> Hixie: hehe :] I'm in those.
  61. # [01:04] <TabAtkins> The 0w/0h stuff filters the list, and the UA then decides among the rest which to download based on its own heuristics and the presented resolution data.
  62. # [01:04] * Parts: cygri (~cygri@089-101-028170.ntlworld.ie)
  63. # [01:05] <TabAtkins> From a layout perspective, resolution only has an effect on the intrinsic size of an image.
  64. # [01:05] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Ping timeout: 260 seconds)
  65. # [01:05] <Velmont> TabAtkins: Yes, -- I'm asking if it would be allowed to change height×width ratio in srcset.
  66. # [01:05] <TabAtkins> If you set @width and @height, sending a 32dpi versus a 192dpi image is identical, except that one has more detail.
  67. # [01:05] <TabAtkins> Velmont: It doesn't change the ratio. You might misunderstand what the w/h numbers are doing.
  68. # [01:06] <Velmont> Ah.
  69. # [01:06] <TabAtkins> They're equivalent to using a max-width/height Media Query.
  70. # [01:06] <Velmont> It's not talking about the picture. It's actually a viewport mediaquery hint?
  71. # [01:07] <Velmont> Hmmm. Okay. I thought normal.jpg (800x600), then hd@2.jpg 2x, hd@2.jpg 800w 600h would be equal.
  72. # [01:07] <Velmont> That's making that usage clearer, yes. :P
  73. # [01:07] <TabAtkins> Is there a reason for the strange spacing in your last line?
  74. # [01:08] <TabAtkins> (I'm wondering if I'm missing some characters that should be there.)
  75. # [01:08] <Velmont> TabAtkins: Heh, no... I really wanted to \n\tEXAMPLEHERE
  76. # [01:09] <TabAtkins> Ah, kk.
  77. # [01:10] * Quits: othermaciej (~mjs@17.244.9.246) (Quit: othermaciej)
  78. # [01:11] <TabAtkins> Hixie: Yeah, just posting to the list would be good. I'd want to see if there are good use-cases for MQ-in-general, or if the explicit restriction to the max-width/height MQs are good enough.
  79. # [01:11] <TabAtkins> I suspect they'd be good enough, based on what I've heard of use-cases so far.
  80. # [01:12] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
  81. # [01:13] <Velmont> Is even having both max-height max-width really necessary? Having one number (the largest) and treating it as a bounding-box would solve the cases I think of.
  82. # [01:14] <Velmont> The smartphone probably wants to fetch one it can show in portrait and landscape anyway.
  83. # [01:14] <TabAtkins> I dunno!
  84. # [01:15] <Velmont> And I guess people are not using 2048x200 pictures on a real device. -- Or maybe they are. Hmm, headers might be.
  85. # [01:15] * Quits: mven (~mven__@169.241.49.57) (Ping timeout: 260 seconds)
  86. # [01:15] <TabAtkins> Yup, that's a use-case.
  87. # [01:15] <Velmont> I should think before I speak.
  88. # [01:15] <TabAtkins> ^_^
  89. # [01:15] <Velmont> Will sound so much wiser.
  90. # [01:15] <Velmont> :D
  91. # [01:16] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  92. # [01:16] * Quits: danheberden (~danheberd@li225-35.members.linode.com) (Quit: oh noes)
  93. # [01:17] <zewt> fetching two images for every picture is expensive on latent, bandwidth-quotad devices, so i'm guessing few phones would want to do that anyway (at least today)
  94. # [01:19] * Joins: danheberden (~danheberd@li225-35.members.linode.com)
  95. # [01:19] * Quits: danheberden (~danheberd@li225-35.members.linode.com) (Excess Flood)
  96. # [01:20] * Joins: danheberden (~danheberd@li225-35.members.linode.com)
  97. # [01:23] <Velmont> zewt: Fetching two images? No, I was only talking about actually fetching one that will fit both portrait and landscape. So if you're in portrait, you overestimate, and pick a slightly bigger picture that'll also use all your pixels in landscape. Hence you only need to fetch that image once, in case the user switches to landscape.
  98. # [01:23] <Velmont> zewt: So you are actually hindering an extra image fetch here.
  99. # [01:25] <Velmont> zewt: I should've written "UA wants to fetch _one_ image that it is big enough to use in both portrait and landscape".
  100. # [01:28] * Quits: twisted` (~twisted@p5DDB9484.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
  101. # [01:33] * Joins: othermaciej (~mjs@17.245.104.240)
  102. # [01:35] * Joins: seventh (seventh@69.80.107.71)
  103. # [01:37] <zewt> gluh
  104. # [01:38] <zewt> it needs to not be possible for sites to prevent you from pasting into form fields
  105. # [01:38] <zewt> sites that stop you from copying and pasting your email address into confirm fields need to burn in a ditch
  106. # [01:38] * Joins: mkanat (mkanat@nat/google/x-judurruwkwigdzov)
  107. # [01:38] * Quits: othermaciej (~mjs@17.245.104.240) (Quit: othermaciej)
  108. # [01:39] <TabAtkins> Yus.
  109. # [01:39] <zcorpan> http://xkcd.com/970/
  110. # [01:39] <zewt> "we will deliberately waste your time"
  111. # [01:40] * Joins: othermaciej (~mjs@17.245.104.240)
  112. # [01:40] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Quit: The computer fell asleep)
  113. # [01:40] * Joins: KevinMarks (~KevinMark@64.65.178.199)
  114. # [01:41] * Quits: seventh (seventh@69.80.107.71) (Remote host closed the connection)
  115. # [01:42] * Quits: drublic (~drublic@frbg-5f730166.pool.mediaWays.net) (Remote host closed the connection)
  116. # [01:43] * Joins: seventh (seventh@69.80.107.71)
  117. # [01:45] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Ping timeout: 245 seconds)
  118. # [01:45] <TabAtkins> Even worse are those that do this for your password confirmation field. I don't *ever* type my passwords if I can avoid it - they get generated by a hasher.
  119. # [01:48] <zcorpan> or where there are restrictions on the password such that you can't pick anything sane, like with bredbandsbolaget
  120. # [01:48] * Joins: richwild (560acfe2@gateway/web/freenode/ip.86.10.207.226)
  121. # [01:48] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
  122. # [01:49] <zewt> in general password rules just make everyon capitalize their password and add "1"
  123. # [01:49] <zewt> they're a pretty good sign that whoever's running the site doesn't think things through
  124. # [01:49] <TabAtkins> Yes.
  125. # [01:49] <richwild> Yes1
  126. # [01:49] <zcorpan> which, iirc, requires a length between 6 and 8 chars, requires at least one uppercase letter, and at least two numbers, and no punctuation and no non-ascii
  127. # [01:50] <zewt> well non-ascii is asking for trouble, heh
  128. # [01:50] <TabAtkins> max-length password requirements just *infuriate* me. Out of all the things you could require, that's the one that's not defensible in *any* way.
  129. # [01:50] <zewt> (re: normalization)
  130. # [01:50] <Philip`> TabAtkins: Maybe they're storing your password in a fixed-width database field
  131. # [01:50] <TabAtkins> Unless they're not hashing your password before storing (which would make it fixed-length).
  132. # [01:51] <TabAtkins> Philip`: See what I just said. ^_^
  133. # [01:51] <zcorpan> yeah i couldn't even use a normal word, capitalize it, and add two numbers at the end, because it ended up being longer than 8 chars
  134. # [01:52] <TabAtkins> My password generator, at least, has the ability to *almost* satisfy those requirements.
  135. # [01:52] <TabAtkins> I can force it to generate an 8-char password with at least one uppercase letter, number, and punctuation. I just can't do *2* numbers, so I'd have to hope it happens to generate two.
  136. # [01:52] <Philip`> Banks here tend to ask for random subsets ("Enter the 2nd, 5th and 8th characters of your password" etc) so they can't be storing just a hashed password
  137. # [01:53] <TabAtkins> Philip`: Those banks are idiots. :/
  138. # [01:53] <TabAtkins> I mean, if you just ask for three characters, that's a pretty decent chance of randomly guessing correctly.
  139. # [01:53] <richwild> What do you think they must be storing?
  140. # [01:53] <jamesr_> TabAtkins: they store a hash of each character!
  141. # [01:54] <TabAtkins> jamesr_: Brilliant!
  142. # [01:54] <Philip`> TabAtkins: They ask for 3 digits of the 4-digit PIN too
  143. # [01:54] <TabAtkins> ...
  144. # [01:54] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Quit: tantek)
  145. # [01:54] <Philip`> (I assume they're just trying to reduce the effectiveness of keyloggers by not making you type in all your login details at once, so attackers would have to log multiple logins)
  146. # [01:55] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
  147. # [01:57] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Client Quit)
  148. # [01:59] * Joins: ukai (ukai@nat/google/x-lbibgcnkmjnxsvuc)
  149. # [01:59] <TabAtkins> Shrug. The right solution to that is a fob that provides OTPs. :/
  150. # [01:59] <Hixie> which, ironically, is also somewhat common in europe
  151. # [01:59] <Hixie> natwest has both sent me hardware and requires me to log in as Philip` describes
  152. # [02:01] <TabAtkins> lolwut
  153. # [02:03] <Philip`> I think they require the card-reading hardware device just for relatively high risk operations, like setting up a new payee
  154. # [02:03] <Hixie> i don't think i've ever had to end up using it
  155. # [02:03] <Philip`> presumably on the assumption that most people would be unwilling to put up with the inconvenience of having to use it just for checking their balance or paying regular bills
  156. # [02:04] <Hixie> it'd be a hell of a lot less inconvenient to swipe my card and get a number than it is to have to decode my password to figure what damn digit they want
  157. # [02:09] <jamesr> zewt, in multi-monitor setups you have to pick (fairly arbitrarly) a device to vsync to
  158. # [02:12] * jernoble is now known as jernoble|afk
  159. # [02:13] <jamesr> the flow control situation is interesting for offscreen stuff
  160. # [02:14] * Quits: ap (~ap@2620:149:4:1b01:c4ea:70e6:9e8a:fecf) (Quit: ap)
  161. # [02:24] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
  162. # [02:25] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
  163. # [02:27] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Read error: Connection reset by peer)
  164. # [02:27] * Joins: tantek (~tantek@ip-64-134-223-52.public.wayport.net)
  165. # [02:35] * Quits: jsbell (jsbell@nat/google/x-cuowikpwfmtqkizd) (Quit: There's no place like home...)
  166. # [02:38] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  167. # [02:38] * Quits: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Read error: Connection reset by peer)
  168. # [02:39] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
  169. # [02:42] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
  170. # [02:48] <zewt> jamesr: well, you either have to explicitly say which element to use (which only webkit supports, unless that page is out of date), or sync vsync together (no idea if that happens in practice)
  171. # [02:49] <jamesr_> everything in a page is vsync'd together
  172. # [02:49] <zewt> not if the page spans monitors
  173. # [02:49] <jamesr_> doesn't matter
  174. # [02:50] <jamesr_> everything within a page is rendered at the same time
  175. # [02:50] <zewt> it's not rendering, it's backbuffer flipping
  176. # [02:50] <jamesr_> that's not a concern of the web platform. the backbuffer is prepared for everything in the page at the same time
  177. # [02:50] <zewt> rendering happens when it happens (with webgl)
  178. # [02:50] * Quits: tantek (~tantek@ip-64-134-223-52.public.wayport.net) (Quit: tantek)
  179. # [02:50] <zewt> not with webgl it isn't
  180. # [02:51] <jamesr_> sure it is
  181. # [02:51] <zewt> it isn't? heh
  182. # [02:51] <jamesr_> draw ops in webgl to the webgl backbuffer happen whenever
  183. # [02:51] <jamesr_> those are resolved/flipped/copied into the rest of the system as an independent step (not observable from the web directly)
  184. # [02:51] <zewt> then it flips to the front buffer on monitor vsync, which depends on which monitor the element happens to be on (unless it spans monitors, in which case all bets are off, most likely)
  185. # [02:52] <jamesr_> no
  186. # [02:52] <zewt> the point is that you want to begin rendering right after vsync, and that depends on the monitor
  187. # [02:52] <jamesr_> it has to go to at least one intermediate buffer
  188. # [02:52] <jamesr_> and nothing at all depends on which monitor an element lands on
  189. # [02:53] <zewt> these are all implementation details; what matters is when you want to begin rendering, which is as close after vsync as possible
  190. # [02:53] <jamesr_> yes. in the multimonitor case, just pick some monitor and go
  191. # [02:54] <jamesr_> i've heard of some non-web systems picking the monitor with the largest area of intersection with the window
  192. # [02:54] <zewt> not some monitor; you want to pick the monitor the element is on, whenever possible
  193. # [02:54] <jamesr_> no
  194. # [02:54] <zewt> can you say something more informative than "no"? heh
  195. # [02:54] <jamesr_> it doesn't make any difference what monitor the element is on
  196. # [02:54] <zewt> why would you ever not do that?
  197. # [02:54] <jamesr_> because individual elements are not flipped independently
  198. # [02:54] <jamesr_> the whole buffer is prepared at once
  199. # [02:54] <jamesr_> and then made available to every monitor
  200. # [02:55] <zewt> how would you know that? heh
  201. # [02:55] <zewt> it's an implementation detail, and a good implementation would sync as close to each monitor as possible
  202. # [02:55] <jamesr_> i know that because i'm an implementor?
  203. # [02:56] <zewt> of every implementation ever?
  204. # [02:56] <jamesr_> an implementation as you describe would be infeasible
  205. # [02:56] <zewt> how so? you flip the region associated with the webgl context (which in a great many cases is the entire window) on vsync for the monitor it's on
  206. # [02:56] * Quits: MikeSmith (~MikeSmith@81.253.8.113) (Read error: Connection reset by peer)
  207. # [02:56] * Joins: MikeSmith (~MikeSmith@81.253.8.113)
  208. # [02:57] <zewt> (clearly someone at webkit agrees, if their requestAnimationFrame takes an element)
  209. # [02:57] <jamesr_> see this is where it's hard to take you seriously. i wrote the element param for webkit's RAF, and the spec text, and deleted that code
  210. # [02:58] <jamesr_> you can't cite a nebulous "someone at webkit" against me when that someone is me
  211. # [02:58] <zewt> okay i don't feel like a condescending conversation right now
  212. # [02:58] <zewt> later
  213. # [02:58] <jamesr_> it really gets my goat when people say "implementations do X or could easily do X" when that's clearly not true
  214. # [02:59] <zewt> uh huh
  215. # [03:00] * jonlee is now known as jonlee|afk
  216. # [03:06] * Quits: edwardbc (~edward.ba@186.176.193.20) (Ping timeout: 252 seconds)
  217. # [03:12] * Quits: othermaciej (~mjs@17.245.104.240) (Quit: othermaciej)
  218. # [03:13] * Quits: pablof (~pablof@144.189.101.1) (Quit: ^z)
  219. # [03:17] * Joins: macpherson (~macpherso@2401:fa00::ea06:88ff:fecc:9412)
  220. # [03:23] * Quits: myndzi (myndzi@c-67-168-184-168.hsd1.wa.comcast.net) (Ping timeout: 272 seconds)
  221. # [03:26] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
  222. # [03:27] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
  223. # [03:41] * Quits: sicking (~chatzilla@nat/mozilla/x-amcbbrxrrwtkleao) (Remote host closed the connection)
  224. # [03:42] * Joins: ehsan (~ehsan@209.20.29.228)
  225. # [03:51] * Joins: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
  226. # [03:53] * Quits: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
  227. # [03:57] * Quits: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.88.2-rdmsoft [XULRunner 12.0/20120420145725])
  228. # [04:07] * Quits: jamesr_ (jamesr@nat/google/x-tspymionlpbvsbtg) (Quit: jamesr_)
  229. # [04:08] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
  230. # [04:09] * Joins: tantek (~tantek@mf10536d0.tmodns.net)
  231. # [04:10] * Joins: ehsan (~ehsan@209.20.29.228)
  232. # [04:12] * Joins: tomasf (~tom@2002:55e5:dbde:0:b9fc:8df3:2f62:a08f)
  233. # [04:36] * Joins: espadrine (~thaddee_t@63-235-13-3.dia.static.qwest.net)
  234. # [04:38] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
  235. # [04:43] * Quits: tantek (~tantek@mf10536d0.tmodns.net) (Quit: tantek)
  236. # [04:54] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  237. # [05:01] * ojan_away is now known as ojan
  238. # [05:04] * ojan is now known as ojan_away
  239. # [05:10] * jonlee|afk is now known as jonlee
  240. # [05:26] * Joins: niftylettuce (u2733@gateway/web/irccloud.com/x-piarwytdtjthqwqq)
  241. # [05:36] * Joins: [[zzz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net)
  242. # [05:39] * Quits: [[zz]] (~q@node-1as9.pool-125-25.dynamic.totbb.net) (Ping timeout: 245 seconds)
  243. # [05:44] * [[zzz]] is now known as [[zz]]
  244. # [06:06] * Joins: temp01 (~temp01@unaffiliated/temp01)
  245. # [06:23] * Quits: shepazu (~shepazu@81.253.2.12) (Ping timeout: 252 seconds)
  246. # [06:41] * Quits: MikeSmith (~MikeSmith@81.253.8.113) (Ping timeout: 272 seconds)
  247. # [06:42] * Joins: silentimp (~silentimp@77.87.42.24)
  248. # [06:43] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
  249. # [06:56] * Quits: silentimp (~silentimp@77.87.42.24) (Quit: silentimp)
  250. # [07:22] * Joins: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  251. # [07:24] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 244 seconds)
  252. # [07:25] * Quits: richwild (560acfe2@gateway/web/freenode/ip.86.10.207.226) (Ping timeout: 245 seconds)
  253. # [07:25] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Ping timeout: 244 seconds)
  254. # [07:25] * Quits: danja (~danny@host94-204-dynamic.13-79-r.retail.telecomitalia.it) (Ping timeout: 244 seconds)
  255. # [07:26] * Joins: danja (~danny@host94-204-dynamic.13-79-r.retail.telecomitalia.it)
  256. # [07:26] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
  257. # [07:27] * Quits: nephyrin (~nephyrin@v-1025.fw1.scl3.mozilla.net) (Ping timeout: 244 seconds)
  258. # [07:27] * Joins: nephyrin (~nephyrin@v-1025.fw1.scl3.mozilla.net)
  259. # [07:28] * Joins: stalled (~stalled@unaffiliated/stalled)
  260. # [07:29] * Joins: Areks (~Areks@rs.gridnine.com)
  261. # [07:30] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
  262. # [07:38] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
  263. # [07:45] * Joins: mishunov (~spliter@142-131-95-178.pool.ukrtel.net)
  264. # [07:48] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
  265. # [07:58] * Quits: KDN (~kdn@90.149.135.254) (Quit: KDN)
  266. # [07:59] * Quits: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr_)
  267. # [07:59] <AryehGregor> "Wait until any invocations of this algorithm that had the same method context, that started before this one, and whose timeout is equal to or less than this one's, have completed."
  268. # [08:00] <AryehGregor> "equal to"?
  269. # [08:00] <AryehGregor> Oh, I guess everything runs single-threaded, so it's not a deadlock.
  270. # [08:00] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 272 seconds)
  271. # [08:03] * Joins: niloy (~niloy@61.12.96.242)
  272. # [08:06] * Joins: fishd (darin@nat/google/x-umaxkmblauxytytp)
  273. # [08:15] * Parts: mishunov (~spliter@142-131-95-178.pool.ukrtel.net)
  274. # [08:20] * Quits: stalled (~stalled@unaffiliated/stalled) (Read error: Connection reset by peer)
  275. # [08:22] * Joins: stalled (~stalled@unaffiliated/stalled)
  276. # [08:24] <matjas> in which cases must `>` be escaped in HTML? I can only think of unquoted attribute values
  277. # [08:24] <AryehGregor> matjas, this should have all the rules: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing I think you're probably right.
  278. # [08:26] <AryehGregor> Maybe in <textarea> if preceded by "</textarea", and likewise for <title>?
  279. # [08:27] <AryehGregor> That's not relevant if you're really asking "which characters do I have to escape?" and are already escaping <.
  280. # [08:29] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  281. # [08:29] * Quits: padenot (~paul@li421-75.members.linode.com) (Quit: WeeChat 0.3.5)
  282. # [08:31] <AryehGregor> There are other cases where ">" isn't allowed, but it can't be escaped in those cases.
  283. # [08:31] <AryehGregor> Like attribute names, or certain configurations within <script>/<style>/comments.
  284. # [08:33] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 245 seconds)
  285. # [08:34] <matjas> AryehGregor: thanks for confirming. that’s indeed the use case here, escaping HTML (and `<` is being escaped)
  286. # [08:35] * Quits: niloy (~niloy@61.12.96.242) (Remote host closed the connection)
  287. # [08:35] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  288. # [08:35] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  289. # [08:37] * Quits: JohnAlbin_zzzzzz (~JohnAlbin@114-36-33-17.dynamic.hinet.net) (Quit: HTTP/1.1 404 JohnAlbin Not Found)
  290. # [08:38] * Quits: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net) (Ping timeout: 252 seconds)
  291. # [08:38] * Joins: padenot (~paul@li421-75.members.linode.com)
  292. # [08:40] * Joins: niloy (~niloy@61.12.96.242)
  293. # [08:40] * Joins: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net)
  294. # [08:43] * Joins: drublic (~drublic@frbg-5d84f2b2.pool.mediaWays.net)
  295. # [08:45] * Joins: KDN (~kdn@pc173-96.hiof.no)
  296. # [08:50] * Quits: decadance (~decadance@204.93.201.197) (Read error: Operation timed out)
  297. # [08:50] * Joins: PalleZingmark (~Adium@217.13.228.226)
  298. # [08:51] * Joins: decadance (~decadance@204.93.201.197)
  299. # [08:52] * Quits: nessy (Adium@nat/google/x-tigiucgjejqytoey) (Quit: Leaving.)
  300. # [08:58] * Joins: Ms2ger (~Ms2ger@91.181.123.95)
  301. # [09:07] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  302. # [09:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  303. # [09:17] * Joins: KevinMarks (~KevinMark@64.65.178.199)
  304. # [09:17] * Joins: Kolombiken (~Adium@217.13.228.226)
  305. # [09:18] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
  306. # [09:18] * Joins: pyrsmk (~pyrsmk@202.182.141.88.rev.sfr.net)
  307. # [09:19] * Joins: nessy (~Adium@49.178.1.98)
  308. # [09:20] * Quits: KDN (~kdn@pc173-96.hiof.no) (Remote host closed the connection)
  309. # [09:20] * Joins: KDN (~kdn@2001:700:a00:ff21:3d71:5a2a:c16e:4d48)
  310. # [09:25] * Quits: Guest31456 (~jondong@123.126.22.58) (Ping timeout: 272 seconds)
  311. # [09:25] * Quits: kinetik (~kinetik@121.98.132.55) (Ping timeout: 255 seconds)
  312. # [09:25] * Joins: spliter_ (~spliter@16-98-112-92.pool.ukrtel.net)
  313. # [09:26] * Parts: spliter_ (~spliter@16-98-112-92.pool.ukrtel.net)
  314. # [09:26] * Joins: kinetik (~kinetik@121.98.132.55)
  315. # [09:26] * Joins: jondong (~jondong@123.126.22.58)
  316. # [09:26] * jondong is now known as Guest32383
  317. # [09:32] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net) (Read error: Connection reset by peer)
  318. # [09:33] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
  319. # [09:33] * Quits: nessy (~Adium@49.178.1.98) (Ping timeout: 252 seconds)
  320. # [09:37] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
  321. # [09:39] <Hixie> phew
  322. # [09:39] <Hixie> finally caught up with the tsunami
  323. # [09:48] * Ms2ger didn't hear about a tsunami in the Bay Area
  324. # [09:48] <Hixie> the responsive tsunami
  325. # [09:48] <Hixie> been replying to that thread for like a week now
  326. # [09:48] <Ms2ger> Oh, have fun with that :)
  327. # [09:48] <Hixie> every night i'm almost done
  328. # [09:48] <Hixie> i come back the next morning
  329. # [09:48] <Hixie> and it's run away again
  330. # [09:48] <Hixie> but i finally caught up!
  331. # [09:48] * Quits: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net) (Read error: Operation timed out)
  332. # [09:49] <Ms2ger> I would suggest fixing some bugs instead ;)
  333. # [09:49] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
  334. # [09:49] <Hixie> bugs are on hold til i deal with mail
  335. # [09:50] <Hixie> which is a far bigger pile right now
  336. # [09:50] <Hixie> though i see from the chart that you've done a good amount of work on the bugs yourself!
  337. # [09:50] <Hixie> nice!
  338. # [09:51] <Ms2ger> Saddening how much junk accumulated, really :)
  339. # [09:51] <Hixie> heh
  340. # [09:54] * Joins: necolas (~necolas@5ade1e67.bb.sky.com)
  341. # [09:55] * Joins: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net)
  342. # [09:55] * Joins: Necrathex (~Necrathex@82-170-160-25.ip.telfort.nl)
  343. # [09:55] * Joins: tomasf_ (~tomasf@77.72.97.5.c.fiberdirekt.net)
  344. # [09:59] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  345. # [09:59] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  346. # [09:59] <ShaneHudson> How do we go about removing srcset from the living spec? Both this irc channel and the community group were unanimous that srcset is the wrong way to go.
  347. # [10:00] <matjas> are the spec short URLs documented anywhere? if not I’ll take a stab at writing it up
  348. # [10:00] <matjas> e.g. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset can be http://whatwg.org/html/embedded-content-1.html#attr-img-srcset or even http://whatwg.org/html#attr-img-srcset
  349. # [10:01] <ShaneHudson> For which one?
  350. # [10:02] <matjas> ShaneHudson: the multi-page and one-page versions of the HTML living standard
  351. # [10:02] <ShaneHudson> Ah, I have only seen the multi page so far
  352. # [10:03] <matjas> Hixie: heads up, http://www.whatwg.org/specs/ is missing a </strong>
  353. # [10:04] * jonlee is now known as jonlee|afk
  354. # [10:06] * Quits: kinetik (~kinetik@121.98.132.55) (Ping timeout: 250 seconds)
  355. # [10:06] * Joins: kinetik (~kinetik@121.98.132.55)
  356. # [10:09] * Quits: mkanat (mkanat@nat/google/x-judurruwkwigdzov) (Quit: Ex-Chat)
  357. # [10:09] <ShaneHudson> this is the first time I have got involved with the spec, so if there is anything I should be doing to help, let me know please!
  358. # [10:09] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
  359. # [10:12] * Joins: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net)
  360. # [10:14] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
  361. # [10:16] * Quits: necolas (~necolas@5ade1e67.bb.sky.com) (Remote host closed the connection)
  362. # [10:17] <odinho> ShaneHudson: "Both this irc channel and the community group were unanimous that srcset is the wrong way to go.". Really? I've not seen that in this IRC-channel. And I've been here and discussed it. :-)
  363. # [10:18] * Joins: remysharp (u4345@gateway/web/irccloud.com/x-sjhqsgmhzfdkbxbt)
  364. # [10:18] <ShaneHudson> Yes, I asked everyone about 5pm GMT two days ago I believe
  365. # [10:19] <ShaneHudson> about 20 people said that they did not like srcset, and nobody said otherwise
  366. # [10:19] * Joins: gwicke (~gabriel@212.255.28.33)
  367. # [10:19] <odinho> ShaneHudson: What you do is reply to Hixie's email that came in just half an hour ago.
  368. # [10:19] <ShaneHudson> I am still reading it, it is extremeley long
  369. # [10:20] <odinho> ShaneHudson: Well, popularity contests is not the best way for specs to be made. Technical discussion and merit, however, is.
  370. # [10:21] <ShaneHudson> True of course, but have you not seen the discussions on the community group?
  371. # [10:21] <[tm]> annevk: I need to get the URL spec ready for FPWD publication, but having some trouble figuring out what anolis switches I need to flip to get it W3C-styled
  372. # [10:21] <kennyluck> ShaneHudson, you can join the W3C HTML WG and write a change proposal.
  373. # [10:21] <ShaneHudson> I will reply to Hixie's email later today, so that I do not rush it
  374. # [10:22] <odinho> ShaneHudson: Well, I get lots of email. -- I have not read it lately (I did when it was announced some time ago). Anyway, we'll be hearing it on WHATWG later, which has a much bigger audience and where most people read and listens in.
  375. # [10:22] <Ms2ger> [tm], have a look at the DOM4 Makefile ;)
  376. # [10:22] <ShaneHudson> kennyluck: Ah I am able to join the WG? Was not sure how exclusive it was, I was under the impression I could only join the CG
  377. # [10:23] <Ms2ger> ShaneHudson, joining the HTML WG is generally a waste of time
  378. # [10:23] <odinho> ShaneHudson, kennyluck: No need joining HTML WG... Better to just take it up in WHATWG where it's discussed.
  379. # [10:23] <Ms2ger> If you've got technical arguments for your suggestions, you will find the WHATWG list is enough for you
  380. # [10:24] <odinho> Ms2ger: Heh, implictly saying what the other one is used for?
  381. # [10:25] <kennyluck> ShaneHudson, well, this is a step by step instruction → http://www.paciellogroup.com/blog/2011/12/how-you-can-join-the-w3c-html5-working-group-in-4-easy-steps/
  382. # [10:26] <kennyluck> I am not going to say if that's a waste of time or not. Other people will tell you. :p
  383. # [10:26] <odinho> ShaneHudson: I'm seconding Ms2ger by the way.
  384. # [10:26] <jgraham> Please don't fork the discussion into to a third group
  385. # [10:27] <kennyluck> That I agree. THough writing a change proposal is another thing.
  386. # [10:27] <Ms2ger> A bigger waste of time? :)
  387. # [10:27] <kennyluck> No idea. *shrug*
  388. # [10:27] <odinho> Hehe, I think we can discuss technical on the list first.
  389. # [10:28] <jgraham> Writing a change proposal isn't the best way to get the spec changed
  390. # [10:28] <ShaneHudson> kennyluck: Thank you for the link, I will bookmark it but for now will take the advice of Ms2ger and odinho
  391. # [10:28] <kennyluck> I am simply answering "How do we go about removing srcset from the living spec?" question, and I am a bit sad that no one in this channel has mentioned a, well, way.
  392. # [10:28] <jgraham> The best way is to present convincing technical arguments that it is wrong
  393. # [10:29] * Joins: romainhuet (u2533@gateway/web/irccloud.com/x-debfqfzxgozdikxa)
  394. # [10:29] <jgraham> kennyluck: I assume the goal is not "remove srcset" per-se but "enable a good design for adaptive image loading"
  395. # [10:29] <remysharp> anyone know if img@srcset define in the spec to look for the srcset **before** trying to download the img@src url? (posted before, not sure it made it through the intertubes)
  396. # [10:29] <odinho> change proposal: http://w3cmemes.tumblr.com/post/22414849805
  397. # [10:29] <ShaneHudson> It is going to be very hard to go against hixie since he is obviously understands far more of browser development than I do. But as a spec that every developer should stick to, srcset is not the right way to go.
  398. # [10:29] <jgraham> remysharp: What do you mean?
  399. # [10:30] <kennyluck> jgraham, I am not familiar with this topic but I am just answering "How do we go about removing srcset from the living spec?".
  400. # [10:30] <remysharp> jgraham: if srcset makes it in to browsers, I mustn't request the img@src first by default - otherwise there's no point in having the bandwidth checks
  401. # [10:30] <odinho> remysharp: That's more or less implied, -- but yes, it should say that.
  402. # [10:30] <jgraham> kennyluck: I hope the actual goal is not to be obstructionist, but to be constructive
  403. # [10:30] <[tm]> Ms2ger: thanks, looking now
  404. # [10:31] <remysharp> odinho: good lord - give a vendor "implied" and we authors are fucked - if it can't be removed, it must be explicit about that.
  405. # [10:31] <jgraham> remysharp: Right, the browser would process the whole image tag at once and load the one correct resource
  406. # [10:31] <ShaneHudson> remysharp: haha!
  407. # [10:31] <jgraham> It's not implied, I assume
  408. # [10:31] <odinho> remysharp: Yes I know yes I know. :P I work in Opera. But it's still a draft under discussion :P
  409. # [10:31] <ShaneHudson> Yes I think we have all seen why the spec needs to be a tightly written as any contract
  410. # [10:31] <jgraham> Without reading the spec, I imagine it specifies which image resource should be displayed
  411. # [10:31] <kennyluck> jgraham, I am being constructive by giving ShaneHudson an answer he is looking for.
  412. # [10:32] <jgraham> Of course a browser could chose to load other resources if it wanted. But a browser *could* do anything
  413. # [10:32] <jgraham> kennyluck: I think it is more constructive to take the question a little less literally.
  414. # [10:32] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
  415. # [10:33] <odinho> remysharp: It's specified.
  416. # [10:33] <odinho> remysharp: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
  417. # [10:33] * Joins: gwicke (~gabriel@212.255.28.33)
  418. # [10:33] * Joins: graememcc (~chatzilla@host86-140-179-108.range86-140.btcentralplus.com)
  419. # [10:34] <remysharp> odinho: uses the word "updates" - should that be "load"?
  420. # [10:34] <remysharp> it seems to suggest it's resetting state (though I've not finished reading)
  421. # [10:34] <odinho> remysharp: load uses that algorithm.
  422. # [10:35] <jgraham> remysharp: first load seems like a special case of update
  423. # [10:35] <jgraham> ShaneHudson: FWIW I am *very* skeptical that anything involving media queries is the right solution
  424. # [10:35] <othermaciej> some browser engines will actually initiate the load before the "update the image data" steps would be triggered by they will presumably choose in the same way if they want to do a good job
  425. # [10:36] <jgraham> Becauseit should only be possible to vary on 3 properties: viewport width, viewport height and display density
  426. # [10:36] <othermaciej> (the spec doesn't specify anything about prefetching)
  427. # [10:36] <jgraham> Reusing a general syntax but neutering it so that most things people expect to work don't work seems like a terrible idea
  428. # [10:36] <odinho> othermaciej: It can probably use "process the image candidates" algorithm anyway: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
  429. # [10:37] <jgraham> Right, prefetching is an optimisation
  430. # [10:37] <odinho> Hmmz. Why did I get a wrong URL there, meant http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates
  431. # [10:37] <annevk> remysharp: example of a browser vendor messing up that badly?
  432. # [10:37] <remysharp> video
  433. # [10:37] <remysharp> video referrers were missing from implementations
  434. # [10:38] <remysharp> it's not huge, but it was serious enough to nuke a few servers during hotlinking
  435. # [10:38] <remysharp> Specs are hard for "authors" to read - see appcache - and any ambiguity just makes everything harder for all involved
  436. # [10:39] <annevk> sure
  437. # [10:39] <jgraham> Right, that's why specs are hard to read
  438. # [10:39] <jgraham> (not just for authors, but they spend less time doing it)
  439. # [10:39] <ShaneHudson> Ok I will admit... hixie's email makes srcset look a lot better than it originally did. But I still do not like it
  440. # [10:39] <annevk> I was just curious as doing more network requests than required is something all browsers try very hard to avoid
  441. # [10:40] <jgraham> Well, not entirely
  442. # [10:40] <odinho> ShaneHudson: You want to write very clearly what you want to do. Not getting stuck on *how* you want to do it.
  443. # [10:40] <odinho> ShaneHudson: That is the best and easiest way to reply and give feedback.
  444. # [10:40] <jgraham> I think many implementations of speculation can cause network requests that are later not used
  445. # [10:40] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
  446. # [10:41] <jgraham> Or starting loading DOM-created elements before they are inserted
  447. # [10:41] * Quits: Ms2ger (~Ms2ger@91.181.123.95) (Ping timeout: 272 seconds)
  448. # [10:41] <ShaneHudson> odinho: hmm yes, I will go through it properly after I have been to the gym. But as a "front-end developer" I tend to think more of syntax than how it works technically, so need to balance the two
  449. # [10:42] <odinho> ShaneHudson: Hm, you shouldn't have to think about other stuff than the frontend. But not the syntax, -- what you are getting as end-result, what your users are seeing. Etc etc. You don't need to speak in browser implementation requirements, most people don't - that's mostly for the last step.
  450. # [10:44] <odinho> E.g. what the outcome is in different scenarios for the same page :-)
  451. # [10:44] * Joins: karlcow (~karl@nerval.la-grange.net)
  452. # [10:44] <annevk> [tm]: I think you need to modify Overview.src.html quite a bit for that
  453. # [10:44] <jgraham> To be fair, that's only really if you disagree with the requirements presented so far
  454. # [10:44] <annevk> [tm]: e.g. it needs some kind of license switch I guess
  455. # [10:45] <annevk> [tm]: a style sheet switch
  456. # [10:45] * Joins: kenneth_ (kenneth@nat/nokia/x-hdharwlqympylfml)
  457. # [10:45] <jgraham> It seems to me that that if there is agreement that viewport dimensions / pixel density are the right axes to vary along then most of the rest of the questions are about syntax
  458. # [10:46] <jgraham> If they're not then presenting use cases - things you want to achieve - that require extra considerations is the most important first step, yes
  459. # [10:47] <odinho> :-)
  460. # [10:47] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  461. # [10:49] * Joins: jarib (~jarib@unaffiliated/jarib)
  462. # [10:49] <ShaneHudson> Was the idea of bandwidth as a use case turned down completely? I think that although it is not easily possible at the moment, we should be future proofing too
  463. # [10:50] <odinho> ShaneHudson: Nope, I was maybe thinking about replying to that.
  464. # [10:51] <jgraham> I don't see how bandwidth will ever be possible to solve in this way
  465. # [10:51] <[tm]> annevk: yeah, no worries
  466. # [10:51] <[tm]> working on it now
  467. # [10:51] <jgraham> And hopefully will become less of a problem over time
  468. # [10:51] <annevk> [tm]: you can probably base it on DOM or something
  469. # [10:51] * Joins: vincentb_ (Adium@teledetection213.teledetection.fr)
  470. # [10:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 260 seconds)
  471. # [10:51] <odinho> jgraham: In the case where you just want the smallest size, it's very easy. E.g. I pay for data traffic over 1GB on my phone.
  472. # [10:51] <annevk> ShaneHudson: Hixie's email explains why bandwidth cannot be exposed as a meaningful metric
  473. # [10:52] <[tm]> need to get it done before plh goes on vacation, so we can his OK for FPWD transition
  474. # [10:52] <[tm]> annevk: I think I got it done for now
  475. # [10:52] <jgraham> But Opera have a bit of experience here; we try to use heuristics to suggest when you might want to switch to use Turbo mode which will conserve bandwidth
  476. # [10:52] <annevk> [tm]: he already gave his OK
  477. # [10:52] <odinho> annevk: It doesn't have to be exposed. As it will be an optimization, the browser can choose.
  478. # [10:52] <ShaneHudson> annevk: Does it? I know he says he cannot think how to do it, but something is likely to change or be invented in a few years
  479. # [10:52] <odinho> jgraham: Yeah, and we all know how bad that is :P
  480. # [10:52] <jgraham> This turns out to be *very* hard to get right
  481. # [10:52] <odinho> jgraham: But it's easier on phones.
  482. # [10:53] <ShaneHudson> Right I must be going, see you all later
  483. # [10:53] <[tm]> annevk: yeah, that was provisional on me actually getting it ready
  484. # [10:53] <jgraham> odinho: If you are on a data constrained plan, I suggest Opera mini :p
  485. # [10:53] <annevk> [tm]: oh lol, politics
  486. # [10:53] <odinho> jgraham: Because you can trust the OS knows if you're on GPRS, EDGE, 3G, Wifi.
  487. # [10:53] <annevk> [tm]: you'd think he would have heard of pubrules
  488. # [10:53] <jgraham> So?
  489. # [10:54] <jgraham> How to map that to "I want different assets" is decidedly non-obvious
  490. # [10:54] * Parts: vincentb_ (Adium@teledetection213.teledetection.fr)
  491. # [10:54] <jgraham> (on desktop you can also be on various different connection types, including some or all of those)
  492. # [10:54] <odinho> jgraham: ...? How? If I'm on GPRS I really want to download the smallest image, even though I'm using my KDE Spark tablet with a huge screen.
  493. # [10:55] <odinho> jgraham: Same with my main browser on my normal computer. NetworkManager also expose this information to programs running.
  494. # [10:55] <annevk> odinho: it seems you want the smallest image if you're on 3G as well because you're data-constrained
  495. # [10:55] <annevk> odinho: whereas someone with an iPad on 3G with no data constraints might not want that at all
  496. # [10:55] <jgraham> I have been on non-constrained 3G
  497. # [10:55] <jgraham> Right
  498. # [10:55] <annevk> odinho: so that doesn't seem like a meaningful metric
  499. # [10:55] <odinho> annevk: I'm not up to 1GB.
  500. # [10:55] <annevk> odinho: 1GB is constrained
  501. # [10:55] <odinho> Have any of you ever tried using GPRS?
  502. # [10:55] <jgraham> So a user would have to manually map connection type to desired assets
  503. # [10:55] <jgraham> It would be insane
  504. # [10:55] <odinho> It's very slow.
  505. # [10:56] <annevk> odinho: I know
  506. # [10:56] <jgraham> We can't have a feature that requires UI that no one would implement
  507. # [10:56] <odinho> My computer knows when I'm on GPRS.
  508. # [10:56] <odinho> I don't see why it couldn't just take the lightest assets when I am.
  509. # [10:57] <annevk> odinho: how many assets do you think the page is going to provide though?
  510. # [10:57] <jgraham> In that case I would probably turn on turbo/use mini
  511. # [10:57] <jgraham> And not rely on athors to get it right
  512. # [10:58] <annevk> yeah
  513. # [10:58] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  514. # [10:58] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  515. # [10:59] <odinho> annevk: Well, many sites are CMS driven, mine are, and I guess something like 280w, 576w, 1024w.
  516. # [11:00] <odinho> Yeah, Opera mini/turbo is a better fix, -- but it does rely on proxy servers.
  517. # [11:01] <jgraham> Sure
  518. # [11:01] <jgraham> Anyway, there was a solution to this problem in HTML
  519. # [11:01] <jgraham> lowsrc
  520. # [11:01] <odinho> But thing is, it wouldn't have to really expose anything extra. Although filesize would help, however I can't see that getting any actual use. So this is purely a potential optimization for a browser to do.
  521. # [11:01] * Joins: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi)
  522. # [11:01] <jgraham> It didn't really go anywhere
  523. # [11:01] <odinho> So there needs to be no spec change.
  524. # [11:02] <odinho> I'm merely saying, and meaning, that it *is* possible to use bandwidth and/or data usage as a metric and potential use case here.
  525. # [11:03] * Joins: necolas (~necolas@80.231.76.54)
  526. # [11:03] <jgraham> So your proposal is that, if it knows it is in a bandwidth constrained situation, the UA could choose the "wrong" asset to get one likely to be smaller
  527. # [11:03] * Joins: mpt (~mpt@nat/canonical/x-ftikaoatghrwyvmu)
  528. # [11:03] * Quits: mpt (~mpt@nat/canonical/x-ftikaoatghrwyvmu) (Changing host)
  529. # [11:03] * Joins: mpt (~mpt@canonical/mpt)
  530. # [11:06] <odinho> jgraham: Yep. Being a agent to the user. Or actually even, -- (although progressive images are better here) if you are in fact on a very slow network (not high latency (not saying how you find out that :P)), downloading the small file first to show in-place before doing the big one.
  531. # [11:07] <annevk> that's already allowed
  532. # [11:07] <annevk> "This allows a user agent to override the default algorithm (as described in subsequent steps) in case the user agent has a reason to do so. For example, it would allow the user agent in highly bandwidth-constrained conditions to intentionally opt to use an image intended for a smaller screen size, on the assumption that it'll probably be good enough. "
  533. # [11:07] <annevk> rtfs?
  534. # [11:08] <odinho> annevk: I have. I'm not discussing with the spec, I'm discussing with jgraham, which is saying something else :-)
  535. # [11:09] <jgraham> I'm not saying something else
  536. # [11:09] <jgraham> I'm saying having a feature for it in the spec is silly
  537. # [11:10] <odinho> jgraham: It doesn't really need a feature in the spec, -- because the current information should be enough.
  538. # [11:10] <zcorpan> Hixie: "
  539. # [11:10] <zcorpan> This seems like something that's currently relatively easily handled using
  540. # [11:10] <zcorpan> hidden="" or CSS, with some JS (or more CSS) to decide when to show what." - hidden="" and CSS don't stop the image from loading
  541. # [11:11] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Read error: Operation timed out)
  542. # [11:12] * Joins: richwild (b0236a65@gateway/web/freenode/ip.176.35.106.101)
  543. # [11:13] <[tm]> annevk: can I add you as a co-editor on the URL spec?
  544. # [11:13] * Joins: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
  545. # [11:14] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  546. # [11:16] * Quits: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi) (Ping timeout: 244 seconds)
  547. # [11:17] <annevk> [tm]: if arv is going to edit I don't think it's needed for me to be listed there
  548. # [11:19] * Joins: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi)
  549. # [11:22] <[tm]> OK
  550. # [11:23] <[tm]> annevk: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
  551. # [11:23] <[tm]> I made a new make target
  552. # [11:23] <[tm]> WD target
  553. # [11:24] <[tm]> so we just flip it back to the "publish" target after WD publication
  554. # [11:25] <[tm]> anyway, break time here
  555. # [11:25] <annevk> [tm]: what I do these days is generate a TR.html copy so the editor's draft is not affected
  556. # [11:25] <[tm]> thank God almighty
  557. # [11:25] <annevk> heh
  558. # [11:25] * Quits: Lachy (~Lachy@cm-84.215.193.30.getinternet.no) (Quit: Computer has gone to sleep.)
  559. # [11:25] <[tm]> annevk: OK, I can switch it to that later today
  560. # [11:43] * Joins: Lachy (Lachy@nat/opera/x-anyekuhbgiqyykzk)
  561. # [11:46] * Joins: nonge_ (~nonge@p508299DF.dip.t-dialin.net)
  562. # [11:49] * Quits: nonge (~nonge@p50829C68.dip.t-dialin.net) (Read error: Operation timed out)
  563. # [11:51] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  564. # [11:52] * Joins: jarib (~jarib@unaffiliated/jarib)
  565. # [12:02] * Joins: Isaq (dcff0288@gateway/web/freenode/ip.220.255.2.136)
  566. # [12:02] * Quits: tomasf (~tom@2002:55e5:dbde:0:b9fc:8df3:2f62:a08f) (Quit: tomasf)
  567. # [12:02] * tomasf_ is now known as tomasf
  568. # [12:07] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
  569. # [12:10] * Parts: Isaq (dcff0288@gateway/web/freenode/ip.220.255.2.136)
  570. # [12:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  571. # [12:16] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  572. # [12:16] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  573. # [12:18] * Joins: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  574. # [12:18] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
  575. # [12:19] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
  576. # [12:20] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 244 seconds)
  577. # [12:23] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 265 seconds)
  578. # [12:23] <annevk> hmm
  579. # [12:24] <annevk> people on the WHATWG list don't seem to understand how pixel density affects images in practice
  580. # [12:24] <annevk> oh well
  581. # [12:29] <othermaciej> people seem not to get the fact that the pixel density you provide affects how the image renders
  582. # [12:29] <othermaciej> I'm not sure why this is hard to grasp (apparently)
  583. # [12:30] <othermaciej> people doing native iOS development seem to understand how 2x images fit into the picture
  584. # [12:30] <othermaciej> I think people may not realize that high pixel density means, ultimately, that CSS pixels != device pixels and most images are shown scaled up relative to the native device resolution
  585. # [12:31] * Joins: nessy (~Adium@124-169-129-81.dyn.iinet.net.au)
  586. # [12:32] <annevk> or I give feedback on how constraining URLs is not a good idea
  587. # [12:32] <annevk> "I've seen no objections about that aspect in the Community Group thread, where a number of authors have given feedback."
  588. # [12:32] <annevk> well I just gave you some
  589. # [12:33] <jgraham> Yeah, the implication that the source of the feedback somehow trumps its actual merit is distressing
  590. # [12:35] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Quit: tantek)
  591. # [12:36] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
  592. # [12:42] * Joins: mpt (~mpt@nat/canonical/x-cepzvudaeikfjrzv)
  593. # [12:42] * Quits: mpt (~mpt@nat/canonical/x-cepzvudaeikfjrzv) (Changing host)
  594. # [12:42] * Joins: mpt (~mpt@canonical/mpt)
  595. # [12:44] * annevk stops with http://xkcd.com/386/ and goes to do something else
  596. # [12:49] <othermaciej> heh
  597. # [12:58] <annevk> so should we add new Range()?
  598. # [12:59] * Joins: val__ (~val@c0017-1-82-245-14-126.fbx.proxad.net)
  599. # [13:01] <[tm]> annevk: fyi, I reverted http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html to being unmolested
  600. # [13:02] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  601. # [13:02] <[tm]> and made a TR.html for the TR version
  602. # [13:02] <[tm]> http://dvcs.w3.org/hg/url/raw-file/tip/TR.html
  603. # [13:02] <annevk> ta
  604. # [13:03] <annevk> [tm]: you should probably change the <title> and "Living Draft" in the <h2> does not work either for a TR publication
  605. # [13:05] <[tm]> hai
  606. # [13:06] * Joins: Ms2ger (~Ms2ger@vpnh210.ugent.be)
  607. # [13:11] * Joins: maikmerten (~maikmerte@port-92-201-49-70.dynamic.qsc.de)
  608. # [13:12] <annevk> AryehGregor: how is the detach() experiment going?
  609. # [13:13] <annevk> Ms2ger: should we add baseLang?
  610. # [13:13] <annevk> we should have a better name ideally...
  611. # [13:14] <Ms2ger> What's baseLang?
  612. # [13:15] <annevk> language of the node/element
  613. # [13:15] <annevk> as determining it through script is non-trivial
  614. # [13:16] <Ms2ger> Hmm
  615. # [13:16] <annevk> can baseURI still be null btw?
  616. # [13:16] <annevk> DOMString? looks like a bug if everything starts with about:blank
  617. # [13:20] <[tm]> kinuko has landed a first draft of the Quota API spec: http://dvcs.w3.org/hg/quota/raw-file/default/Overview.html
  618. # [13:22] <annevk> respec :/
  619. # [13:24] <[tm]> yeah
  620. # [13:25] <annevk> emailed some feedback to public-webapps
  621. # [13:26] <annevk> I assumed he's subscribed since I didn't find an email address
  622. # [13:36] * Quits: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.88.2-rdmsoft [XULRunner 12.0/20120420145725])
  623. # [13:40] * Joins: skylamer` (cgskylamer@78.90.213.55)
  624. # [13:43] * Quits: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
  625. # [13:43] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  626. # [13:48] <annevk> language barrier ftl https://www.w3.org/Bugs/Public/show_bug.cgi?id=17042
  627. # [13:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  628. # [13:49] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  629. # [13:53] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
  630. # [13:53] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  631. # [13:56] <annevk> zcorpan: hey yt?
  632. # [13:56] <annevk> zcorpan: you reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=16712
  633. # [13:57] <annevk> zcorpan: I'm trying to figure out how you could ever hit that case 2
  634. # [13:57] * Quits: krijn (u2319@gateway/web/irccloud.com/x-xkjyqwvqxbdmgfei)
  635. # [13:57] <annevk> zcorpan: because it seems case 1 covers it aleady
  636. # [13:58] <zcorpan> annevk: the element doesn't have a prefix
  637. # [14:01] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  638. # [14:02] * Joins: smaug (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
  639. # [14:02] <annevk> zcorpan: exactly, so its namespace prefix equals prefix
  640. # [14:02] * Quits: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi) (Ping timeout: 272 seconds)
  641. # [14:03] <annevk> zcorpan: they're both null
  642. # [14:03] * smaug is now known as smaug____
  643. # [14:03] <zcorpan> annevk: /prefix/ is "bar"
  644. # [14:04] * Joins: jarib (~jarib@unaffiliated/jarib)
  645. # [14:04] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  646. # [14:05] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  647. # [14:05] <annevk> zcorpan: right
  648. # [14:05] <annevk> zcorpan: I guess what I'm saying is if I remove ', or whose namespace prefix is null and local name is "xmlns"' does something fall apart?
  649. # [14:06] <annevk> zcorpan: hmm I guess so
  650. # [14:06] <annevk> aah namespaces
  651. # [14:06] <zcorpan> :)
  652. # [14:07] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  653. # [14:08] <zcorpan> "or whose namespace prefix is null and local name is "xmlns" if prefix is null:"
  654. # [14:08] <zcorpan> (possibly also check the namespace of the "xmlns" attribute)
  655. # [14:08] <annevk> I think I'll add some words for clarity
  656. # [14:08] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
  657. # [14:11] * Quits: skylamer` (cgskylamer@78.90.213.55) (Remote host closed the connection)
  658. # [14:16] <annevk> man this is some long sentence :(
  659. # [14:22] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
  660. # [14:23] <[tm]> annevk: kinuko is a woman, btw
  661. # [14:25] <zcorpan> annevk: looks good
  662. # [14:25] <[tm]> and she is subscribed to public-webppas
  663. # [14:27] <annevk> cool cool
  664. # [14:28] <annevk> is it just the -o or -ko that indicates the name of a woman in Japan?
  665. # [14:32] <annevk> Ms2ger: garbage collection in DOM
  666. # [14:32] * Quits: Ms2ger (~Ms2ger@vpnh210.ugent.be) (Ping timeout: 260 seconds)
  667. # [14:32] <annevk> Ms2ger: where should we put that
  668. # [14:32] <annevk> yeah leave the channel alright
  669. # [14:32] * Joins: erichynds (~ehynds@64.206.121.41)
  670. # [14:32] <annevk> chicken
  671. # [14:33] <[tm]> annevk: -ko
  672. # [14:34] <charlvn> there are japanese men who also have names ending in -o or -ko afaik
  673. # [14:34] <[tm]> yeah
  674. # [14:34] <charlvn> although i think -ko is more common with female names
  675. # [14:36] <[tm]> right. there aren't a lot of men's names that end in -ko and you can almost always tell from the name if it's a men's name or a women's regardless
  676. # [14:36] * Joins: Ms2ger (~Ms2ger@vpnh064.ugent.be)
  677. # [14:36] <annevk> ah, the chicken returns :)
  678. # [14:36] <[tm]> I think the men's names are usually -hiko
  679. # [14:37] <charlvn> [tm]: sounds right
  680. # [14:38] <Ms2ger> Hah
  681. # [14:38] <Ms2ger> annevk, in the closet?
  682. # [14:39] <annevk> ideally, but smaug____ wants it
  683. # [14:39] <annevk> HTML has http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection
  684. # [14:39] <smaug____> what do I want?
  685. # [14:39] <annevk> garbage collection notes in DOM
  686. # [14:40] <smaug____> not really gc, but definition of ownership
  687. # [14:40] <smaug____> or definition in which cases certain objects won't be deleted
  688. # [14:40] <Ms2ger> Everything owns everything :)
  689. # [14:41] <smaug____> whether gc is used internally, is implementation detail
  690. # [14:42] <annevk> not really sure we have to say much then
  691. # [14:43] <annevk> other than that sentence of HTML
  692. # [14:43] <annevk> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16638 suggests saying something about weak references, but that's more of an impl detail
  693. # [14:46] <smaug____> "Unless disconnect() is called, MutationObserver observes node as long as the node exists"
  694. # [14:46] <smaug____> something like that
  695. # [14:47] <annevk> that doesn't mean much
  696. # [14:49] <smaug____> it doesn't ?
  697. # [14:49] <smaug____> it means that the MutationObserver doesn't die even if you don't keep a reference to it
  698. # [14:57] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
  699. # [14:59] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  700. # [15:05] * Quits: KDN (~kdn@2001:700:a00:ff21:3d71:5a2a:c16e:4d48) (Quit: KDN)
  701. # [15:06] * Joins: KDN (~kdn@pc173-96.hiof.no)
  702. # [15:10] * Quits: KDN (~kdn@pc173-96.hiof.no) (Ping timeout: 260 seconds)
  703. # [15:15] * Joins: ehsan (~ehsan@209.20.29.228)
  704. # [15:15] * Joins: davidb (~davidb@66.207.208.98)
  705. # [15:20] * Joins: necolas_ (~necolas@80.231.76.54)
  706. # [15:20] * Quits: necolas (~necolas@80.231.76.54) (Read error: Connection reset by peer)
  707. # [15:20] * Quits: val__ (~val@c0017-1-82-245-14-126.fbx.proxad.net) (Ping timeout: 245 seconds)
  708. # [15:20] * Quits: [[zz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net) (Remote host closed the connection)
  709. # [15:21] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
  710. # [15:24] <[tm]> btw, http://lists.w3.org/Archives/Public/public-whatwg-archive/ is not available
  711. # [15:24] <[tm]> *now available
  712. # [15:25] * Joins: [[zz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net)
  713. # [15:25] <annevk> yeah noticed that yesterday
  714. # [15:25] <annevk> very cool
  715. # [15:26] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
  716. # [15:26] <[tm]> now we should figure out how to add an Archived-at header to whatwg@whatwg.org messages
  717. # [15:30] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Ping timeout: 256 seconds)
  718. # [15:37] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  719. # [15:38] * Joins: JohnAlbin (~JohnAlbin@114-36-33-17.dynamic.hinet.net)
  720. # [15:38] * Joins: MacTed (~Thud@63.119.36.36)
  721. # [15:39] <zewt> used to be you could just search for message-ids, but gmail makes it a pain to get it, which is annoying
  722. # [15:40] * necolas_ is now known as necolas
  723. # [15:42] * Joins: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se)
  724. # [15:46] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Remote host closed the connection)
  725. # [15:46] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
  726. # [15:46] * Joins: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
  727. # [15:48] * Quits: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
  728. # [15:48] * Joins: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
  729. # [15:49] * Joins: KDN (~kdn@90.149.135.254)
  730. # [15:51] <zcorpan> [tm]: archived-at would be nice
  731. # [15:55] * Joins: dbaron (~dbaron@nat/mozilla/x-hqhzmdpkxbxypemi)
  732. # [15:55] <dbaron> anybody know of a description of the advantages of WebVTT over TTML (or some subset thereof)?
  733. # [15:58] <annevk> dbaron: http://lists.w3.org/Archives/Public/public-html/2010May/0160.html
  734. # [15:59] <dbaron> ok, so now suppose that the TTML folks are willing to redefine it to be on top of HTML+CSS instead of XSL-FO?
  735. # [16:00] <dbaron> (may or may not actually be the case, but under discussion)
  736. # [16:00] <annevk> I guess that leaves the enormous amount of namespaces and complexity of having a lot of markup where something simpler does fine
  737. # [16:01] <annevk> and draconian error handling for a text format which would be a first as far as browser technology goes
  738. # [16:01] <zewt> annevk: i don't know anything about it, but that description makes it sound like they have no experience with web formats
  739. # [16:02] <zewt> brb reboot
  740. # [16:02] <annevk> TTML is badly designed
  741. # [16:02] <annevk> that's why we went with WebVTT
  742. # [16:03] <zewt> actually no reboot
  743. # [16:04] <zewt> dbaron: fwiw since VTT seems like it'll work fine, I don't think any amount of "what if we do this" will make web people interested in a different captioning format (ttml or otherwise), there's no problem solved by that
  744. # [16:05] <dbaron> so what's going on is:
  745. # [16:05] * Joins: jdong_bot_ (~jdong_bot@106.3.63.56)
  746. # [16:05] <dbaron> (a) w3c is looking at chartering a WG to do a new version of TTML: http://lists.w3.org/Archives/Public/public-new-work/2012Apr/0005.html
  747. # [16:05] * Joins: ehsan (~ehsan@66.207.208.98)
  748. # [16:05] <dbaron> (b) there's apparently a US government regulation that's going to go into effect in September that may actually require captioning in TTML
  749. # [16:05] <zewt> that sounds BS
  750. # [16:05] <zewt> (in the "not true" sense, not "it's stupid" sense)
  751. # [16:06] <zewt> (not that it wouldn't be the latter too :)
  752. # [16:07] <annevk> I heard about (b) too
  753. # [16:07] <dbaron> something from http://www.fcc.gov/encyclopedia/video-programming-accessibility-advisory-committee-vpaac
  754. # [16:07] <annevk> (a) does not matter much; W3C charters groups to work on silly stuff all the time
  755. # [16:07] <zewt> i heard something about how a specific format was given as an example of a format that could be used, and people read that and went "so now that's required!"
  756. # [16:08] <zewt> http://lists.w3.org/Archives/Public/public-texttracks/2012Apr/0001.html
  757. # [16:08] <espadrine> if the TTML group is ready to redefine it to be on top of HTML+CSS, surely the government cannot push a requirement to use something whose spec is changing
  758. # [16:09] <dbaron> apparently it would be VPAAC WG1
  759. # [16:09] <Ms2ger> espadrine, Ha. Ha. Ha.
  760. # [16:09] <dbaron> apparently the bigger problem is that everybody implements a different subset of TTML
  761. # [16:10] <annevk> isn't the bigger problem that it's a terrible format?
  762. # [16:11] <dbaron> meant the bigger problem with the requirement
  763. # [16:11] <annevk> thanks zewt
  764. # [16:11] <dbaron> but yes, that too
  765. # [16:11] <zewt> there's nothing else leading to the "something something federal requirement" noise, right?
  766. # [16:12] <annevk> during the F2F glenn mentioned it and a couple of people were like "yup that's correct; tough luck WebVTT guys"
  767. # [16:12] * Quits: richwild (b0236a65@gateway/web/freenode/ip.176.35.106.101) (Quit: Page closed)
  768. # [16:13] <odinho> Hehe, yeah, fear struck.
  769. # [16:13] <zewt> "that" glenn? heh
  770. # [16:13] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  771. # [16:13] <annevk> other glenn!
  772. # [16:13] <dbaron> SMPTE-TT is a profile (with additions) of TTML, no?
  773. # [16:13] <dbaron> not a container for it as that message implies?
  774. # [16:13] <zewt> captioning isn't rocket science; if you need *profiles* of a captioning format, something seems badly amiss
  775. # [16:14] <jgraham> Well clearly something *is* badly amiss
  776. # [16:14] <zewt> something usually is
  777. # [16:14] * Joins: richw (b0236a65@gateway/web/freenode/ip.176.35.106.101)
  778. # [16:14] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  779. # [16:15] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
  780. # [16:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  781. # [16:16] <annevk> dbaron: looks like a super-subset, yes
  782. # [16:17] <annevk> as in, it supersets a subset of TTML
  783. # [16:17] <jgraham> Isn't that what we call a "different format"?
  784. # [16:17] <annevk> it uses namespaces so it's cool
  785. # [16:18] <zewt> heh
  786. # [16:18] <[tm]> dbaron, zewt: as far as that supposed US government requirement for TTML, see http://fjallfoss.fcc.gov/edocs_public/attachmatch/FCC-12-9A1.pdf
  787. # [16:18] <zcorpan> does it have 18 new namespaces?
  788. # [16:18] <[tm]> and look for "apparatus"
  789. # [16:18] <zewt> annevk: someone on the webgl list said he wants to push for using the URL-namespacing-gimmick to identify webgl extensions
  790. # [16:18] <zewt> raaaaaaaaage
  791. # [16:18] <zewt> re: xml tried that. it sucked. stop it
  792. # [16:19] <dbaron> is that pdf the same as https://www.federalregister.gov/articles/2012/03/30/2012-7247/closed-captioning-of-internet-protocol-delivered-video-programming-implementation-of-the ?
  793. # [16:19] <annevk> zewt: "feature" in object does not work anymore?
  794. # [16:19] <annevk> zewt: but yeah, ...
  795. # [16:19] <zewt> oh everything works fine
  796. # [16:19] <zewt> he just wanted to change to urls because *crickets*
  797. # [16:20] <odinho> [tm]: They sure say a lot of apparatus all over the place!
  798. # [16:20] * dbaron heads back indoors
  799. # [16:21] <zewt> fortunately he didn't go on to push it, but it's astonishing that nonsense keeps cropping up
  800. # [16:22] <jgraham> Those damn crickets
  801. # [16:22] <annevk> http://cdn.memegenerator.net/instances/400x/20446042.jpg
  802. # [16:23] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net) (Ping timeout: 245 seconds)
  803. # [16:24] <[tm]> odinho: the section "A. Apparatus Subject to Section 203 of the Act
  804. # [16:25] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  805. # [16:25] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  806. # [16:27] <odinho> [tm]: Page 65 seems interesting. But nothing about TTML.
  807. # [16:27] <[tm]> odinho: "If a
  808. # [16:27] <[tm]> video programming owner provides captions to a video programming distributor or provider using the
  809. # [16:27] <[tm]> Society of Motion Picture and Television Engineers Timed Text format (SMPTE ST 2052-1:2010:
  810. # [16:27] <[tm]> “Timed Text Format (SMPTE-TT)” 2010) (incorporated by reference, see § 79.100), then the VPO has
  811. # [16:27] <[tm]> fulfilled its obligation to deliver captions to the video programming distributor or provider in an
  812. # [16:27] <[tm]> acceptable format.
  813. # [16:28] <[tm]> and "The VPAAC proposed that the Commission require a single standard interchange format
  814. # [16:28] <[tm]> so that video programming does not need to be re-captioned to comply with different standards.
  815. # [16:28] <[tm]> 508
  816. # [16:28] <[tm]> The
  817. # [16:28] <[tm]> VPAAC proposed SMPTE-TT as the standard interchange format
  818. # [16:29] <odinho> [tm]: Ah, -- but the general requirements are that you can scale the text and do all sorts of other things, so it doesn't really exclude WebVVT.
  819. # [16:29] <odinho> But that last thing is not written in-doc as requirement, I guess? They only propose that as single standard?
  820. # [16:30] <[tm]> odinho: they are careful to not say it is "mandatory"
  821. # [16:30] <[tm]> but instead "safe harbor"
  822. # [16:30] <[tm]> I don't know that that particular term of art means
  823. # [16:30] <[tm]> e.g., "unlike adopting SMPTE-TT as the mandatory interchange or delivery format, commenters explain that a
  824. # [16:30] <[tm]> safe harbor approach would balance goals of efficiency, certainty, and consumer access with needed
  825. # [16:32] <odinho> e will also provide in our rules that devices that implement SMPTE-TT
  826. # [16:32] <odinho> will be deemed in compliance with our rules, while simultaneously allowing devices to achieve the same
  827. # [16:32] <odinho> functionality without implementing that standard.5
  828. # [16:33] <odinho> "We intend to monitor the marketplace and, to the extent that additional open standards from recognized industry standard-setting organizations appear appropriate, we will consider incorporating those standards into our rules as additional safe harbors.
  829. # [16:33] * Joins: grandmasChoad (~chatzilla@vpn.space150.com)
  830. # [16:33] <odinho> So it seems it can be done ;-)
  831. # [16:34] * Parts: grandmasChoad (~chatzilla@vpn.space150.com)
  832. # [16:36] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 244 seconds)
  833. # [16:36] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
  834. # [16:37] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
  835. # [16:37] * Joins: niloy (~niloy@61.12.96.242)
  836. # [16:38] * Joins: mpt (~mpt@canonical/mpt)
  837. # [16:43] * Quits: espadrine (~thaddee_t@63-235-13-3.dia.static.qwest.net) (Quit: espadrine)
  838. # [16:44] * Joins: raphc (~rc@92.103.77.27)
  839. # [16:46] * Quits: raphc (~rc@92.103.77.27) (Client Quit)
  840. # [16:47] * Joins: raphc (~rc@92.103.77.27)
  841. # [16:47] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  842. # [16:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 244 seconds)
  843. # [16:52] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
  844. # [16:53] * Joins: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com)
  845. # [16:54] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  846. # [16:54] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  847. # [17:04] <zcorpan> Hixie: which characters are supposed to be paragraph separators in WebVTT for the purpose of bidi?
  848. # [17:04] <zcorpan> just Bidi_Class=Paragraph_Separator ?
  849. # [17:05] * Quits: jdong_bot_ (~jdong_bot@106.3.63.56) (Remote host closed the connection)
  850. # [17:05] <zcorpan> tr9 isn't really explicit about which characters it wants to consider paragraph separators
  851. # [17:07] <zcorpan> e.g. U+2028 isn't class B, but i can't tell if it's an "appropriate Newline Function" or not
  852. # [17:09] * Quits: erichynds (~ehynds@64.206.121.41)
  853. # [17:09] * Joins: TabAtkins_ (~jackalmag@50-0-151-4.dsl.dynamic.sonic.net)
  854. # [17:10] <odinho> I surely don't understand why some people are so agressively against srcset. And noone can say why.
  855. # [17:10] <odinho> (... reading twitter)
  856. # [17:10] * Joins: espadrine (~thaddee_t@nat/mozilla/x-qwzuhuzvufelhgan)
  857. # [17:12] <zcorpan> oh, i think i found the definition of "newline function" now
  858. # [17:12] * Joins: edwardbc (~edward.ba@186.176.193.20)
  859. # [17:12] <[tm]> odinho: you can save yourself the confusion by not reading twitter :)
  860. # [17:13] <zcorpan> so newline function is platform-dependent, but none of the platforms listed as examples use any non-B-class character as newline function
  861. # [17:13] <zcorpan> so it's just B class
  862. # [17:13] * Quits: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net) (Quit: leaving)
  863. # [17:21] * Quits: dbaron (~dbaron@nat/mozilla/x-hqhzmdpkxbxypemi) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  864. # [17:23] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Quit: The computer fell asleep)
  865. # [17:23] * Joins: KevinMarks (~KevinMark@64.65.178.199)
  866. # [17:23] <TabAtkins_> odinho: Because http://w3cmemes.tumblr.com/post/22831818920/the-css-wgs-primary-failure-mode , that's why.
  867. # [17:27] * Quits: espadrine (~thaddee_t@nat/mozilla/x-qwzuhuzvufelhgan) (Quit: espadrine)
  868. # [17:27] <annevk> "If you don't set your image's resolution appropriately, you'll get unexpected sizing effects." is not actually true
  869. # [17:27] <annevk> browsers ignore the DPI set in the image
  870. # [17:28] <TabAtkins_> annevk: What I meant is that if you ship, say, a 140dpi image but declare it to be 2x, the auto-size wont' be what you may have expected.
  871. # [17:28] <TabAtkins_> At least, it won't be the same as a 96dpi image at 1x.
  872. # [17:28] <odinho> TabAtkins_: Yeah, thinking that. But saying it alound feels wrong... :]
  873. # [17:28] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Ping timeout: 260 seconds)
  874. # [17:28] <annevk> TabAtkins: it's way easier to think about it in terms of pixel density rather than resolution
  875. # [17:29] * Quits: Kolombiken (~Adium@217.13.228.226) (Ping timeout: 240 seconds)
  876. # [17:29] <TabAtkins_> odinho: It's not completely fair. A good bit of it is people not understanding the weaknesses of MQ for some of the use-cases we want to solve, and thus reacting against what they think is just a weird syntax for no reason.
  877. # [17:29] * Joins: espadrine (~thaddee_t@nat/mozilla/x-dgdzmbmmirpyrvqw)
  878. # [17:29] * ericc|afk is now known as eric_carlson
  879. # [17:29] <annevk> TabAtkins: e.g. everything from 90-130 is typically treated as 1x
  880. # [17:29] <TabAtkins_> annevk: Do image programs talk about pixel density? I thought they explicitly talked about "dpi" when saving an image.
  881. # [17:29] * Quits: richt (richt@nat/opera/x-cddvplkbghseomcj) (Remote host closed the connection)
  882. # [17:29] <annevk> TabAtkins: whereas 260-330ppi would be 2x
  883. # [17:30] <annevk> TabAtkins_: in an image program you would just make an image with twice the amount of pixels in each direction
  884. # [17:30] * Quits: twisted` (~twisted@p5DDB9484.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
  885. # [17:30] <annevk> TabAtkins_: you don't use the dpi setting because it is already ignored by browsers (and has to for compatibility)
  886. # [17:30] <TabAtkins_> annevk: I don't understand. Yes, that's how you map screens to pixel density. But that doesn't have much to do with how the Nx argument works in srcset.
  887. # [17:30] <annevk> I sort of thought everyone involved in the discussion knew this...
  888. # [17:31] <jgraham> TabAtkins_: So someone should propose <srcset><img src="something.png"><source src="somethingelse.png" width=200 height=100 density=2></srcset> or something
  889. # [17:31] <annevk> you have a 10x10 image and a 20x20 image
  890. # [17:31] <TabAtkins_> annevk: Uh, yes, I know.
  891. # [17:31] <annevk> the latter you set as 2x
  892. # [17:31] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  893. # [17:31] <annevk> you don't have to care about dpi
  894. # [17:31] <jgraham> I think that is a kind of horrible syntax compared to to srcset, but maybe that's why I'm a browser QA not a web dev.
  895. # [17:31] <annevk> which is nice because it various all over
  896. # [17:32] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  897. # [17:32] <TabAtkins_> annevk: But that's exactly equivalent to giving an image of the same size and double resolution (because browsers only care about the pixels anyway).
  898. # [17:32] <TabAtkins_> And when you talk about resolution, people will want to do that.
  899. # [17:32] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  900. # [17:32] * Quits: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Quit: tomasf)
  901. # [17:32] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  902. # [17:33] <jgraham> When people talk about "size" they mean "in pixels", no?
  903. # [17:33] <annevk> if it's double resolution it's width and height will be larger
  904. # [17:33] <TabAtkins_> jgraham: Sometimes, sometimes not. When I start GIMP, I can create an image with a size in inches and a resolution in dpi.
  905. # [17:33] <odinho> TabAtkins_: <img src=10x10 srcset="20x20.jpg 2x"> is exactly equivalent to <img src=20x20.jpg width=10 height=10>
  906. # [17:33] <TabAtkins_> odinho: Yes, I know.
  907. # [17:34] <annevk> you cannot create an image of 10x10 with more detail and have it rendered as 10x10
  908. # [17:34] <TabAtkins_> annevk: Yes, I know.
  909. # [17:34] <annevk> there's no such thing
  910. # [17:34] <annevk> well then I've no idea what you're talking about
  911. # [17:34] <odinho> :S
  912. # [17:35] * Quits: Ms2ger (~Ms2ger@vpnh064.ugent.be) (Ping timeout: 245 seconds)
  913. # [17:35] <jgraham> annevk: TabAtkins_ seems to (sometimes) be using "size" to mean something that can be measured with a ruler
  914. # [17:35] <TabAtkins_> If you create a "5 inch wide" image at 192dpi, browsers will display it as 10 inches wide.
  915. # [17:35] <jgraham> It seems clearer to me to always use "size" to mean something in pixels
  916. # [17:36] <jgraham> Because, y'know, working out what real world dimensions you get isn't that easy or helpful
  917. # [17:37] <annevk> TabAtkins_: aren't all images stored as pixels in the end?
  918. # [17:37] <TabAtkins_> annevk: Yes?
  919. # [17:37] <annevk> so then I'm not sure why we have to talk about inches
  920. # [17:37] <TabAtkins_> The point is author expectations.
  921. # [17:37] <annevk> I think authors deal in pixels too
  922. # [17:37] <TabAtkins_> I'm not *sure* if authors think that way, but I suspect that some do. I dunno.
  923. # [17:37] <necolas> 6 months ago, when we (developers) started exploring avenues for responsive images, hixie said: "<img> parsing is pretty much a lost cause" and warned us off the exact kind of syntax that is now being considered. any idea why there has been a change of heart?
  924. # [17:37] <annevk> I certainly do when creating images
  925. # [17:37] <odinho> Ah, they're doomed anyway if they think about stuff like that.
  926. # [17:37] <annevk> necolas: <img> parsing is a lost cause
  927. # [17:37] <odinho> Some print guys do, and they're always way off. Have to explain.
  928. # [17:37] <TabAtkins_> necolas: Changing the parsing of the <img> element is a lost cause.
  929. # [17:38] <annevk> necolas: adding attributes does not affect parsing
  930. # [17:38] <TabAtkins_> Dammit, annevk, why are you 2 seconds faster than me?
  931. # [17:38] <necolas> adding attributes doesn't help with polyfilling either
  932. # [17:38] <odinho> TabAtkins_: In europe?
  933. # [17:38] <annevk> TabAtkins_: Europe :p
  934. # [17:38] <odinho> FTW!
  935. # [17:38] <jgraham> necolas: I answered that once already today
  936. # [17:39] <jgraham> Adding attributes really doesn't seem that bad for polyfilling, and provides the simplest-to-implement solution that will therefore get deployed the soonest
  937. # [17:39] <necolas> i guess we're all still trying to understand why developers have been cast aside on this matter, despite it being something that developers have invested a lot of time in discussing etc
  938. # [17:40] <jgraham> If you are trying to understand that, I see the problem
  939. # [17:40] <jgraham> You are working from a false premise
  940. # [17:40] <necolas> jgraham: you don't think having 2 http requests is a problem for polyfilling?
  941. # [17:40] <necolas> jgraham: and what premise would that be?
  942. # [17:40] <jgraham> "developers have been cast aside"
  943. # [17:41] <TabAtkins_> necolas: If your goal is something that doesn't render at all in legacy browsers (but will be made to work via JS), just omit @src and only use @srcset. Done.
  944. # [17:41] <necolas> that isnt the goal
  945. # [17:41] <TabAtkins_> necolas: Oh. Then I don't understand what you mean by "2 http requests are a problem for polyfilling".
  946. # [17:41] <necolas> jgraham: [the work of] developers
  947. # [17:42] <odinho> necolas: <img srcset="cat.jpg, cat@2.jpg 2x"><noscript><img src=cat.jpg></noscript> <---- you can polyfill that without 2 HTTP requests.
  948. # [17:42] <necolas> TabAtkins_: the browser is going to request the image in `src` before any JS can get to work
  949. # [17:42] <TabAtkins_> necolas: The work done by people developing standards (which, in this case, includes all the developers participating in Adaptive/Response Images thing) is worthless. Never, *ever* try to evaluate a solution by which had the most work put into it.
  950. # [17:42] <necolas> odinho: yeah we've discussed that but dont think it is optimal
  951. # [17:42] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 244 seconds)
  952. # [17:43] <TabAtkins_> necolas: ...that's why I just suggested using only @srcset and omitting @src.
  953. # [17:43] <necolas> TabAtkins_: that's not what we're doing. but basically there has been little to no engagement with the devs who were already interested in this problem
  954. # [17:43] <jgraham> necolas: The fact that people have brought up technical shortcomings does not mean that "the work has been cast aside"
  955. # [17:44] <jgraham> Wht do you think this is if not engagement?
  956. # [17:44] <TabAtkins_> necolas: I'm not sure what a thread that explicitly thanks people for all the useful work they've done, and explicitly addresses their concerns and criticisms while crafting a solution based on their work, is, other than engagement.
  957. # [17:44] <jgraham> Seriously, if there are technical problems with the srcset proposal, point them out
  958. # [17:45] * nonge_ is now known as nonge
  959. # [17:45] <jgraham> It's a way more useful use of everyone's time than complaining about lack of engagement
  960. # [17:45] <necolas> Aside from discussions of the technical merit, I'm saying you that the developer community doesn't feel like how you described, Tab.
  961. # [17:46] <TabAtkins_> necolas: That's fine. Most people don't like it when their personal preferred solutions aren't used. That's part of standards, though.
  962. # [17:46] <TabAtkins_> necolas: Since I'm sure a lot of these devs are having their first brush with actual standards development, that mismatch is to be expected.
  963. # [17:46] <necolas> I just wish there had been better communication
  964. # [17:46] * Philip` thinks there ought to be a way of standardising the technically best solution without also alienating people who have proposed other solutions
  965. # [17:46] <necolas> TabAtkins_: this has nothing to do with whos solution is getting used
  966. # [17:47] <TabAtkins_> necolas: Do you think the discussion is completely over and this is a fait accompli? That's incorrect.
  967. # [17:47] <dglazkov> good morning, Whatwg!
  968. # [17:47] <necolas> I really don't think devs are wedded to "their ideas" but are simply looking to be included in discussions and have their interests heard.
  969. # [17:47] * gwicke is now known as gwicke_away
  970. # [17:47] <adactio> What necolas said.
  971. # [17:47] <odinho> Philip`: Yes, sure. But it's not super easy if people feel hurt.
  972. # [17:47] <necolas> because, initially, responsive images was not of interest to you guys, we set up a CG
  973. # [17:47] <jgraham> Philip`: I guess we could drug all the people that back the wrong solution, so they are unaware that their solution didn't get picked
  974. # [17:47] <TabAtkins_> necolas: Again, I'm not sure how what has been happening is anything if not "hearing dev's interest".
  975. # [17:48] * Quits: seventh (seventh@69.80.107.71) (Remote host closed the connection)
  976. # [17:48] <necolas> and Wilto put in a LOT of time. and if he feels upset, then you should look at how we can all avoid this kind of thing in the future
  977. # [17:48] <TabAtkins_> I mean, responsive images are in the spec now, when before they weren't, and it's *entirely* due to the work of devs, mostly in the CG.
  978. # [17:48] <TabAtkins_> How is this anything other than "you win, your arguments were right, here's a solution for your problem".
  979. # [17:49] <necolas> jgraham: that doesnt sound like an unpleasant experience :)
  980. # [17:49] <necolas> TabAtkins_: "thanks, we'll take over from here", right?
  981. # [17:49] * Joins: doublec_ (~doublec@cd.pn)
  982. # [17:49] <TabAtkins_> We didn't get together and politely ask everyoen which solution they liked the most and hold a vote. That's because HTML uses the benevolent-dictator model.
  983. # [17:49] * Quits: slartsa_ (~slartsa@vps-2498-1.tilaa.nl) (Read error: Operation timed out)
  984. # [17:49] * Quits: doublec (~doublec@unaffiliated/doublec) (Read error: Operation timed out)
  985. # [17:49] <jgraham> The problem with being upset in technical discussions is that it doesn't scale very well.
  986. # [17:49] <TabAtkins_> (Also because voting is usually a bad way to make technical decisions.)
  987. # [17:49] <jgraham> You would end up being upset a lot of the time
  988. # [17:50] <odinho> Noone has really given any feedback of why they don't like the new thing though. - There is also lots of intermixing of different problems that are solving different things.
  989. # [17:50] <dglazkov> oh cool, browserfolk vs. webdevfolk
  990. # [17:50] <TabAtkins_> necolas: You are more than welcome to provide feedback on the solution that Hixie proposed, though. That's what I'm doing, for example.
  991. # [17:50] <zcorpan> fight!
  992. # [17:50] * dglazkov is both. Should I be arguing with myself?
  993. # [17:50] <jgraham> Certianly *I* would if I was upset every time my initially-preferred solution didn't make the final spec
  994. # [17:50] <necolas> imo, this isnt purely about the technical details. we're not asking for votes (even though that seems to sometimes get used for CSS specs).
  995. # [17:50] <zcorpan> dglazkov: clearly you should hit yourself in your face
  996. # [17:50] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  997. # [17:50] * Joins: Obvious (tachikoma@188.226.74.2)
  998. # [17:50] <dglazkov> zcorpan: and enjoy it
  999. # [17:50] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  1000. # [17:51] <hober> dglazkov: count me in! /me hits himself in the face too :)
  1001. # [17:51] * jgraham still thnks we should have done MathML by making browsers understand something like LaTeX
  1002. # [17:51] <necolas> jgraham: well, as devs, we're used to our "awesome solution" being trashed and reimagined by someone else in the OSS community. so i guess we don't care so much :)
  1003. # [17:51] <jgraham> Oh, right, Tuesday night is S&M night
  1004. # [17:51] <odinho> I think many of us "browserfolk" actually are former/present webdevs as well. I'm still more dev than browserfolk still after being in for so little.
  1005. # [17:51] <zcorpan> jgraham: that was on the table before we put mathml in to html, wasn't it?
  1006. # [17:52] <jgraham> zcorpan: Well I tried to convivce Hixie it was a good idea then
  1007. # [17:52] * Quits: Obvious_MkII (tachikoma@188.226.74.2) (Ping timeout: 255 seconds)
  1008. # [17:52] <jgraham> I guess it would have been a lot of work
  1009. # [17:52] <jgraham> But afaict it is still the most popular way of including MathML in HTML
  1010. # [17:52] <jgraham> But implemented in Javascript
  1011. # [17:52] <annevk> he tried to think of a scheme that implied a lot of the markup
  1012. # [17:52] * Joins: slartsa (~slartsa@vps-2498-1.tilaa.nl)
  1013. # [17:52] <annevk> but that didn't work out
  1014. # [17:53] * Joins: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
  1015. # [17:53] <zcorpan> annevk: iirc real LaTeX was also considered
  1016. # [17:53] <dglazkov> whoa, how did we just switch from srcset to mathml?
  1017. # [17:53] <dglazkov> is this the equivalent of Godwin's law in the standards discussions?
  1018. # [17:53] * Joins: scottjehl (u3055@gateway/web/irccloud.com/x-negzqnxitrusiewh)
  1019. # [17:53] <dglazkov> once LaTeX is mentioned...
  1020. # [17:53] <necolas> odinho: oh of course. there are many aspects of being a web developer
  1021. # [17:53] <miketaylr> probably all the punching in the face
  1022. # [17:53] <annevk> necolas: so Hixie did reply in length to the various emails on the subject so saying the CGs input was not even considered seems wrong
  1023. # [17:54] <scottjehl> hello!
  1024. # [17:54] <necolas> annevk: i didn't say that
  1025. # [17:54] <TabAtkins_> odinho: I don't think that "most" browser people were webdevs. Some. But a significant fraction of the CSSWG, frex, has never written a non-trivial site. ^_^
  1026. # [17:55] <odinho> TabAtkins_: Hehe, okay. In my limited experience in Opera though, most people were webdevs :-)
  1027. # [17:55] <hober> TabAtkins_: that's why you, me, and some other people get to try to make sure that wg keeps it real. :)
  1028. # [17:55] <TabAtkins_> odinho: Opera might be different, I dunno.
  1029. # [17:56] <TabAtkins_> necolas: The bottom line is, if you don't like the solution, say so. Complaining about process is *very rarely* productive, however.
  1030. # [17:56] <adactio> hober: I'm curious. In your email to the WHATWG on May 10th when you proposed srcset, why didn't you mention the Responsive Images Community Group? Were you genuinely unaware of its existence?
  1031. # [17:56] <TabAtkins_> necolas: (But, hopefully, don't rehash criticisms that have already been answered, unless you have new information.)
  1032. # [17:56] <necolas> even with web devs in the whatwg, i hope you still believe it is worthwhile to have input from people outside the whatwg who are building large and complex sites with these technologies
  1033. # [17:56] <zcorpan> just saying "this is not what i want!" is also not very useful, though.
  1034. # [17:57] <necolas> that is not what i was saying
  1035. # [17:57] <TabAtkins_> necolas: Once again, that is *exactly* what happened in this case.
  1036. # [17:57] <necolas> i think it is fair to discuss the way that things get done
  1037. # [17:57] <zcorpan> necolas: sorry, i didn't mean you, i just saw some bugs filed along those lines
  1038. # [17:57] <TabAtkins_> necolas: A few webdevs suggested something, it got shot down, more came together and made a cogent case, it was accepted. That's exactly how things should work.
  1039. # [17:57] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  1040. # [17:57] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  1041. # [17:59] <TabAtkins_> adactio: From what I understand, hober had written that email a few weeks ago (around the time he wrote the email proposing image-set() for CSS), he just hadn't gotten around to sending it. Hixie talking about adding it into the spec made him hurry up. ^_^
  1042. # [17:59] <TabAtkins_> adactio: I believe the timing meant that at the time of writing, the CG was either not started yet, or just starting.
  1043. # [17:59] <necolas> TabAtkins_: I dont know how else to explain to you that your vision of events isn't how many people in the CG feel. so either way, there has been a communication breakdown which is worth accepting as not-ideal
  1044. # [18:00] <hober> adactio: sorry, about to get off the bus. be back in <30 min; for now, http://krijnhoetmer.nl/irc-logs/whatwg/20120511#l-202
  1045. # [18:00] <TabAtkins_> necolas: I'm quite certain there are people who dont' feel it went down that way. Unfortunately, that is *always* the case. I think I'm *extraordinarly* receptive to the input of other webdevs (because I was one, and still am in a limited capacity), but I still get people angry when I don't take their solution.
  1046. # [18:01] <TabAtkins_> necolas: I don't like to characterize it as sour grapes, but that's what it feels like to me.
  1047. # [18:01] <necolas> well you'd be wrong
  1048. # [18:01] <necolas> and i don't think you should dismiss this like that
  1049. # [18:02] <TabAtkins_> necolas: I know that, for example, Wilcox is unhappy that his specific solution wasn't used. It has some merits beyond @srcset, but also some strong weaknesses (which I brought up in the thread that Wilto started).
  1050. # [18:02] <necolas> most of us have pretty much nothing invested in the ideas themselves - they all came in some form from earlier mailing list ideas.
  1051. # [18:02] <necolas> TabAtkins_: hah, but wilcox is always unhappy :)
  1052. # [18:02] <adactio> TabAtkins_: It's not about an alternate solution being *rejected* so much as the existence of an alternate solution (in development for months) being acknowledged at all.
  1053. # [18:02] <TabAtkins_> Overall I find it an unacceptable solution without changes, and even then, the fact that it relies on brand-new functionality like URL rewriting and MQ variables makes it a harder sell than @srcset.
  1054. # [18:03] <necolas> definitely
  1055. # [18:03] <TabAtkins_> necolas, adactio: If it's about feeling bad because you don't think you were adequately credited, then I think that's an ego problem. ^_^
  1056. # [18:03] <jgraham> That particuolar solution would probably require a huge amount of spec work to turn into something usavle, and then be hideously complex to implement so it was either not implemneted for ages, or implemented in a very buggy way
  1057. # [18:04] <necolas> TabAtkins_: [facepalm] it's not about ego either
  1058. # [18:04] <jgraham> *usable
  1059. # [18:04] <TabAtkins_> necolas: Quote from Hixie's email " thank you to everyone for making very good points, both here on the list and on numerous blog posts and documents on the Web, referenced from these threads".
  1060. # [18:05] <necolas> People put a lot of work and time into that group. They just dont want to feel like it was wasted. Feeling invested in the technologies we use and feeling in partnership with the people taking time to make the specs...is a good thing.
  1061. # [18:06] <necolas> TabAtkins_: have that kind of thing filter down to the CG itself would be a great start
  1062. # [18:06] <TabAtkins_> necolas: It's there own choice to feel like it was wasted. Given the fact that we went from (1) idea was rejected, (2) CG was formed, people made good arguments, (3) idea was accepted, it's clear that the time *was* useful.
  1063. # [18:06] <TabAtkins_> necolas: Feel free to forward the email to the CG, then!
  1064. # [18:07] <TabAtkins_> bbiab
  1065. # [18:07] <scottjehl> just catching up here, but I see there are criticisms of syntax, and criticisms of srcset's applicability today. The latter is more critical. I posted some concerns on that today. Are these not valid? (perhaps they were already mentioned above..?) https://gist.github.com/2701939#gistcomment-319724
  1066. # [18:07] * Parts: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
  1067. # [18:07] <adactio> TabAtkins_: Are you being wilfully obstreperous? A solution was proposed (srcset) without knowledge of the existing proposal (picture). Once the existence was acknowledged, instead of evaluating both on their merits, one was chosen simply because it came from inside the WHATWG — *not* on merit.
  1068. # [18:07] * Joins: niloy (~niloy@61.12.96.242)
  1069. # [18:07] <Wilto> So.
  1070. # [18:07] <divya> adactio: fwiw there are some concerns raised about picture element
  1071. # [18:07] <annevk> adactio: actually hober knew about <picture>
  1072. # [18:08] <divya> as there are w.r.t srcset.
  1073. # [18:08] <annevk> adactio: and used that in his evaluation
  1074. # [18:08] <zewt> (hard to take people seriously when they use words like "obstreperous")
  1075. # [18:08] <necolas> Tab, I'm only trying to highlight something that you don't seem to have been aware of, and instead of thinking that - whatever the reason - developer dissatisfaction is worthy of concern, you don't.
  1076. # [18:08] <odinho> scottjehl: If giving feedback, it has to be on the mailing list for it to be seen and replied to.
  1077. # [18:08] <divya> (lol zewt)
  1078. # [18:08] <annevk> adactio: and <picture> and variants has come up since 2007 or so
  1079. # [18:08] <annevk> adactio: it's not a recent invention
  1080. # [18:08] <zewt> odinho: heh my thought was "we're hiding discussions away on github now?"
  1081. # [18:08] <Wilto> My concern is that I was asked to furnish a list of use cases, potential polyfilling decisions, and _provide citation of developer sentiment_ before our proposal would be so much as considered.
  1082. # [18:08] <annevk> adactio: popped up shortly after I proposed <video> I think
  1083. # [18:08] <adactio> zewt: Apologies. I'll try not to use words of more than three syllables from now on. *sheesh*
  1084. # [18:09] <zewt> (sarcasm is worse)
  1085. # [18:09] <Wilto> Meanwhile, the only missive from the WHATWG on `img set` seems to be this: http://junkyard.damowmow.com/507
  1086. # [18:09] <necolas> annevk: re:2007, that's exactly why the CG people don't have any ego invested in the proposals - we didn't invent anything fundamentally new
  1087. # [18:09] <Wilto> So I’m left to wonder if those were just tasks to get me our of everyone’s hair, or if I was simply being humored.
  1088. # [18:09] <Wilto> And moreover, to wonder whether any `process` exists here in the first place.
  1089. # [18:10] <Wilto> Or if merit is simply based on the fact that things were—or were not—“invented here.”
  1090. # [18:10] <annevk> Wilto: the way the WHATWG works is that people email and the editor takes those emails and produces a proposal
  1091. # [18:10] <annevk> Wilto: usually that proposal goes directly in the spec, sometimes he puts up something on damwmow.com or other
  1092. # [18:10] <Wilto> annevk: The bottom line is that the `img set` pattern is largely indefensible—and no effort at defending it with citations and documentation have even been made.
  1093. # [18:10] <Wilto> This was a decision made in a vacuum. Let’s not pretend there was any process involved.
  1094. # [18:11] * Joins: Guest1064 (~anonymous@87.115.113.220)
  1095. # [18:11] <Wilto> The only repeated defense has been “this is easier for implementors.”
  1096. # [18:11] <annevk> Wilto: people emailed, Hixie replied with a proposal...
  1097. # [18:11] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
  1098. # [18:11] <Wilto> And Hixie proceeded despite the response.
  1099. # [18:11] <annevk> Wilto: I guess you haven't read the email then
  1100. # [18:11] <necolas> annevk: so what are the CG designed for, just so we know in the future?
  1101. # [18:12] * Quits: jochen__ (jochen@nat/google/x-snbxeiczyyqshrne) (Remote host closed the connection)
  1102. # [18:12] <Wilto> I don’t care how many times I’m told “we considered feedback.”
  1103. # [18:12] * Joins: jochen__ (jochen@nat/google/x-qodgpcnmgjesufuh)
  1104. # [18:12] <annevk> necolas: the WHATWG has a WHATCG for patent reasons
  1105. # [18:12] <Wilto> If none of that feedback is incorporated, we’re just being humored further.
  1106. # [18:13] <annevk> necolas: I think in general they're used as a discussion group
  1107. # [18:13] <scottjehl> The developer support for picture is completely overwhelming, and very very public. A List Apart articles, w3c groups, loads of high profile tweets. How could this possibly be missed by anyone in this group?
  1108. # [18:13] <necolas> annevk: so, people discuss in a CG, then email hixie?
  1109. # [18:13] <odinho> Wilto: Have you read the feedback?
  1110. # [18:13] * Joins: Adam_ (4580040a@gateway/web/freenode/ip.69.128.4.10)
  1111. # [18:13] <Philip`> I like how the spec says "(Steps in synchronous sections are marked with .)" in my font
  1112. # [18:13] <annevk> necolas: there's never been a CG for any part of HTML before really; I'm not sure why people made one now
  1113. # [18:13] <Philip`> (Looks like there's meant to be some visible character there instead)
  1114. # [18:13] <Wilto> Let me be frank:
  1115. # [18:14] <zewt> (what does "developer support" mean? popularity is a fairly low factor in spec decisions, i think)
  1116. # [18:14] <annevk> necolas: making a CG when there's already a group for HTML seems like the mistake that was made here
  1117. # [18:14] <odinho> As tab wrote: Given the fact that we went from (1) idea was rejected, (2) CG was formed, people made good arguments, (3) idea was
  1118. # [18:14] <odinho> accepted, it's clear that the time *was* useful.
  1119. # [18:14] <Wilto> I do not care about Hixie’s opinion, any more than anyone should care about mine.
  1120. # [18:14] * Quits: Adam_ (4580040a@gateway/web/freenode/ip.69.128.4.10) (Client Quit)
  1121. # [18:14] <zewt> (bad ideas can become popular)
  1122. # [18:14] * Joins: adamdbradley (4580040a@gateway/web/freenode/ip.69.128.4.10)
  1123. # [18:14] <Wilto> This is all, frankly, a little sad.
  1124. # [18:14] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 256 seconds)
  1125. # [18:14] <Wilto> I’ve seen seen no defense of `img set` on technical merit.
  1126. # [18:15] <Wilto> Where are the published use cases?
  1127. # [18:15] <necolas> annevk: wow. the w3c set up the CG model - there are many. we discussed in the responsive images one. there is one for mobile stuff that includes facebook devs. are we all wasting our time in the community groups?
  1128. # [18:15] <odinho> Wilto: ...?
  1129. # [18:15] <necolas> if yes, then shut them all down
  1130. # [18:15] <annevk> necolas: we're not the W3C
  1131. # [18:15] <necolas> yeah, i was just talking aloud
  1132. # [18:15] <Wilto> odinho: You know: that thing I was asked to do, before `picture` could ever be taken seriously? http://wiki.whatwg.org/wiki/Adaptive_images
  1133. # [18:15] * Quits: nessy (~Adium@124-169-129-81.dyn.iinet.net.au) (*.net *.split)
  1134. # [18:15] * Quits: pererik_ (~pe@unaffiliated/pererik) (*.net *.split)
  1135. # [18:15] * Quits: Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp) (*.net *.split)
  1136. # [18:15] * Quits: rektide (~rektide@deneb.eldergods.com) (*.net *.split)
  1137. # [18:15] <odinho> Wilto: Have you read the full threads on WHATWG, and are you honestly meaning that?
  1138. # [18:15] * Joins: rektide_ (~rektide@deneb.eldergods.com)
  1139. # [18:16] <necolas> but if people are being sent to CG's, and they have no worth, then that isn't great
  1140. # [18:16] <annevk> necolas: and most CGs are not about changing HTML
  1141. # [18:16] <Wilto> Where have you guys landed on the technical viability of polyfilling the `img set` pattern? Have you decided that isn’t a major consideration?
  1142. # [18:16] <annevk> necolas: if you want to change HTML you should not set up a CG, for anything else they're probably great
  1143. # [18:16] <jgraham> necolas: You are wasting your time if you're trying to get browsers to change something and don't have browser vendors on board
  1144. # [18:16] <necolas> so HTML CG's are worthless, CSS CG's are ?, other CG's are ?
  1145. # [18:16] <odinho> Wilto: It's easy to polyfill. Tell us why it's not.
  1146. # [18:16] <annevk> necolas: I don't think there are CSS CGs either
  1147. # [18:17] <odinho> 17:33 < odinho> necolas: <img srcset="cat.jpg, cat@2.jpg 2x"><noscript><img src=cat.jpg></noscript> <---- you can polyfill that without 2 HTTP requests.
  1148. # [18:17] <scottjehl> zewt: it works without overhead or accessibility drawbacks in existing browsers, with fallbacks. Developers have merely been waiting on a spec or browser implementation to validate something they already can use.
  1149. # [18:17] <necolas> jgraham: does srcset have browser vendors on board?
  1150. # [18:17] <Wilto> odinho: That will result in two requests in browsers with JS on.
  1151. # [18:17] <necolas> i bet that more people working for browser vendors were aware of our CG than this proposal
  1152. # [18:17] <odinho> Wilto: No, it will not. Take a new look. No src attribute.
  1153. # [18:17] <jgraham> necolas: Browser vendors pay attention to the WHATWG at least
  1154. # [18:17] <adactio> So much for the priority of constituencies.
  1155. # [18:17] <scottjehl> odhino src is required via the HTML spec
  1156. # [18:17] <Wilto> odinho: So, in non-supporting browsers without JavaScript: no image.
  1157. # [18:17] <odinho> scottjehl: Easy to change.
  1158. # [18:17] <jgraham> adactio: What nonsense
  1159. # [18:18] <Wilto> odinho: With JavaScript, rather.
  1160. # [18:18] <scottjehl> not in existing browsers
  1161. # [18:18] <gsnedders> adactio: If impls won't support something, then a change doesn't help users.
  1162. # [18:18] <odinho> Wilto: Oh, you have to actually write the polyfill of course. :-) But that's easy.
  1163. # [18:18] <Wilto> If we’re being honest, the WHATWG is completely entrenched.
  1164. # [18:18] <scottjehl> my gist linked above explores as much, but I'm happy to post it wherever it needs to be so it'll be read
  1165. # [18:18] <Wilto> Arguing here won’t change anything.
  1166. # [18:18] <zewt> (is wilto just trolling?)
  1167. # [18:18] <zewt> (sure smells like it)
  1168. # [18:18] <jgraham> zewt: I hope not
  1169. # [18:18] <odinho> scottjehl: They don't throw any exceptions or anything if you omit the src.
  1170. # [18:19] * Joins: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
  1171. # [18:19] <odinho> scottjehl: It's perfectly doable.
  1172. # [18:19] <Wilto> odinho, zewt, jgraham: I’ve posted scottjehl’s gist covering why polyfills may not be possible.
  1173. # [18:19] * Joins: dydx (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net)
  1174. # [18:19] * Quits: dydx (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net) (Client Quit)
  1175. # [18:19] <adactio> jgraham: From what you're saying, whatever solution browser makers want is what ends up getting specced. Even if it's not what developers want. That's the very opposite of the priority of constituencies.
  1176. # [18:19] <odinho> I've read it.
  1177. # [18:19] <Wilto> Can you prove otherwise, odinho?
  1178. # [18:19] <Wilto> I’d love to see some code.
  1179. # [18:20] <Philip`> scottjehl: Existing browsers don't care what the HTML spec says is a valid document; there's a totally separate set of instructions for how they must process documents regardless of validity (which in the case of missing or empty src attribute, says they don't download anytthing)
  1180. # [18:20] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
  1181. # [18:20] <jgraham> adactio: What I said is that if you are discussing somethjing where there are no browser makers involved, it is very unlikely that they will implement it
  1182. # [18:20] <Philip`> scottjehl: (Also, that's somewhat separate from what current browsers actually do in practice - they might not implement what the spec says they must)
  1183. # [18:20] <krijnh> Wilto: digital beers received, thanks! :)
  1184. # [18:20] <jgraham> That's just common sense.
  1185. # [18:20] <gsnedders> adactio: Spec'ing what developers want if browsers won't impl it doesn't help the developers.
  1186. # [18:20] <jgraham> But the priority of constituencies doesn't give authors magical powers
  1187. # [18:21] * Joins: pererik (~pe@c-89-233-213-67.cust.bredband2.com)
  1188. # [18:21] * Joins: nessy (~Adium@124-169-129-81.dyn.iinet.net.au)
  1189. # [18:21] * Joins: Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp)
  1190. # [18:21] <Philip`> scottjehl: (I don't know if anywhere reliably documents what current browsers do actually do in this case)
  1191. # [18:21] <jgraham> If browser vendors agree that a different spec will work better for end users they will adopt the better spec
  1192. # [18:22] <Wilto> So if `picture` is provably better in terms of use cases, polyfills, and developer sentiment: what exactly—aside from “this is easier for —was the reason `img set` was codified instead?
  1193. # [18:22] <Wilto> easier for implementors*
  1194. # [18:22] <zewt> developers often want things they can't have, like more synchronous APIs in the UI thread
  1195. # [18:22] <jgraham> Wilto: If it is provably better, please prove it
  1196. # [18:22] <Wilto> zewt: This isn’t about doing what’s best for some petulant developers.
  1197. # [18:22] <scottjehl> alt text is shown in some non-JS environments for one, followed by the noscript img fallback. It's odd behavior for a recommended approach. I guess I'd expect these things would be tested before pushing out a recommendation. A lot of work has gone into ensureing picture is bulletproof today. I'm assuming some browsers will show a broken img icon without a src, but given that this spec came out wit
  1198. # [18:22] <scottjehl> h so little precedence, we've yet to test how src-less images behave in existing browsers
  1199. # [18:22] <annevk> Wilto: afaik <picture> does not address the pixel density use case
  1200. # [18:22] <Wilto> With citations, documentation, etc.? I have, zewt.
  1201. # [18:23] <zewt> what?
  1202. # [18:23] <jgraham> I really haven't seen that many emails making technical objections to @srcset or arguments in favour of <picture>
  1203. # [18:23] <Wilto> Y’know, nevermind.
  1204. # [18:23] <adactio> jgraham: But that's my whole point: this hasn't been about what's better. It's been about where proposals are made (WHATWG) and who makes them (hober), *not* on merit.
  1205. # [18:23] <jgraham> Just lots of assertions taht developers prefer <picture>
  1206. # [18:23] <necolas> jgraham: but where is the proff srcset is better?
  1207. # [18:23] <necolas> s/proff/proof
  1208. # [18:23] <annevk> adactio: you don't think what Hixie wrote illustrates why srcset was chosen?
  1209. # [18:23] <Wilto> jgraham: http://www.w3.org/community/respimg/
  1210. # [18:23] <necolas> it's a strange point to make
  1211. # [18:23] <jgraham> necolas: Various arguments in its favour have been made
  1212. # [18:23] <Wilto> The “lots of assertions” are from developers.
  1213. # [18:24] * rektide_ is now known as rektide
  1214. # [18:24] <jgraham> It doesn't reuse an different feature in a mostly incompatible way
  1215. # [18:24] <jgraham> It is relatively concise to author
  1216. # [18:24] <jgraham> It is much easier for UAs to process
  1217. # [18:24] <Wilto> Authors have stated that they don’t prefer the concise syntax, so let’s not pretend that’s still a factor here.
  1218. # [18:24] <jgraham> (and therefore less likely to be buggy)
  1219. # [18:25] <Wilto> Else, we’re just in denial.
  1220. # [18:25] <Wilto> jgraham: Can you prove that “mostly incompatible” statement?
  1221. # [18:25] <jgraham> To be honest, most authors have never been asked, and no one seems to have actually tried both
  1222. # [18:25] <Wilto> I stress that the WHATWG wiki is publicly editable; I’d love to see a reasoned response to use cases.
  1223. # [18:25] <Wilto> jgraham: Those we asked preferred picture. I’m sure you’re not saying “we didn’t ask everyone.”
  1224. # [18:26] <zewt> i'm an author and i sure prefer concise syntax
  1225. # [18:26] * annevk too
  1226. # [18:26] <Wilto> zewt: That’s a factor, then, among the many voices we’ve heard from.
  1227. # [18:26] <jgraham> Wilto: Sure. Almost all of media queries isn't appropriate for this feature and so it is confusing to make it look like it is reusing media queries
  1228. # [18:26] <Wilto> Two more for `img src`.
  1229. # [18:26] <divya> zewt: most authors prefer what is easiest to understand
  1230. # [18:26] * Quits: Taggnostr (~quassel@dyn57-365.yok.fi) (Read error: No route to host)
  1231. # [18:26] <divya> not what is most concise.
  1232. # [18:27] * Joins: Taggnostr (~quassel@dyn57-365.yok.fi)
  1233. # [18:27] <annevk> Wilto: so that wiki page; what it says for high resolution displays does not actually work
  1234. # [18:27] <Wilto> zewt, annevk: Perhaps you could join the other developers commenting on http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/
  1235. # [18:27] <jgraham> The problem with this kind of "preference" thing is that it is rather hard to tell much from first impressions
  1236. # [18:27] <scottjehl> jgraham: why does it make sense for <video> but not <picture>?
  1237. # [18:27] <necolas> that goes both ways
  1238. # [18:27] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1239. # [18:28] <annevk> scottjehl: it's not exactly clear media="" makes sense for <video>
  1240. # [18:28] <jgraham> scottjehl: I don't think it does make sense for <video>; only Opera implement it and we suggested dropping it
  1241. # [18:28] <zewt> Wilto: that is not where whatwg discussions take place; if you want people to see a conversation, have it on the list where it belongs
  1242. # [18:28] <Wilto> jgraham: I assume the first impression of a few hundred developers is likely worth as much as the opinions of a few “key decision makers.”
  1243. # [18:28] <annevk> scottjehl: it's even implemented by all browsers; <video> has it mostly for type=""
  1244. # [18:28] <Wilto> zewt: So you’re stating that—because of the forum—those opinions have been disregarded by the WHATWG.
  1245. # [18:28] <annevk> scottjehl: and for <track>
  1246. # [18:28] * Quits: MacTed (~Thud@63.119.36.36) (Ping timeout: 244 seconds)
  1247. # [18:28] <jgraham> Wilto: I don't know how to solve problems in that algebra
  1248. # [18:29] <zewt> uh, i'm saying that discussions should take place in a place where people will see them, not hidden away in blog comments
  1249. # [18:29] <Wilto> jgraham: That much is obvious.
  1250. # [18:29] <Wilto> zewt: It was posted to the list twice.
  1251. # [18:29] <jgraham> Wilto: It would be more convincing if someone actually implemented both and tried them out
  1252. # [18:29] * Joins: jreading (~Adium@ip98-169-200-82.dc.dc.cox.net)
  1253. # [18:29] <zewt> (tip: you're going to find it hard to convince people of anything when you make everyone squint through a thick pane of annoyance and snarkiness; it's tiring and most of us have other places to spend our energy)
  1254. # [18:29] * Joins: Guest1064 (~anonymous@87.115.113.220)
  1255. # [18:30] <necolas> jgraham: scottjehl already made a <picture> polyfill
  1256. # [18:30] <Wilto> zewt: Would you prefer I encouraged all those commenters to post their +1s on the mailing list?
  1257. # [18:30] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
  1258. # [18:30] <necolas> it would be easy to make one for srcset and then see how people get on with using them
  1259. # [18:30] * Joins: ap (~ap@2620:149:4:1b01:8c01:d49c:4306:e324)
  1260. # [18:30] <Wilto> zewt: Happy to do so, if that’s the only way their votes will be factored in. I assumed that would be less than ideal.
  1261. # [18:30] <jgraham> necolas: So where is the srcset one for comparison?
  1262. # [18:30] <jgraham> Ah you said that
  1263. # [18:31] <necolas> jgraham: no one has made it yet
  1264. # [18:31] <jgraham> apologies
  1265. # [18:31] <Wilto> jgraham: Good question.
  1266. # [18:31] <zewt> "+1s" aren't considered much of a factor at all
  1267. # [18:31] <scottjehl> jgraham: 1) picturefill already works today, and we've tested it exhaustively in jQuery Mobile's device lab - loads of existing devices, no overhead drawbacks. https://github.com/scottjehl/picturefill/
  1268. # [18:31] <Wilto> zewt: So, developers cannot simply vote on their own preferences.
  1269. # [18:31] <Wilto> zewt: I would _love_ to quote you on that.
  1270. # [18:31] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  1271. # [18:31] <jreading> <picture> is too much markup FWIW
  1272. # [18:31] <zewt> apis should be based on technical merit, not petitions
  1273. # [18:32] <Wilto> Absolutely, zewt. Developer sentiment is a factor only as much as implementor sentiment.
  1274. # [18:32] <Wilto> Technical merit is key.
  1275. # [18:32] * Joins: gavinc (~gavin@barad-dur.carothers.name)
  1276. # [18:32] <gsnedders> The only non-technical thing that matters is usability, and that's more than just first-look opinion.
  1277. # [18:32] * Joins: jarib (~jarib@unaffiliated/jarib)
  1278. # [18:32] <scottjehl> jgraham: 2) some concerns around making a polyfill for imgset are here: https://gist.github.com/2701939#gistcomment-319735 (I was told to post to the wg list and I'm happy to)
  1279. # [18:32] <miketaylr> (re: +1, http://wiki.whatwg.org/wiki/FAQ#.2B1)
  1280. # [18:32] <Wilto> jgraham: I posted it to the list easlier today, as well.
  1281. # [18:33] * Joins: krijn (u2319@gateway/web/irccloud.com/x-uwcbdcwelkyjekca)
  1282. # [18:33] * hober catches up again
  1283. # [18:33] <Wilto> If you’re in the mood for prose, more of those technical challenges are detailed at http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ and http://www.netmagazine.com/features/state-responsive-images
  1284. # [18:33] <Wilto> Again: posted to the list multiple times.
  1285. # [18:33] <hober> adactio: "A solution was proposed (srcset) without knowledge of the existing proposal (picture)" is untrue; i was aware of the CG's work
  1286. # [18:33] <jgraham> scottjehl: Those technical challenges hardly seem insurmountable
  1287. # [18:34] * Joins: sedovsek (~robert@93-103-104-107.dynamic.t-2.net)
  1288. # [18:34] * Quits: sedovsek (~robert@93-103-104-107.dynamic.t-2.net) (Read error: Connection reset by peer)
  1289. # [18:34] <hober> adactio: when I wrote the srcset draft (which was a long time before i hit send, as TabAtkins mentioned), I had been working on two drafts
  1290. # [18:34] * Quits: Lachy (Lachy@nat/opera/x-anyekuhbgiqyykzk) (Quit: Computer has gone to sleep.)
  1291. # [18:34] <hober> adactio: one was the srcset proposal, and one was a "why i don't think <picture> is a good idea" post
  1292. # [18:34] <hober> actually, iirc they started out as one email but the second part was getting really long and unweildy and needed editing
  1293. # [18:35] <hober> so i split it up
  1294. # [18:35] <hober> and didn't actually send any of it because of, err, i have no idea that was a long time ago
  1295. # [18:35] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  1296. # [18:35] <necolas> jreading: im sure that could be overcome. we shouldnt turn this into @srcset vs <picture> - there may be positives from both that could lead to something beter
  1297. # [18:35] <scottjehl> jgraham: perhaps, but they're there. and there are none for picture. It seems like a proposal should follow this sort of experimentation to verify if it's useful today before any spec is drafted
  1298. # [18:35] * Joins: mplehman (~mplehman@71-87-1-124.static.eucl.wi.charter.com)
  1299. # [18:35] <hober> anyway, while at the css f2f there was some irc chatter about this, so i thought hold on a sec, i have something drafted
  1300. # [18:36] <hober> pulled up and sent the srcset email
  1301. # [18:36] * Joins: MacTed (~Thud@63.119.36.36)
  1302. # [18:36] * Joins: niloy (~niloy@61.12.96.242)
  1303. # [18:36] <TabAtkins_> Wilto: I'm pretty sure the technical challenges of polyfilling are insurmountable. You have only two choices: (1) Do something that involves having an <img src> in the document (and thus produces two requests in polyfilled browsers), or (2) Do something that *doesn't* involve having an <img src> in the document (and thus fails entirely in legacy browsers unless the polyfill runs).
  1304. # [18:36] <hober> which iirc says that i'll tackle <picture> in another email
  1305. # [18:36] <TabAtkins_> There's no syntax that can get around that.
  1306. # [18:36] <hober> i just haven't sent that other email yet, because i haven't finished writing it
  1307. # [18:38] <adactio> hober: Okay. It's a shame that the excising of your email gave the impression that you were proposing in isolation.
  1308. # [18:38] <scottjehl> tabatkins: "and thus fails entirely in legacy browsers unless the polyfill runs)." That can be easily avoided with a noscript fallback. noted in picturefull repo, and noscript would be necessary for any polyfill of srcset anyway
  1309. # [18:38] * Joins: izhak (~izhak@188.168.201.226)
  1310. # [18:39] <jgraham> scottjehl: <picture> does seem to have the same disadvantages though. Encouraging people not to add <img src> except via script seems like a problem
  1311. # [18:39] <jgraham> Since they are quite likely to just forget
  1312. # [18:39] <scottjehl> jgraham: sorry, can you clarify?
  1313. # [18:40] <jreading> necolas: perhaps there a way to stay DRY with <picture>, but it seems like so much cruft
  1314. # [18:40] <scottjehl> hmm. plenty of standard features require careful syntax to bulletproof: @font-face is a good example of success in that
  1315. # [18:41] <jgraham> Preumably you either add <img> in normal (not <noscript>) markup and get an extra HTTP request in the polyfill case, or you make graceful fallback difficult, increasing the chance that someone will forget to do it
  1316. # [18:41] <scottjehl> jgraham: have you looked at how picturefill works?
  1317. # [18:41] <TabAtkins_> scottjehl: Yup, that's an interesting hack around the problem. Requires duplication, but it works in all situations. What's not to like?
  1318. # [18:42] <scottjehl> I think it addresses your concerns
  1319. # [18:42] * Joins: toddmparker_ (u3054@gateway/web/irccloud.com/x-xrohawmublfleceb)
  1320. # [18:42] <adamdbradley> they both are handling two different things, lets combine both of them. Use the srcset format for resolution variants, and source elements for setting breakpoints inline
  1321. # [18:43] <hober> adactio: priority of constituencies is users over authors over etc.; i think <img srcset> is better for *users* than <picture> *for the use case <img srcset is designed to solve*
  1322. # [18:43] <adactio> hober: What I don't understand is why you weren't told "Provide use cases! What about backwards-compatibility?" (which is what other people would've been told). Instead your proposal was added to the spec just like that *snaps fingers*.
  1323. # [18:43] <adactio> hober: This all seems far less about merit and far more about who's making the proposal (exactly what TabAtkins_ said shouldn't be happening).
  1324. # [18:44] <TabAtkins_> adamdbradley: That's more verbose, though. It (or some variant) might be worthwhile if it can be shown that there are good use-cases for using more than just min/max-width MQs.
  1325. # [18:44] <hober> adactio: i think you perceive a causal relationship between me sending that email and hixie making his edits
  1326. # [18:44] <TabAtkins_> adactio: The CG took care of use-cases. Backwards compat was obvious.
  1327. # [18:44] <hober> adactio: that simply isn't there
  1328. # [18:44] <scottjehl> tabatkins: true of picture, yes. as for srcset, that's not verified, and apparently has never been tested. How do current mobile browsers render img elements without a src attribute? Can they be polyfilled? SRC been required in the spec since img was created - wouldn't that requirement factor into some browser implementations? Anyone tested this?
  1329. # [18:45] <jreading> srcset is horrible syntax anyway, picture is crufty, why don't we leverage existing, validate attributes, much in the way media queries were implemented…
  1330. # [18:45] <jreading> http://hellowurld.heroku.com/blog/2012/05/15/another-image-proposal-for-responsive-design/
  1331. # [18:45] <TabAtkins_> scottjehl: Requirements like "must provide a @src" are for authors, not implementors. Browsers treat a missing source like any other missing attribute.
  1332. # [18:45] <adactio> hober: Okay. I will try to avoid apopheniac interpretations.
  1333. # [18:45] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 260 seconds)
  1334. # [18:45] * Joins: Guest1064 (~anonymous@87.115.113.220)
  1335. # [18:45] <TabAtkins_> jreading: I and others have explained multiple times why MQs are inadequate for solving the multiple-resolution use-case.
  1336. # [18:46] <jreading> lowsrc (now obsolete) would prefetch if it came first in the attrs list...
  1337. # [18:46] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  1338. # [18:46] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
  1339. # [18:48] <scottjehl> tabatkins: my brief tests show they treat it very differently
  1340. # [18:48] * Joins: jsbell (jsbell@nat/google/x-qebgnrehpisxnvsk)
  1341. # [18:48] <TabAtkins_> Details?
  1342. # [18:49] <bjankord> Aynone have a recent recap, trying to figure out where the discussion is at?
  1343. # [18:50] <scottjehl> opera renders the image alt text as if the img was not found. I plan to test more, and perhaps there are no other issues, but I find it surprising this exploration wasn't done up front... maybe IE shows a broken image icon. Nobody knows is my point. This is surprising to me.
  1344. # [18:50] <scottjehl> (if no alt text, it spells out "IMAGE")
  1345. # [18:50] <hober> adactio: i agree that the impression of work-in-isolation is unfortunate
  1346. # [18:50] <TabAtkins_> Actually, that's exactly normal behavior. If you omit an attribute, it's value is the empty string. For url-valued attributes, that means "the current page". Which will never be a valid image in HTML.
  1347. # [18:51] <hober> [whee, only 13 minutes behind :)]
  1348. # [18:51] <TabAtkins_> So you'll get the "invalid image" fallback, which varies per browser.
  1349. # [18:51] * Joins: pablof (~pablof@144.189.101.1)
  1350. # [18:51] <TabAtkins_> adactio: If it makes anyone feel better, I can state definitely that the work of the CG was very useful and was important in designing what is currently in the spec.
  1351. # [18:52] <hober> adamdbradley: i agree that they are addressing different problems (resolution variation of bitmaps v. affordance for arbitrary design breakpoints)
  1352. # [18:52] <TabAtkins_> Hixie said as much in his draft, but people might have skipped past that sentence, or been miffed that the words "Responsive Images CG" didn't explicitly appear in the acks.
  1353. # [18:52] <TabAtkins_> On that point...
  1354. # [18:52] <TabAtkins_> Hixie: It might be nice to explicitly include the Responsive Images CG (as a unit) in the acks.
  1355. # [18:53] <hober> adactio: for all i know, i *will* be told that when hixie gets around to processing my email. :)
  1356. # [18:53] <adamdbradley> An image is content, but variants of the same image is presentation. Baking presentation in to HTML should be an option, but overall the preferred way is to solve this with CSS
  1357. # [18:53] * Quits: drublic (~drublic@frbg-5d84f2b2.pool.mediaWays.net) (Remote host closed the connection)
  1358. # [18:53] <necolas> here we go again
  1359. # [18:54] <scottjehl> adamdbradley: this is about content images. design is separate. it's about delivering assets per screen size and density. in a fluid layout, that's unrelated to design breakpoints
  1360. # [18:54] <TabAtkins_> adamdbradley: When the 'content' property gains the ability to make proper replaced images, and browsers let it apply to arbitrary elements like the spec says, it'll be doable in CSS. You have everything you need (once I add image-set() to CSS Images 4). It's just more verbose.
  1361. # [18:55] <necolas> adamdbradley: I already wrote about how this might be possible in CSS, but still has significant drawbacks - http://nicolasgallagher.com/responsive-images-using-css3/
  1362. # [18:55] <Wilto> adamdbradley: The CSS approach—even with proposed specs—will still result in a redundant request for clients that shouldn’t receive the original src.
  1363. # [18:56] <bjankord> scottjehl: I test img tag without src attr and alt text and alt text renders in IE6-IE9, FF, and Opera the same more or less, displaying the alt text
  1364. # [18:56] <scottjehl> same issue as imgset actually
  1365. # [18:56] <Wilto> bjankord: I don’t think we can say for certain that it won’t introduce issues in older browsers.
  1366. # [18:56] <Wilto> bjankord: Or any number of mobile browsers, since those tend to exhibit a great deal of variance in the way they handle markup errors.
  1367. # [18:57] <webben> both <picture> and srcset will result in a redundant request unless the <img> element is wrapped in <noscript>.
  1368. # [18:57] <bjankord> Wilto: Agreed
  1369. # [18:58] <necolas> TabAtkins_: "If it makes anyone feel better"... I'm disappointed that it seems no one here thinks something went wrong with the whatwg-developer-CG communication. Instead, it seems to be getting dismissed as ego.
  1370. # [18:59] <bjankord> It does seem like a hack that the only way to polyfill srcset is to remove the src attribute from the img tag and us JS to add it back in.
  1371. # [18:59] * Joins: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
  1372. # [18:59] <scottjehl> +1
  1373. # [18:59] <odinho> bjankord: Polyfills *are* hacks.
  1374. # [18:59] * Quits: adamdbradley (4580040a@gateway/web/freenode/ip.69.128.4.10) (Quit: Page closed)
  1375. # [18:59] <Wilto> bjankord: Absolutely.
  1376. # [18:59] <hober> necolas: fwiw, i do think that it's clear that some kind of communication breakdown has happened, and that that's unfortunate.
  1377. # [18:59] <odinho> That's the whole reason for them existing.
  1378. # [19:00] <bjankord> odinho: Agreed
  1379. # [19:00] <TabAtkins_> necolas: Sorry, that's all I'm seeing. Everyone was explicitly thanked for their contributions, and specific people were responded to when appropriate. If people still don't fill like they were adequately thanked, then shrug.
  1380. # [19:00] <hober> necolas: that said, most attempts to characterize that breakdown seem to me to be overly simple, us-v-them sorts of stories that don't help
  1381. # [19:00] <scottjehl> is it possible that imgset could still be reconsidered at this time? Is it possible for web developers' feedback to change it? I'm unsure whether web developers have a say, and if so, where we should be focusing our efforts/disapproval. Mailing list?
  1382. # [19:00] <odinho> bjankord: So I don't think you can hold that against srcset(!)
  1383. # [19:00] <hober> necolas: we should all try to learn from this in order to do better in the future
  1384. # [19:01] <Wilto> I second scottjehl’s question.
  1385. # [19:01] <necolas> TabAtkins_: as I keep saying, it's not about people not feeling "thanked"
  1386. # [19:01] <odinho> scottjehl: Yes. But you have to talk in use cases that are not being met.
  1387. # [19:01] * Quits: richw (b0236a65@gateway/web/freenode/ip.176.35.106.101) (Ping timeout: 245 seconds)
  1388. # [19:01] <necolas> you're basically not listening, which is part of the problem
  1389. # [19:01] <odinho> scottjehl: Or ground it on technical merit.
  1390. # [19:01] <hober> necolas: who is "you" in that?
  1391. # [19:01] <necolas> tab
  1392. # [19:01] <hober> necolas: it seems clear to me that many people are listeningto many other people :)
  1393. # [19:01] * Joins: bradee1 (~Adium@sjfw1.adobe.com)
  1394. # [19:02] <odinho> hober: English is such a inprecise language :P
  1395. # [19:02] <odinho> an*
  1396. # [19:02] <odinho> im*
  1397. # [19:02] <odinho> lol
  1398. # [19:02] <odinho> I kinda blew that, didn't I! :D
  1399. # [19:02] <hober> :)
  1400. # [19:02] <necolas> it's actually pretty patronising to just dismiss what several developers are saying as a problem with their egos, when it's clearly not
  1401. # [19:02] <Wilto> odinho: Can we quote you as saying that one should simply remove the `src` when creating a polyfill?
  1402. # [19:02] <bjankord> necolas: +1
  1403. # [19:03] <odinho> Wilto: I have written the polyfill. It works :-) I only need to test it a bit more. Don't have Windows handy right now, working on it.
  1404. # [19:03] <TabAtkins_> necolas: I'm sorry, but as far as I understand it, the problem is "I'm unhappy that the CG wasn't explicitly mentioned by name in Hixie's email." Am I wrong? If so, can you explain it to me better? I've been trying all morning to understand. ^_^
  1405. # [19:03] <bjankord> odinho: I can test in IE6-IE9 if you need it
  1406. # [19:03] <necolas> TabAtkins_: yeah you're wrong. and I think i've already explained that at least 3 times.
  1407. # [19:03] <Wilto> odinho: Cool. We’re agreed that we can’t guarantee backwards compatibility with the removal of the src, right?
  1408. # [19:04] <Wilto> If that’s the official stance coming out of the WHATWG, I’m happy to pass that information around.
  1409. # [19:04] <TabAtkins_> necolas: And all three times I've felt like I've gotten closer, but still am not right. I'll take that blame on myself, but still, I don't know what's wrong.
  1410. # [19:04] <TabAtkins_> Wilto: Wait wait wait. Clarification.
  1411. # [19:04] <odinho> Wilto: Guarantee is a very very strong word. -- But we can certainly test it many places, and see if it's a good enough solution. I very well think it may be.
  1412. # [19:04] <bjankord> Shit, can't read this fast
  1413. # [19:05] <TabAtkins_> Wilto: If you omit the @src from an <img>, in legacy browsers you will get the default "broken image" behavior. This varies per browser.
  1414. # [19:05] <hober> Wilto: what's "an official stance coming out of the WHATWG"? that's not how things work around here...
  1415. # [19:05] <TabAtkins_> Wilto: At least until the polyfill comes along and fixes it.
  1416. # [19:05] <odinho> Wilto, bjankord: Bear in mind that it's proof of concept more than anything. So haven't implemented the algo etc :P Someone else has to do the real work, but that should be doable.
  1417. # [19:05] <TabAtkins_> Wilto: Alternately, you can do something like use a data: url for a 0x0 image.
  1418. # [19:06] <TabAtkins_> Wilto: But that seems like more work than necessary.
  1419. # [19:06] * Quits: pablof (~pablof@144.189.101.1) (Read error: Connection reset by peer)
  1420. # [19:06] <bjankord> TabAtkins_: How does the polyfill handle users without JS
  1421. # [19:06] * Joins: pablof (~pablof@144.189.101.1)
  1422. # [19:06] <TabAtkins_> bjankord: polyfills *don't* handle users without JS. That's the point.
  1423. # [19:06] <bjankord> This is something scottjehl's picturefill is capable of
  1424. # [19:06] * Joins: tomasf (~tom@c-dedbe555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1425. # [19:06] <TabAtkins_> bjankord: If you want to support users without JS, use @src. But then you have two requests in legacy browsers with JS.
  1426. # [19:06] <TabAtkins_> There are unavoidable tradeoffs.
  1427. # [19:07] <webben> or use noscript
  1428. # [19:07] <Wilto> TabAtkins_: That’s hardly a _rule_. Better polyfills certainly do.
  1429. # [19:07] <adactio> TabAtkins_: Here's the problem. You are getting feedback on imgset (a fugly "solution" that authors won't grok) and you're dismissing those concerns with "Aw, you're just unhappy because your egos are bruised." It's patronising.
  1430. # [19:07] <mdelcx> is the prevailing opinion still that the <picture> tag is optimal?
  1431. # [19:07] <scottjehl> picture/picturefill avoids that
  1432. # [19:07] <scottjehl> and it's a huge concern
  1433. # [19:07] <Wilto> mdelcx: From the developer community, yes.
  1434. # [19:07] <odinho> How do you turn off js in chrome?
  1435. # [19:07] * Joins: grigs (~jason@67.131.102.78)
  1436. # [19:07] <bjankord> adactio: +1 +1 +1
  1437. # [19:07] <mdelcx> imset is a non-starter for me... poor spec
  1438. # [19:07] <Wilto> Agreed with adactio.
  1439. # [19:07] <webben> scottjehl: Avoids which?
  1440. # [19:07] <mdelcx> IMO, of course
  1441. # [19:07] <jgraham> adactio: You are getting requests to make technical comments and I haven't seen you make any. Others have made some, which is good.
  1442. # [19:08] <bjankord> odinho: Google it
  1443. # [19:08] <TabAtkins_> adactio: No. I simply am *unable* to tell what necolas is saying is wrong. It's not technical, it appears to be personal.
  1444. # [19:08] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
  1445. # [19:08] <odinho> bjankord: Actually did that ,found a nice one now though, -- it was so bad the first one. Thought there had to be better.
  1446. # [19:08] <TabAtkins_> scottjehl: No, <picture> doesn't really avoid it.
  1447. # [19:08] <scottjehl> I have a test page
  1448. # [19:08] <bjankord> TabAtkins_: Can you elaborate?
  1449. # [19:09] <TabAtkins_> scottjehl: With enough extra markup crap thrown at it, <picture> can be *as good* as <img src="data:0x0 image goes here" srcset="stuff">.
  1450. # [19:09] <scottjehl> but without any http overhead
  1451. # [19:09] <scottjehl> http://scottjehl.github.com/picturefill/
  1452. # [19:09] <adactio> jgraham: I was responding to TabAtkins_'s request to necolas: "I'm sorry, but as far as I understand it, the problem is "I'm unhappy that the CG wasn't explicitly mentioned by name in Hixie's email." Am I wrong? If so, can you explain it to me better? I've been trying all morning to understand."
  1453. # [19:10] <TabAtkins_> adactio: Let me repeat the last three sentences of that.
  1454. # [19:10] <necolas> TabAtkins_: No. It's not personal. It's about the lack of communication and the form that that communication takes when it does happen
  1455. # [19:10] <TabAtkins_> Am I wrong? If so, can you explain it to me better? I've been trying all mornign to understand.
  1456. # [19:10] <bjankord> Has any discussion been made here on meta media variables. https://gist.github.com/2702067
  1457. # [19:10] <scottjehl> btw that markup is purposely verbose to illustrate different queries. more than a real scenario in my experience
  1458. # [19:10] <webben> scottjehl: That just uses <noscript>, which could also be used with @srcset _if_ avoiding a download in browsers that don't support srcset and trying to imitate srcset using media queries is a goal.
  1459. # [19:10] <bjankord> It seems one of Hixie's issues with <picture> is how verbose it can get
  1460. # [19:11] <scottjehl> of course that's a goal. that's every browser that exists today.
  1461. # [19:11] <TabAtkins_> necolas: So what, precisely, of Hixie's email wasnt' sufficient?
  1462. # [19:11] <Wilto> TabAtkins_: So help me, you can’t possibly be struggling to understand our line here.
  1463. # [19:11] <bjankord> Wilto: +1 seriously
  1464. # [19:11] <Wilto> TabAtkins_: Obviously this isn’t about ego. I can’t tell if this is misdirection or just condescention.
  1465. # [19:12] <webben> scottjehl: None of those browser versions will be significant in 5 years time.
  1466. # [19:12] <TabAtkins_> Wilto: Either the solution is technically inadequate, in which case PROVIDE FEEDBACK so it can be changed, or it was just bad communication, in which case who gives a crap.
  1467. # [19:12] <Wilto> For our part: it’s about technical merit, and has been.
  1468. # [19:12] <scottjehl> webben: this is a feature we need yesterday
  1469. # [19:12] <Wilto> TabAtkins_: My feedback was ignored.
  1470. # [19:12] <Wilto> TabAtkins_: Or shut down with “please prove it.”
  1471. # [19:12] <Wilto> Which I have.
  1472. # [19:12] <TabAtkins_> Wilto: omigod please get stories straight. Your line cannot be squared with necolas'.
  1473. # [19:12] <webben> scottjehl: And srcset can't be fully imitated (because media queries don't tell you what the UA needs)
  1474. # [19:12] <Wilto> Meanwhile, a solution made it into the spec.
  1475. # [19:12] <hober> who ignored whose feedback?
  1476. # [19:12] <Wilto> This is a waste of everyone’s time.
  1477. # [19:12] <webben> scottjehl: But you _can_ imitate it (poorly) if you want to, using <picture> or @srcset.
  1478. # [19:12] <hober> the passive voice is not helping with clarity :)
  1479. # [19:12] <tkadlec> TabAtkins_: The problem doesn't lie in one email—it's the entire way that the communication has taken place. A series of blunders, not one.
  1480. # [19:12] <TabAtkins_> Agreed, unfortuantely. ;_;
  1481. # [19:13] <Wilto> You all, as representatives of the WHATWG, are obviously digging in your heels.
  1482. # [19:13] <TabAtkins_> tkadlec: Again, was it technical, or was it communication? If it's communication, *nobody will care* in a year.
  1483. # [19:13] <scottjehl> Sigh.
  1484. # [19:13] <scottjehl> As someone who had never participated very much in a standards evangelism/planning process, I'm really disheartened to see how this went through. I'm just so surprised by the lack of cooperation with the community group. Even if picture wasn't chosen, we were all completely blindsided by this spec. We would have had loads of concerns to discuss - all of which you're seeing now, after the fact. It
  1485. # [19:13] <scottjehl> 's not how I imagined this process worked.
  1486. # [19:13] <Wilto> So I suppose all that’s left is to publicize your reasonings, to the best we can sort them out.
  1487. # [19:13] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
  1488. # [19:13] <TabAtkins_> AGHIO3IPO.
  1489. # [19:13] <Philip`> TabAtkins_: "You have only two choices" - if I understand correctly (unlikely), I'd guess you could do something like <noscript><img src=foo.png srcset=...></noscript><script>polyfillSrcset()</script> which runs a script that parses document.body.lastChild.previousSibling.textContent and inserts the appropriate img element, so you don't need any content duplication
  1490. # [19:13] <webben> scottjehl: "after the fact": after what fact?
  1491. # [19:13] <necolas> TabAtkins_: there are 2 different things here, which can be squared.
  1492. # [19:14] <webben> scottjehl: The WHATWG spec follows a commit-then-review process.
  1493. # [19:14] <necolas> 1. The fact that people are not happy with how things have been handled or how they have been spoken to throughout
  1494. # [19:14] <TabAtkins_> I cannot express how frustrating it is to be told "The problem is with communication" and then told "it has nothing to do with personal issues".
  1495. # [19:14] <Philip`> TabAtkins_: "... the empty string. For url-valued attributes, that means "the current page"" - the spec says for img that missing or empty src means the image shouldn't be loaded (instead of resolving as relative to the base URL)
  1496. # [19:14] <webben> scottjehl: Just because @srcset is there today does not mean it's there tomorrow.
  1497. # [19:14] <zewt> (You're right, I'm not too happy with how Wilto talks to all of us)
  1498. # [19:14] <TabAtkins_> Either I have *no idea* what definitions you are using for those words, or someone else is sending mixed messages.
  1499. # [19:14] <webben> scottjehl: You wouldn't believe the amount of material that was one time included in the spec and has later been jettisoned...
  1500. # [19:15] <Wilto> zewt: I assumed condescension was the established tone here, based on how I’ve been received.
  1501. # [19:15] <TabAtkins_> Philip`: Ah, kk. Well, same effect in the end here.
  1502. # [19:15] <necolas> TabAtkins_: being personal is different to adequate communication
  1503. # [19:15] <gsnedders> scottjehl: The typical process is that based on the initial feedback, some initial proposal is put in the spec. If you have further points to raise against the proposal in the spec, do so.
  1504. # [19:15] <tkadlec> TabAtkins_: I have my issues with the srcset attribute, much like most of the developers that have seen it. The bigger issue to me has been exactly what scottjehl just said—there has been a lack of communication and cooperation here. The discussion didn't feel resolved in anyway on the mailing list. To see Hixie's email stating it was added to the draft was stunning.
  1505. # [19:15] <hober> what gsnedders said.
  1506. # [19:15] <gsnedders> scottjehl: That fact there's now something in the spec changes little.
  1507. # [19:15] <zewt> you're the only one that's been condescending and, well, frankly rather obnoxious; it's pretty uncommon here
  1508. # [19:15] <beverloo> I think a primary cause of the issue is that the Responsive Images CG proposed <picture> (among other ideas) to WHATWG which ended up unresolved. They then started a community group to discuss it, several months ago, and now a solution has been specced in a very short time (4 days!) without really reaching out to them.
  1509. # [19:16] <Philip`> TabAtkins_: (...but I think some browsers do still resolve the empty string, at least for an explicit src="")
  1510. # [19:16] <beverloo> Being a proponent of <picture> myself, I can see that being frustrating.
  1511. # [19:16] <necolas> 2. The other issue is related to the details of the technical proposals. Different issues.
  1512. # [19:16] <TabAtkins_> beverloo: But omigod the solution was *based* on the month+ of feedback on the issue.
  1513. # [19:16] <TabAtkins_> al;skjdf;als
  1514. # [19:16] <beverloo> TabAtkins, I get it, I get it
  1515. # [19:16] <bjankord> beverloo: exactly
  1516. # [19:16] <beverloo> just emphasizing
  1517. # [19:16] <TabAtkins_> beverloo: I don't. ;_
  1518. # [19:16] <beverloo> flip tables.
  1519. # [19:16] <Wilto> beverloo: It’s not even that no one reached out to us.
  1520. # [19:17] <gsnedders> beverloo: That seems an inevitable given any sort of model that works on specing something based on use-cases and then refining the spec.
  1521. # [19:17] <Wilto> I reached out to the WHATWG, representing the CG.
  1522. # [19:17] <bjankord> So much time and effort was put into the CG
  1523. # [19:17] <Wilto> And was asked to furnish proof of `picture`s merit, which was summarily dismissed.
  1524. # [19:17] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
  1525. # [19:17] <Wilto> Over the course of four days.
  1526. # [19:18] <bjankord> How can it not be clear our frustration TabAtkins?
  1527. # [19:18] <TabAtkins_> Wilto: It. Was. Not. Dismissed. That proposal was found wanting for reasons which were stated in the email.
  1528. # [19:18] <TabAtkins_> Namely, that <picture> was overly verbose and, being MQ based, didn't address the "MQs dont' work for multi-res negotiation" problem.
  1529. # [19:19] <jreading> Tab: is there a summary of the "MQs dont' work for multi-res negotiation"?
  1530. # [19:19] <bjankord> multi-res negotiation, you mean min-device-pixel-ration?
  1531. # [19:19] <TabAtkins_> Having your suggestion rejected is *not* the same as having your feedback dismissed.
  1532. # [19:19] <TabAtkins_> jreading: yes. I can illustrate it best with a real-world example.
  1533. # [19:19] <TabAtkins_> Assume for a moment that there was a bandwidth MQ.
  1534. # [19:19] <annevk> bjankord: yes, you can query the ratio, but you do not set it for the resource
  1535. # [19:19] <bjankord> There are device-pixel-ratio media queries to handle various resolution displays
  1536. # [19:20] * gwicke_away is now known as gwicke
  1537. # [19:20] <webben> Wilto: Not sure why you think four days is an unreasonable time for evaluating a technical proposal.
  1538. # [19:20] <annevk> bjankord: and you need to set it, because otherwise your image will be displayed four times as large
  1539. # [19:20] <TabAtkins_> You, a good author who wants to do well by your users, use this MQ to serve high-bandwiidth people the high-res image, and low-bandwidth people the low-res iamge.
  1540. # [19:20] <bjankord> The issue of verbosity can be handled by adding meta media variables as an option to the picture element and including URI templates
  1541. # [19:20] <TabAtkins_> I have a phone, and visit your site. I'm initially on 4G, which triggers the high-bandwidth MQ, and get served the good images.
  1542. # [19:20] <Wilto> webben: Because it makes it clear that all this discussion was going on _while_ it was specced.
  1543. # [19:20] <Wilto> Not before.
  1544. # [19:21] <annevk> this discussion has been going on forever
  1545. # [19:21] <annevk> since 2007
  1546. # [19:21] <TabAtkins_> I then go somewhere with only 2G service, flipping into the low-bandwidth MQ. The browser will then *throw away* the already-downloaded high-res images and *re-download* the low-res ones.
  1547. # [19:21] <necolas> and it's no less depressing
  1548. # [19:21] <TabAtkins_> This is, obviously, a bad situation.
  1549. # [19:21] * Joins: jtwalters (~jtwalters@c-50-132-87-187.hsd1.wa.comcast.net)
  1550. # [19:21] * Joins: erichynds (~ehynds@64.206.121.41)
  1551. # [19:22] <TabAtkins_> And it's unavoidable as long as you try to do multi-res negotiation by a mechanism that's simple and stateless like MQ.
  1552. # [19:22] <bjankord> So because bandwidth media queries are a bad situation for serving images, the picture element was disregarded?
  1553. # [19:22] <Wilto> bjankord: I did get that impression several times.
  1554. # [19:22] <bjankord> You've got to be shitting me
  1555. # [19:22] <gsnedders> Wilto: That's surely only an issue if what is in the spec is final? If it isn't, then there's no issue the two happen concurrently.
  1556. # [19:22] <TabAtkins_> bjankord: Well, because of that, any solution that relied solely on MQ was disregarded. Because it's a bad solution..
  1557. # [19:22] <jreading> Tab: I get that, but I would argue that bandwidth MQ's a re bad spec as well
  1558. # [19:22] <odinho> bjankord: Because media queries is not the way to solve it.
  1559. # [19:22] <jreading> esp. considering latency is more of an issue than bandwdith
  1560. # [19:22] <Wilto> bjankord: No one commented on the fact that picture would be much simpler to manipulate via the DOM, however, which may make `navigator.connection` a more viable option.
  1561. # [19:23] <webben> Wilto: Why is it a problem if people produce alternate proposals while evaluating a proposal?
  1562. # [19:23] <Wilto> bjankord: Which I posted to the WHATWG wiki, and linked in the mailing list twice.
  1563. # [19:23] <TabAtkins_> jreading: You can argue that, but you'd be wrong. ^_^ "Fixing" bandwidth MQ is *very* complicated, and can't be done without making MQs stateful, which is completely inconsisten with the rest of the model.
  1564. # [19:23] <scottjehl> Tab, why would it have to do that? It seems presumptive to suggest bandwidth queries couldn't be implemented more smartly, especially for a feature that doesn't exist
  1565. # [19:23] <miketaylr> what about zooming in on a page, from your desktop? the low-res/mobile image MQ will be triggered.
  1566. # [19:23] <jreading> so because of bandwidth MQ, MQ are bad… makes no sense
  1567. # [19:23] <odinho> Wilto: Then it's another proposal. Right now we're taking about the flexible image resolutions.
  1568. # [19:23] <Wilto> miketaylr: Not when using ems.
  1569. # [19:23] <scottjehl> or doesn't yet work anyway...
  1570. # [19:23] <miketaylr> Wilto: ORLY
  1571. # [19:24] <TabAtkins_> jreading: No. Because bandwidth MQ are bad, but negotiating res based on bandwidth is an important use-case, anything which uses *only* MQ is bad.
  1572. # [19:24] <Wilto> It’s worth noting the the specced solution seems to be fully pixel dependent. Is that correct?
  1573. # [19:24] <TabAtkins_> Because that means, by definition, that it's not solving an important use-case.
  1574. # [19:24] <Wilto> As no detailed use cases have been published, we don’t know.
  1575. # [19:24] <bjankord> The network information API is the closest thing we have to detecting a users bandwidth connection. http://www.w3.org/TR/netinfo-api/
  1576. # [19:24] <miketaylr> can everyone start using ems? that's one of my biggest complaints about "responsive" sites. zooming in gets me a mobile layout
  1577. # [19:24] <hober> miketaylr: :)
  1578. # [19:24] <beverloo> TabAtkins_, the spec could define a fallback model. If a 3G version is available in cache/memory, use that, otherwise fall back to the 2G version.
  1579. # [19:25] <beverloo> there's other issues with that, though
  1580. # [19:25] <gsnedders> Wilto: What use-cases does it fail to fulfil on the discussion on the mailing list?
  1581. # [19:25] <TabAtkins_> beverloo: It could. But then your MQ is stateful. What about the *rest* of the properties that you're applying via the bandwidth MQ?
  1582. # [19:25] <Wilto> miketaylr, hober: <3 ems.
  1583. # [19:25] <beverloo> I'm not sure whether I agree with a bandwidth MQ at all, actually
  1584. # [19:25] <beverloo> it'd be based on estimates
  1585. # [19:25] <Wilto> gsnedders: The one I just mentioned.
  1586. # [19:25] <beverloo> "wifi" can be significantly slower than "3g"
  1587. # [19:26] <TabAtkins_> beverloo: I agree with you. ^_^ That's the point. Bandwidth MQs are a bad idea for multiple reasons. So you can't rely on MQs to do res negotiation.
  1588. # [19:26] <zewt> seems to me that connection-based selection is so fiddly, imprecise and heuristic, that the only sane solutions are ones that give the browser metadata and say "do what you think is best"
  1589. # [19:26] <Wilto> I’m not sure we’re all on the original topic anymore.
  1590. # [19:26] <TabAtkins_> Yes, the Network Info API is *really* flawed.
  1591. # [19:26] <beverloo> So we're excluding a feature such as <pictures> on a use-case that relies on a hypothetical, not yet specified feature (being bandwidth MQs)?
  1592. # [19:26] <odinho> beverloo: it will never be right, in Opera, we've tried to at least make it useful as an heuristic, -- but that also falls flat on its bottom. Although it sounds like it can be done, it's extremely hard to even get an approximation.
  1593. # [19:26] <Wilto> beverloo: It seems so.
  1594. # [19:26] <TabAtkins_> beverloo: No, we're excluding it based on a ues-case (res negotiation) which requires an ability that MQ can't do.
  1595. # [19:27] <beverloo> odinho, yes, I'm aware of that (I'm on the Chrome on Android team)
  1596. # [19:27] <Wilto> beverloo: Android Chrome! You do yeoman’s work, beverloo.
  1597. # [19:27] * jernoble|afk is now known as jernoble
  1598. # [19:28] <bjankord> TabAtkins_: If the Network Information API is flawed, why have Chrome and Firefox added support for it?
  1599. # [19:28] <TabAtkins_> Wilto: Chat with me privately. I need to find out what pieces of your knowledge are missing so I can fill them in properly.
  1600. # [19:28] <beverloo> TabAtkins, as odinho says, getting bandwidth negotiation right is extremely hard to begin with. It's likely that we won't ever get past heuristics here
  1601. # [19:28] <TabAtkins_> bjankord: Because it's in a spec.
  1602. # [19:28] <odinho> beverloo: You obviously knew something about it, just wanted to back you up by extra data point :-)
  1603. # [19:28] <ShaneHudson> Bandwidth media queries would be really nice but they are not accurate at the moment, perhaps never will be. That is absolutely no reason to deminish <picture> or the other solutions the community group as proposed.
  1604. # [19:28] <TabAtkins_> beverloo: heuristics are fine. the *real* problem is statefulness, which MQ can't provide.
  1605. # [19:28] <Wilto> TabAtkins_: I’d prefer to see more information on the specced solution posted publicly.
  1606. # [19:28] <beverloo> TabAtkins, changing a mobile device's orientation will influence the width
  1607. # [19:28] <Wilto> You don’t have to convince me; the developer community will need citations.
  1608. # [19:28] <bjankord> ShaneHudson: +1
  1609. # [19:28] <beverloo> potentially causing the same problem
  1610. # [19:29] <TabAtkins_> Wilto: I've responded on multiple threads about why MQ-based solutions are flawed. Did you read those posts? If not, I can fill you in quickly.
  1611. # [19:29] * Joins: jamesr_ (jamesr@nat/google/x-rlvvpxuvwmcoskmv)
  1612. # [19:29] <Wilto> TabAtkins_: Sure. Sum up for me, real quick.
  1613. # [19:29] <Wilto> The community will want an easy-to-digest reasoning.
  1614. # [19:29] <annevk> beverloo: so does resizing the browser window on desktop
  1615. # [19:29] <TabAtkins_> I explained *literally* a screen or so ago, to jreading.
  1616. # [19:29] <odinho> beverloo: A browser has much better control over herusticts, and can do special things based on its special knowledge. Say, the phone knows it's roaming, -- or that the user has set a bandwidth limitation, -- those it can use in a useful way to always take the smallest pictures to save bandwidth.
  1617. # [19:29] <beverloo> annevk, TabAtkins, so neither solution is really stateful
  1618. # [19:29] <odinho> beverloo: MediaQueries can't do that.
  1619. # [19:30] <TabAtkins_> beverloo: Yeah, I think that Hixie's proposal is somewhat flawed because of that.
  1620. # [19:30] <TabAtkins_> beverloo: I think it should take one length and use the smaller of the window dimensions to check it, precisely for that reason.
  1621. # [19:30] <Wilto> TabAtkins_: It seemed like you were discussing bandwidth MQ.
  1622. # [19:30] <beverloo> odinho, absolutely, the heuristics would be much more accurate than what a user can do
  1623. # [19:30] <annevk> beverloo: one solution describes the resource, the other queries the device and selects a resource based on that
  1624. # [19:30] <annevk> beverloo: you need the former for e.g. pixel density stuff
  1625. # [19:30] <TabAtkins_> Wilto: I was explainign why you can't do bandwidth MQ, yes. And that's why MQ-based solutions are bad.
  1626. # [19:31] <bjankord> Tab: What solution do you suggest?
  1627. # [19:31] <Wilto> So, neither of these solutions will use hard-coded bandwidth detection, is that correct?
  1628. # [19:31] <odinho> TabAtkins_: I think that too. A bounding box. Did I write that on mailing list, or only here?
  1629. # [19:31] <beverloo> TabAtkins, issue there is that websites may present different versions based on the orientation (again due to MQs)
  1630. # [19:31] <Wilto> TabAtkins_: ^
  1631. # [19:31] <TabAtkins_> bjankord: For what? The general problem?
  1632. # [19:31] <Wilto> Nothing inline, in the markup, I mean.
  1633. # [19:31] <TabAtkins_> odinho: I think it was you suggesting that, here in the chatroom.
  1634. # [19:31] * jonlee|afk is now known as jonlee
  1635. # [19:31] <jreading> bandwidth MQ are bad
  1636. # [19:31] <beverloo> TabAtkins, for which you may want a different picture too.
  1637. # [19:31] <jreading> none of this makes sense… MQ are still part of the style layer in the presentation layer, there's navigator.connection and UA ISP sniffing, server solutions to work with bandwidth. Latency is more of an issue than bandwidth with wireless carriers anyway, bandwidth means nothing with 600ms latency. Why is this a concern of the presentation layer? Are all mobile web solutions through the letterbox of markup and css?
  1638. # [19:31] <ShaneHudson> <picture> could work the same way as srcset if need be, without the media queries. The biggest problem with srcset is that it has the potential to be an extremely large attribute which would be unreadable and horrid. It also has very litttle potential for expansion
  1639. # [19:31] <TabAtkins_> beverloo: Eh, true. Welp, whatever.
  1640. # [19:32] * Quits: pablof (~pablof@144.189.101.1) (Remote host closed the connection)
  1641. # [19:32] <Wilto> TabAtkins_: If neither is using an attribute that detects bandwidth, I’m not sure why we’re still talking about it.
  1642. # [19:32] <Wilto> I agree that it’s a flawed idea.
  1643. # [19:32] <bjankord> Agreed
  1644. # [19:32] <Wilto> On both markup patterns.
  1645. # [19:32] <Wilto> Let’s move on.
  1646. # [19:32] <beverloo> annevk, it's really a subset, MQs can poll for the DPI as well. Due to it being a subset however, most of the questions we're discussing now are out of scope (let alone parsing issues)
  1647. # [19:32] <Wilto> Apart from _theoretical_ media queries, that is.
  1648. # [19:32] <TabAtkins_> Wilto: You, um, tell the browser what your image's DPI is. It then decides based on its own metrics (such as bandwidth history) which one to download.
  1649. # [19:32] * Joins: pablof (~pablof@144.189.101.1)
  1650. # [19:32] <annevk> beverloo: polling for the DPI is not enough
  1651. # [19:32] <annevk> beverloo: you need to set it
  1652. # [19:33] <Wilto> TabAtkins_: And the specced pattern does not, then?
  1653. # [19:33] <annevk> beverloo: because otherwise the image will be displayed four times the size
  1654. # [19:33] <Wilto> It incorporates bandwidth in a meaningful way?
  1655. # [19:33] <TabAtkins_> Wilto: Wait, have you read the specced proposal?
  1656. # [19:33] <beverloo> annevk, got you
  1657. # [19:33] <webben> Wilto: Providing information about the resource allows browsers to use any information (including bandwidth information, power information, viewport size, orientation etc) to select the optimal image.
  1658. # [19:33] <beverloo> annevk, thanks :)
  1659. # [19:33] <zewt> TabAtkins: well, you also need to tell it the image's size (even if it's only a hint)
  1660. # [19:33] <TabAtkins_> Wilto: I'm not sure if you're asking questions that I should answer, or if you're being rhetorical, if you're trying to lead to a point that I suspectis inaccurate.
  1661. # [19:33] <annevk> beverloo: I'm somewhat surprised everyone thinks MQ magically solve that...
  1662. # [19:33] <zewt> file size, I mean
  1663. # [19:34] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
  1664. # [19:34] <TabAtkins_> zewt: Filesize *should* correspond to the Nx multiplier you give.
  1665. # [19:34] <webben> zewt: Yeah. I'm inclined to suggest srcset should include HxW (always) and would benefit form size.
  1666. # [19:34] <webben> TabAtkins_: Doesn't that depend on e.g. jpeg quality?
  1667. # [19:34] <beverloo> annevk, let's make a new image format containing the target DPI!
  1668. # [19:34] <zewt> TabAtkins: you can also have multiple images at the same resolution with eg. different jpeg compression ratios
  1669. # [19:34] * beverloo runs
  1670. # [19:34] <TabAtkins_> zewt: Unless you're being perverse and providing different-sized images for different resolutions.
  1671. # [19:35] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
  1672. # [19:35] <TabAtkins_> Yeah, compression ratio is somewhat harder to deal with, particularly since it's so format-specific.
  1673. # [19:35] * hober mumbles something about jpeg2000
  1674. # [19:35] <TabAtkins_> I think by the time you're dealing with that, you should just go res-independent.
  1675. # [19:35] <bjankord> We could sit here all day discussing pros and cons of each solution, yet still get no where...
  1676. # [19:35] <odinho> beverloo: They already have it. But let's rather make a "Real_Image_DPI_I_Really_Mean_It" attribute for JPG et al! *runs*
  1677. # [19:35] <annevk> beverloo: you mean one that browsers are not forced to ignore?
  1678. # [19:36] <zewt> TabAtkins: also, file size doesn't change linearly with resolution
  1679. # [19:36] <zewt> not always, anyway
  1680. # [19:36] <beverloo> annevk, odinho, yup.
  1681. # [19:36] <grigs> Wow, lot's of conversation. Took forever to catch up. A couple of quick notes.
  1682. # [19:37] * Joins: nicksergeant (~Nick@74.112.37.250)
  1683. # [19:37] <bjankord> grigs: yes, there is a lot to digest here
  1684. # [19:37] <tantek> TabAtkins - re: "just go res-independent", let me know when you know of cameras that output SVG photographs :p
  1685. # [19:37] <grigs> 1. Was really pleased to hear more background from hober. Good to know that he looked at a bunch of info before making his rec.
  1686. # [19:37] * Joins: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net)
  1687. # [19:37] <annevk> beverloo: good luck with that :)
  1688. # [19:38] <beverloo> annevk, :D
  1689. # [19:38] <TabAtkins_> zewt: Yeah, it's not a perfect fit. But I suspect it's probably a good enough approximation.
  1690. # [19:38] <grigs> 2. A couple of people asked earlier why we went to a community group to discuss this. It was because we were asked to take the conversation off the whatwg list.
  1691. # [19:38] <annevk> grigs: pointer for that? I asked before but never got it
  1692. # [19:39] <ShaneHudson> It should be in a community group anyway, it is the kind of thing the community should have input on
  1693. # [19:39] <grigs> @annevk I'll dig it up.
  1694. # [19:40] <zewt> TabAtkins: at least on impression (without having looked at it too hard), having different JPEG qualities seems useful; if I'm looking at pictures, I'd rather have a high-resolution image go from q12 to q10 than cut the resolution in half
  1695. # [19:40] * Joins: sicking (~chatzilla@nat/mozilla/x-lvqdtqihpcubzkhh)
  1696. # [19:40] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Quit: Leaving)
  1697. # [19:40] <annevk> ShaneHudson: WHATWG is a community developing HTML
  1698. # [19:41] <annevk> ShaneHudson: no need for subgroups in the past eight years
  1699. # [19:41] <zewt> i suppose that if browsers are given too many axes to choose from, the chances of making wrong decisions rises, which could be a barrier to using the feature
  1700. # [19:41] <grigs> annevk: original objection to the conversation on the list http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034775.html
  1701. # [19:41] * Joins: Adam_ (42b54b7f@gateway/web/freenode/ip.66.181.75.127)
  1702. # [19:41] <TabAtkins_> zewt: I think that, in general, you won't request the double-res image unless you're on a double-res device anyway, regardless of bandwidth.
  1703. # [19:41] <TabAtkins_> (Or, as people have said, you're printing, or saving, etc.)
  1704. # [19:41] <grigs> annevk: my response and concern http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034790.html (which in retrospect seems pretty spot on ;-) )
  1705. # [19:42] <annevk> grigs: interesting, I don't know who that is
  1706. # [19:42] * Quits: necolas (~necolas@80.231.76.54) (Remote host closed the connection)
  1707. # [19:42] <TabAtkins_> zewt: Within a particular resolution level, jpeg quality might be useful, but I think it's a much smaller concern.
  1708. # [19:42] <grigs> annevk: still looking for the specific suggestion that we take it to a community group.
  1709. # [19:42] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 264 seconds)
  1710. # [19:42] * Joins: necolas (~necolas@80.231.76.54)
  1711. # [19:42] <TabAtkins_> Huh. I have also never heard of this Ronjek guy.
  1712. # [19:42] <zewt> TabAtkins: i mean, for example, if I'm on a 1920x1200 display, and a site wants to show a 1920x1200 image, selecting an appropriate quality for my connection--it can make sense to choose a 1920x1200 q10 image if you want to save bandwidth, rather than a 1280x720 q12 one
  1713. # [19:43] * Joins: cheron (~cheron@unaffiliated/cheron)
  1714. # [19:43] <annevk> grigs: the list has 1500 people so if one person tells you something that doesn't mean it's definitive
  1715. # [19:43] <zewt> at least for that (isolated, off-the-top-of-my-head) case, it's almost always the better choice
  1716. # [19:43] * Parts: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  1717. # [19:43] <annevk> grigs: thanks
  1718. # [19:43] <tkadlec> grigs: I believe here? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html
  1719. # [19:43] <annevk> i have to go now
  1720. # [19:43] <grigs> annevk: I get that. To me, that’s the frustrating part.
  1721. # [19:43] <divya> annevk: you are just being defensive here. ultimately who do we consider as the 'voice'?
  1722. # [19:44] <divya> if we mention to hixie
  1723. # [19:44] <zewt> but then it's also much more tied into connection heuristics, where resolution selection at least isn't, so it's much more likely to be useful in practice I guess
  1724. # [19:44] <divya> thats not enough
  1725. # [19:44] <divya> if we mention here
  1726. # [19:44] <divya> thats not enough
  1727. # [19:44] <divya> if we mention on mailing list its not enough
  1728. # [19:44] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
  1729. # [19:44] <divya> when is it enough?
  1730. # [19:44] * Joins: scottkellum (~scottkell@rrcs-50-74-240-194.nyc.biz.rr.com)
  1731. # [19:44] <annevk> divya: not sure what you're saying
  1732. # [19:44] <annevk> but I have to go watch a movie
  1733. # [19:44] <grigs> tkadlec: thanks, that's the link
  1734. # [19:44] <grigs> annevk: enjoy!
  1735. # [19:44] <webben> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html seems relevant.
  1736. # [19:44] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  1737. # [19:45] * Joins: chazcross (ad0a2166@gateway/web/freenode/ip.173.10.33.102)
  1738. # [19:45] <grigs> webben: yep.
  1739. # [19:45] * Joins: jacobrask (~jacob@jacobrask.net)
  1740. # [19:45] * Joins: stalled (~stalled@unaffiliated/stalled)
  1741. # [19:46] <webben> divya: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F
  1742. # [19:46] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
  1743. # [19:46] <TabAtkins_> zewt: Sure, it's the better choice. I personally don't think it'd be worth the effort of speccing compression levels in a cross-format way (or handling format-specific stuff).
  1744. # [19:46] <zewt> TabAtkins: i'd just include the file size by itself
  1745. # [19:47] * Quits: necolas (~necolas@80.231.76.54) (Ping timeout: 252 seconds)
  1746. # [19:47] <TabAtkins_> Ah, yeah, that's valid.
  1747. # [19:47] <TabAtkins_> Hixie mentions that in a response on the latest thread.
  1748. # [19:47] <zewt> that would make the assumption that all available options are in the same or comparable compression types, which is probably reasonable
  1749. # [19:47] <divya> webben: all of it was done.
  1750. # [19:48] <divya> hober: it would have been nice when you proposed the solution why you decided it over picture
  1751. # [19:48] <divya> hober: it seems like the whole work was summarily dismissed even though now it looks like it wasnt
  1752. # [19:48] <webben> divya: I'm linking you to that to explain why it doesn't make sense to ask for the voice of the WHATWG.
  1753. # [19:49] <webben> divya: The WHATWG as an organization speaks only for administrative reasons basically.
  1754. # [19:50] <jgraham> Hmm, I am now behind on the discussion, obviously, but it occured to me that one problem with an element-based solution is that people will be tempted to polyfill it before there are any browser implementations. This will make it very hard to modify in the face of implementor feedback without breaking existing content. By contrast with an attribute-based solution one could use data-srcset or similar from script until there are shipping native impleme
  1755. # [19:50] * Quits: Adam_ (42b54b7f@gateway/web/freenode/ip.66.181.75.127) (Quit: Page closed)
  1756. # [19:50] <divya> jgraham: i actually am not attached to any one solution
  1757. # [19:50] <divya> i suspect none of the people are
  1758. # [19:51] <divya> jgraham: only concern is the unreadable syntax that srcset proposes
  1759. # [19:51] <divya> and the other concerns that scottjehl raises
  1760. # [19:51] <grigs> divya: +1
  1761. # [19:51] <divya> jgraham: we know people will go wrong
  1762. # [19:51] <divya> jgraham: i think having an easy to understand solution would make it less difficult to go wrong
  1763. # [19:52] <grigs> i'll also add that while hober's original spec was clear, despite multiple readings of the expanded version, i still don't fully grok how it will work.
  1764. # [19:52] * Joins: chippper (627ca660@gateway/web/freenode/ip.98.124.166.96)
  1765. # [19:52] <grigs> not trying to be difficult here, but will readily acknowledge I may be dense. ;-)
  1766. # [19:53] <divya> just because the GCD is stupid
  1767. # [19:53] <jgraham> divya: hmm i don't think I said you were. Just sharing some "thinking" from the bus ride home
  1768. # [19:53] <grigs> divya: GCD?
  1769. # [19:53] <divya> Greatest common denominator :)))
  1770. # [19:53] <Philip`> zewt: Your example of a 1280x720 image on a 1920x1200 display sounds like it's effectively using downsample+upsample as a lossy compression algorithm, but a pretty dumb one, in which case it makes sense that any non-terrible lossy compression algorithm (e.g. JPEG) ought to be able to do a better job at the same bitrate
  1771. # [19:53] * Joins: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202)
  1772. # [19:54] <divya> doesnt mean we should just do whatever is the most easy for implementors.
  1773. # [19:54] <divya> jgraham: ya ya i am just ranting
  1774. # [19:54] <paul_irish> jgraham: every feature will be polyfilled. polyfill all the things. if there is a way polyfill solutions can better coexist with iterative browser implementations, then that'd be good too.
  1775. # [19:54] <jgraham> paul_irish: There is: don't use new elements before they are implemented; for things with no implementation use data- attributes
  1776. # [19:54] <divya> jgraham: i am yet to come across a polyfill problem
  1777. # [19:55] <zewt> Philip`: sure, the point of the example was why you might want to select among different jpeg quality versions for the same resolution--why file size might be useful in addition to resolution
  1778. # [19:55] <divya> jgraham: is there one?
  1779. # [19:56] <jgraham> divya: My concern is that people add special processing for <picture> based entirely on polyfill, then a browser implements it, we realise that the spec doesn't work for some reason that the polyfill doesn't care about (e.g. during dynamic changes) and changing the spec breaks existing content
  1780. # [19:56] <paul_irish> <x-picture> is the equivalent. it could work effectively the same from the polyfill side.
  1781. # [19:57] <jgraham> Yeah, but inventing elements is non-conforming and highly controversial
  1782. # [19:57] <divya> jgraham: like we havent been doing that for eons :P
  1783. # [19:57] <jgraham> divya: How many things *that no browser implements*?
  1784. # [19:57] <scottjehl> jgraham: the polyfill would of course be updated to match implementation
  1785. # [19:57] <Philip`> zewt: Yeah, I'm not trying to argue any case - just musing about how lowering resolution is simply a poor lossy compression algorithm
  1786. # [19:57] <divya> jgraham: severalll
  1787. # [19:57] <jgraham> scottjehl: But existing sites would break
  1788. # [19:58] <divya> HOW ABOUT HGROUP
  1789. # [19:58] * jgraham -> food
  1790. # [19:58] <divya> kk bai
  1791. # [19:59] * Joins: adactio (~adactio@cust217-dsl91-135-3.idnet.net)
  1792. # [20:00] * Quits: mplehman (~mplehman@71-87-1-124.static.eucl.wi.charter.com) (Remote host closed the connection)
  1793. # [20:00] <jreading> there.must.be.a.better.way
  1794. # [20:00] <jreading> http://davidbcalhoun.com/present/mobile-performance-amazon/#navigator.connection this should be in headers and we can kill that MQ bandwidth nonsense
  1795. # [20:02] <jreading> variablize the MQ's in <picture> (like my blog post) and be more DRY
  1796. # [20:03] * Quits: pyrsmk (~pyrsmk@202.182.141.88.rev.sfr.net) (Ping timeout: 244 seconds)
  1797. # [20:04] * Joins: danielfilho (~daniel@187.31.77.7)
  1798. # [20:04] <paul_irish> jgraham: speaking of changing implementations, that spec changed. :p
  1799. # [20:04] <paul_irish> oops. jreading, rather.
  1800. # [20:04] <odinho> I've written a polyfill for srcset now.
  1801. # [20:05] <zewt> hey, i've been using gmail for years and I finally figured out how to extend a damned quote block
  1802. # [20:05] <odinho> To see it could be done. But, yes, it does have some problems at edge cases.
  1803. # [20:05] <paul_irish> jreading: agreed we need http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html in MQs and some sort of relation to <picture>/srcset
  1804. # [20:06] * Joins: kevinSuttle (4a88c1a4@gateway/web/freenode/ip.74.136.193.164)
  1805. # [20:06] * Quits: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
  1806. # [20:06] <scottjehl> odhino: link?
  1807. # [20:06] <odinho> scottjehl: Yeah, I need someone to test it in IE :P
  1808. # [20:07] <scottjehl> ...and loads of mobile devices
  1809. # [20:08] <scottjehl> so what's next for picture element supporters? is there anywhere worthwhile to direct our existing and ongoing efforts?
  1810. # [20:08] * Quits: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202) (Quit: Page closed)
  1811. # [20:08] <divya> scottjehl: i am not sure if we should be so affiliated to pic element
  1812. # [20:08] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
  1813. # [20:09] <ShaneHudson> I am not 100% attached to picture element, but it is far surpior to srcset and to be honest, I prefer most suggested solutions over srcset
  1814. # [20:09] * Quits: TabAtkins_ (~jackalmag@50-0-151-4.dsl.dynamic.sonic.net) (Ping timeout: 244 seconds)
  1815. # [20:09] <scottjehl> divya, what do you mean?
  1816. # [20:09] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
  1817. # [20:10] * Joins: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net)
  1818. # [20:10] <grigs> scottjehl: i'm still trying to definitely figure out if srcset addresses one of the core use cases.
  1819. # [20:10] <divya> scottjehl: i am saying we shouldnt be attached to a syntax
  1820. # [20:10] <divya> its okay as long as we find a solution that works for implementors and devs alike
  1821. # [20:11] <scottjehl> sure, primary concern is something that solves the problem for users. That said, many are attached to picture's syntax because we already know it does solve that problem today.
  1822. # [20:12] <grigs> scottjehl: to my mind there are three questions about srcset. 1) does it do what we need it to do? 2) can the syntax be improved to provide more clarity? 3) does the real or perceived concerns about the syntax mean that srcset will have a harder time being adopted by developers?
  1823. # [20:12] <kevinSuttle> At this point, I don't think this is our problem to solve. I'm trying to bring a bit more scope to the discussion. http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-780 (Going to keep posting this until it gets in front of decision makers/influencers)
  1824. # [20:12] <tantek> In following this discussion, I'm a bit surprised to see so little reasoning from actual use-cases, that is, what seems to be documented here: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ and here: http://www.w3.org/community/respimg/wiki/Main_Page and perhaps originating here: https://etherpad.mozilla.org/responsive-assets
  1825. # [20:12] <Philip`> scottjehl: If you define yourself as being in the pro-foo camp, you're implicitly defining everyone else as anti-foo, which makes it emotionally harder for them to ever support foo, so you're shooting yourself in the foot :-)
  1826. # [20:13] <grigs> tantek: exactly
  1827. # [20:13] * Joins: eberon_ (~eberon@angilas.ur.northwestern.edu)
  1828. # [20:13] * tantek agrees with Philip - why jumping straight to pro/anti any specific syntax?
  1829. # [20:13] * tantek has yet to see any consensus on which use-cases matter and why.
  1830. # [20:14] <tantek> if you can't agree on use-cases and priority, then of course you're going to get different solutions. it's pointless to argue about syntax when you can't agree on purpose.
  1831. # [20:14] * Joins: greenplastic (~anonymous@71-87-1-124.static.eucl.wi.charter.com)
  1832. # [20:14] <grigs> tantek: amen!
  1833. # [20:14] <tantek> grigs - I'm looking at the folks proposing <picture> as well
  1834. # [20:14] <grigs> tantek: OH I KNOW
  1835. # [20:14] <grigs> :-)
  1836. # [20:15] <tantek> I've yet to see the clear math-style proof of, starting from these use-cases, with this priority, here's how we end up designing the <picture> element.
  1837. # [20:15] <tantek> until you show your work, I'm not buying the proof (proposal)
  1838. # [20:15] <grigs> same true for srcset as well then, eh?
  1839. # [20:16] <tantek> grigs - of course
  1840. # [20:16] <odinho> I think the camps disagree about the use cases. -- Because many use cases can't be done with srcset, - and many can't be done with <picture>. -- I align much more with srcset's use cases, and think they're more important to tackle. However, -- the other use cases should be tackled as well, maybe later. Maybe the best solution for those is a new <picture> element.
  1841. # [20:17] <tantek> odinho - that's bass-ackwards
  1842. # [20:17] <tantek> "align much more with srcset's use cases"
  1843. # [20:17] <grigs> i do think there's a lot of that going on though.
  1844. # [20:17] <tantek> are you seriously framing a set of use-cases by one particular syntax? that's so limiting in thinking I don't even know where to begin.
  1845. # [20:17] <jgraham> tantek: Not if you are charitable
  1846. # [20:17] * Quits: espadrine (~thaddee_t@nat/mozilla/x-dgdzmbmmirpyrvqw) (Quit: espadrine)
  1847. # [20:18] <tantek> those use-case documents I linked to above are reasonable starting points. the only nit I would pick is to put them on a *generally* accessible/usable wiki (e.g. w3.org/wiki/ or wiki.whatwg.org )
  1848. # [20:18] <odinho> tantek: No :-) I'm not wedded to any syntax at all! But I want certain things to be able to do in the browser.
  1849. # [20:18] <adactio> tantek: And yet one of the proposed solutions is in the spec while the other is not. Both, as you rightly point out, should first be tested through use-cases, backward-compatibility, etc. There is an unequal weighing of proposals.
  1850. # [20:18] <tantek> group/community specific wikis are a bit of a silo-iziation/tribalization and not useful for broadening consensus (actually harmful)
  1851. # [20:18] <jgraham> tantek: You could assume he meant "I think that the use cases that informed the design of srcset are more important than those that influenced <picture>"
  1852. # [20:19] <grigs> jgraham: that's the way I read it.
  1853. # [20:19] <tantek> as long as you frame the use-cases by specific syntaxes, you're going to suffer more arguments/friction than if you simply give the use-cases their own (perhaps fragment) permalinks and discuss them individually.
  1854. # [20:20] <odinho> http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ <- in fact these are actually very nice.
  1855. # [20:20] <tantek> odinho - except it's not editable
  1856. # [20:20] <tantek> hence: "put them on a *generally* accessible/usable wiki (e.g. w3.org/wiki/ or wiki.whatwg.org )"
  1857. # [20:20] <tantek> give them their own sections so you can link to them
  1858. # [20:20] <ShaneHudson> So how do we go about settling on the use-cases? We have had hundreds of posts on the CG, the mailing list and in here about the different use cases. What is the recommented way to compile them, the wiki?
  1859. # [20:20] * Joins: brucel (~brucel@cpc5-smal11-2-0-cust151.perr.cable.virginmedia.com)
  1860. # [20:21] <tantek> example: http://wiki.whatwg.org/wiki/Time_element
  1861. # [20:21] <odinho> tantek: I agree with all of them. -- But the media queries doesn't solve them as nicely as the srcset proposal does.
  1862. # [20:21] <tantek> ShaneHudson - yes, wiki please
  1863. # [20:21] <grigs> one lesson coming out of this experience should be some better guidance on the hoops developers should jump through when they really want something in the spec.
  1864. # [20:21] <tantek> that way we can iterate on them in one place
  1865. # [20:21] <scottjehl> grigs +1
  1866. # [20:21] <tantek> rather than go round-round in the support forums known as "mailing lists"
  1867. # [20:21] <tkadlec> grigs: +1
  1868. # [20:22] * Joins: akselkreis (~Adium@rrcs-50-75-52-51.nys.biz.rr.com)
  1869. # [20:22] <jgraham> tantek: Characterising the whatwg list as a "support forum" is just inaccurate
  1870. # [20:22] <tantek> grigs - what part of "document use-cases on the wiki" was not communicated?:
  1871. # [20:22] <ShaneHudson> http://wiki.whatwg.org/wiki/Adaptive_images Has everyone seen that page?
  1872. # [20:22] <jgraham> Although I agree that using the wiki in this case might be useful
  1873. # [20:22] <grigs> we've had people say we shouldn't discuss on the whatwg list, we should use a community group, we should build use cases, we should have use cases on publicly editable wiki (why isn't that part of the community group), math proofs, etc.
  1874. # [20:23] <Wilto> tantek: Just tuning back in, but you saw this, yeah? http://wiki.whatwg.org/wiki/Adaptive_images
  1875. # [20:23] <Wilto> I posted it to the list a couple of times.
  1876. # [20:23] * Joins: rdebeasi (ada04aae@gateway/web/freenode/ip.173.160.74.174)
  1877. # [20:23] <jgraham> Wilto: That still has proposed solutions listed under "use cases"
  1878. # [20:23] <ShaneHudson> grigs: I agree. For new members at least, it is pretty caotic!
  1879. # [20:23] <tantek> Wilto - problem with that wiki page is that it is already assuming <picture> as syntax
  1880. # [20:23] <odinho> grigs: That was one person of a list of 1400+, and at least I haven't seen him much. But it's good to start from use cases.
  1881. # [20:23] <tantek> so you're not going to get people to read past that
  1882. # [20:24] <tantek> this style of documenting use-cases is better: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/
  1883. # [20:24] <grigs> odinho: how the hell were we supposed to know that? :-)
  1884. # [20:24] * Joins: J_Voracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
  1885. # [20:24] <ShaneHudson> Okay, lets make a new page.
  1886. # [20:24] * Joins: TabAtkins_ (jackalmage@50-0-151-4.dsl.dynamic.sonic.net)
  1887. # [20:24] * Quits: J_Voracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
  1888. # [20:24] <grigs> At various points we were told that modifying the img tag was a non-starter so we coached others not to do so.
  1889. # [20:24] <tantek> jgraham - the one person that told people to not discuss responsive images on the whatwg list proves my point about it being a support forum.
  1890. # [20:24] <Wilto> That’s helpful, tantek. We can put up a page more along those lines, if that’ll help.
  1891. # [20:24] <tantek> all email lists eventually devolve into support forums
  1892. # [20:24] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  1893. # [20:25] <TabAtkins_> grigs: That was misinterpreted, unfortunately. Modifying <img> to have *children* is a non-starter. Adding attrs is always okay.
  1894. # [20:25] <odinho> grigs: That's also a technicality, -- you were told you couldn't change the parser for img element, that's a non-starter. Adding attrs is ofc.
  1895. # [20:25] <jgraham> grigs: That was a misunderstanding about what "modify" meant
  1896. # [20:25] <tantek> actual design happens in smaller / quicker fora like IRC, with anything of any substance being documented on the web (wiki pages)
  1897. # [20:25] <tantek> the whatwg list *appears* to work only because Hixie treats it as his inbox.
  1898. # [20:25] <jgraham> tantek: I don't think that is true and I think you are assuming your hypothesis and then picking and choosing data to support it
  1899. # [20:26] <grigs> Back to my original point, my biggest frustration with the process feeling like there was a lot of wasted time despite asking a lot how to go about making something happen.
  1900. # [20:26] <tantek> no, I'm just concluding from the vast majority of email that gets to sent to the whatwg list
  1901. # [20:26] <Philip`> tantek: Not even maths has maths-style proofs of the suitability of its syntax - it just has people like Newton and Leibniz coming up with something arbitrary that works for them, until one of them becomes most widely adopted and only weirdos like physicists use the other
  1902. # [20:26] <tantek> sure reads like a support forum
  1903. # [20:26] <jgraham> You must be reading a very different list to me
  1904. # [20:26] <ShaneHudson> It is a shame we cannot modify the <img> to have children.. Bruce Lawon and Christian Heilmann explained it to me on Twitter, but it would make things so much easier if we could
  1905. # [20:27] <odinho> grigs: It was not wasted. Read what hober said about his proposal. And also, how easy everyone now agrees that the use cases are sane and good.
  1906. # [20:27] <odinho> grigs: It was not like that last time.
  1907. # [20:27] <ShaneHudson> How do we register for this wiki? Says I have to be an admin to register...
  1908. # [20:27] <Philip`> ShaneHudson: Many things would be much easier if we could ignore reality :-)
  1909. # [20:27] <grigs> odinho: Actually, no, we don’t seem to agree on use cases (which was tantek's earlier point).
  1910. # [20:27] <tantek> ShaneHudson - any W3C account can sign into w3.org/wiki
  1911. # [20:28] <odinho> grigs: I agree with the use cases you've put up. -- And putting media queries up to those points, I find it lacking.
  1912. # [20:28] <ShaneHudson> tantek: Ah, so not wiki.whatwg? Ok
  1913. # [20:28] <jgraham> ShaneHudson: The whatwg wiki?
  1914. # [20:28] <jgraham> Uh Hixie is an admin, maybe annevk, AryehGregor perhaps
  1915. # [20:28] <grigs> odinho: happy you agree, not clear everyone else does (again tantek's point)
  1916. # [20:28] <odinho> grigs: media queries in <picture> do _more_ stuff though, -- and I thought there was more use cases people wanted, -- but I didn't see them on respimg.
  1917. # [20:29] <Wilto> The official instructions for creating an account on the WHATWG wiki are to either ask someone in here to create it, or contact Hixie directly about one.
  1918. # [20:29] <tantek> anyway, now that there's WHATCG, it probably makes reasonable sense to just use w3.org/wiki - unless there's major WHATWG objection to doing so.
  1919. # [20:29] <odinho> So I thought people wanted the extra power of media queries as well (and had made some use cases that wanted that), but it seems not. :-)
  1920. # [20:30] <tantek> odinho - indeed, it's easy to draw incorrect conclusions when we don't have specific use-cases to refer to by URL.
  1921. # [20:30] <jreading> i have a hard time seeing a dozen or so <picture> elements on a page, each with 2 or 3 MQ's sources as a good solution…
  1922. # [20:30] <tantek> jreading - a good solution to *what use-cases*?
  1923. # [20:30] <grigs> odinho: i'm pleased hober found the threads useful. i was thankful to see his comments this morning. still hard not to see time wasted writing a spec for picture if that wasn't really a good next step.
  1924. # [20:30] <ShaneHudson> Right I am going to grab dinner. Does anyone disagree with the wiki page being http://www.w3.org/wiki/Images ?
  1925. # [20:30] * Joins: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net)
  1926. # [20:30] <tantek> ShaneHudson - go ahead and start it. we can rename/move later if needed.
  1927. # [20:31] * Parts: scottkellum (~scottkell@rrcs-50-74-240-194.nyc.biz.rr.com)
  1928. # [20:31] <jreading> is their a github of use cases that I can submit pull requests?
  1929. # [20:31] <tantek> jreading - wiki editing is easier / more usable/accessible that git for documentation/text
  1930. # [20:31] <zewt> let's make discussing a feature as complicated as possible
  1931. # [20:31] <ShaneHudson> jgraham: Use the wiki I just linked to.. I will be creating the page after dinner
  1932. # [20:32] <tantek> just created it as a stub ;)
  1933. # [20:32] <jreading> tantek: I was thinking markup, but I'd be happy to contribute some examples to the wiki that might illustrate my pain
  1934. # [20:32] <jgraham> That doesn't follow the general layout of the W3C wiki
  1935. # [20:33] <jgraham> But I don't really care
  1936. # [20:33] <Wilto> jreading: I started a repo here a while back: https://github.com/Wilto/respimg
  1937. # [20:33] <jgraham> (I think the WhatWG wiki would be better since it doesn't require W3C Member access)
  1938. # [20:33] <Wilto> jreading: The WHATWG wiki page is more thorough, though.
  1939. # [20:34] <TabAtkins_> grigs: Time wasted writing specs is, fortunately, never a consideration when deciding on which solution to use. If we prioritized "time spent by an editor", we'd make *much* worse decisions in general.
  1940. # [20:34] * gwicke is now known as gwicke_away
  1941. # [20:34] <grigs> TabAtkins_: not my point. seriously.
  1942. # [20:34] <tantek> TabAtkins indeed.
  1943. # [20:34] <TabAtkins_> grigs: It definitely doesn't *feel* good to have something you've put time into not be used, but shrug. Good design must be egoless.
  1944. # [20:34] * Joins: PendragonDev (~IceChat77@ip-64-134-189-67.public.wayport.net)
  1945. # [20:35] <TabAtkins_> grigs: "still hard not to see time wasted writing a spec for picture if that wasn't reallly a good next step." Sorry if I misinterpreted this.
  1946. # [20:35] <tantek> good design must be based on referenceable real world use cases
  1947. # [20:35] <odinho> TabAtkins_: And sunken cost-less!
  1948. # [20:35] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Remote host closed the connection)
  1949. # [20:35] <TabAtkins_> odinho: Yeah.
  1950. # [20:36] * Joins: necolas (~necolas@5ade1e67.bb.sky.com)
  1951. # [20:37] <tantek> ShaneHudson - I added the URLs I mentioned below to help kickstart the /Images page - please feel free to rewrite the page as you see fit - I gave it a bit of skeleton structure to get started: http://www.w3.org/wiki/Images
  1952. # [20:37] <tantek> s/below/above
  1953. # [20:37] <grigs> TabAtkins_: that was in response to someone saying there wasn't wasted time spent in the community group, not in response to a question about the solution selected.
  1954. # [20:38] <tantek> grigs - time is usually most wasted on email lists / support forums.
  1955. # [20:38] * Joins: rpflo (~rpflo@216.51.73.6)
  1956. # [20:39] * Quits: chazcross (ad0a2166@gateway/web/freenode/ip.173.10.33.102) (Quit: Page closed)
  1957. # [20:39] <ShaneHudson> tantek: Thank you :) I have not written anything quite like this before so anyone feel free to help and suggest improvements
  1958. # [20:39] <ShaneHudson> Will get started on it in about 30 mins, not cooked dinner yet
  1959. # [20:41] <tantek> ShaneHudson - we had similar problems with trying to expand the time element, and only by writing down discrete use-cases on the wiki were we able to discuss them individually, find out which were actually important (and which were not) and then *lastly* decide on syntax to support the rough consensus of useful/important use cases.
  1960. # [20:41] <grigs> my point is that for people outside the standards process who would like to see something change in html, the process for contributing was confusing. so we asked a lot of questions. it was unclear who could provide definitive answers. a lot of time was spent with incorrect assumptions (no modifications to img tag) and jumping through hoops that may or may not have made sense (writing a spec when maybe we should have been working on use cases).
  1961. # [20:41] <tantek> point being, not all the use-cases were satisfied, that's OK.
  1962. # [20:41] <grigs> anyways, for next time, it would be nice to have something a little clearer for outsiders. which was my original point. :-)
  1963. # [20:41] <tantek> " we asked a lot of questions. it was unclear who could provide definitive answers. a lot of time was spent with incorrect assumptions " ==> sign of a support forum
  1964. # [20:42] <TabAtkins_> grigs: Ah, sure. Yeah, standards is hard.
  1965. # [20:42] <grigs> any disagreement with that?
  1966. # [20:42] * Joins: davatron5000 (~dave@cpe-66-25-175-141.austin.res.rr.com)
  1967. # [20:42] <TabAtkins_> The takeaway is: present persuasive arguments, and figure out who will actually be making the decision, so you can decide what sort of presentation will work best for them.
  1968. # [20:42] <TabAtkins_> Everything else is details.
  1969. # [20:43] * Joins: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
  1970. # [20:43] <tantek> grigs - yes, framing "outsiders" is imprecise. at the end of the day, Hixie is the editor of HTML, everyone else contributes their input/opinions.
  1971. # [20:43] * Parts: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
  1972. # [20:43] * Joins: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
  1973. # [20:43] <TabAtkins_> For Hixie, for example, you just need persuasive use-cases. Examples of solutions can be useful, but are not required. However, they can be used to point out specific corners of the problem-space that need to be looked at.
  1974. # [20:46] * Joins: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42)
  1975. # [20:47] <tantek> adactio (late follow-up to your message) - Hixie experiments with adding things to the spec, and then sometimes removing them. If you're ok with (a believer in) "HTML the living standard" - then you're ok with that level of spec frothiness. The current alternative is to wait for things to stabilize / percolate into a W3C snapshot on TR.
  1976. # [20:47] * Joins: drublic (~drublic@frbg-5f73366a.pool.mediaWays.net)
  1977. # [20:47] <grigs> tantek: would replacing "outsiders" with "people new to the whatwg standards process" be sufficient? i think we're just talking semantics.
  1978. # [20:47] <tantek> outsiders just means anyone not editing the spec ;)
  1979. # [20:47] * Joins: yodasw16 (~dgillhesp@ql1fwhide.rockfin.com)
  1980. # [20:48] <adactio> grigs: What do you mean exactly by "semantics?" ;-)
  1981. # [20:48] <tantek> adactio LOL
  1982. # [20:48] <grigs> adactio: LOL
  1983. # [20:48] <grigs> https://twitter.com/#!/adactio/status/197343204683694080
  1984. # [20:49] <grigs> I’ve got that tweet favorited.
  1985. # [20:49] <zewt> so many quotostrophes
  1986. # [20:49] * Quits: maikmerten (~maikmerte@port-92-201-49-70.dynamic.qsc.de) (Remote host closed the connection)
  1987. # [20:49] * Parts: rpflo (~rpflo@216.51.73.6)
  1988. # [20:52] <grigs> tantek: a support forum would be nice. my fear in starting the community group is that we would persist in silo-iziation/tribalization and wouldn’t get the feedback we needed from people with more experience to really test our assumptions and conclusions.
  1989. # [20:53] <zewt> the biggest problem I've seen with CGs is that for some bizarre reason, they all feel the need to set up little isolated mailing lists instead of using the larger lists that people are actually on
  1990. # [20:53] * Joins: necolas_ (~necolas@80.231.76.54)
  1991. # [20:53] <tantek> grigs, sometimes it's useful to get a smaller group of people together to agree on some set of clear principles, use-cases etc. in order to write them down as such for review/feedback by a broader audience.
  1992. # [20:53] <grigs> tantek: perhaps some specific place to get that guidance would have helped. it could have made it clear that persuasive use cases was where to focus energy
  1993. # [20:54] <zewt> tantek: i disagree; better off having the largest (relevant) audience possible, so you don't waste time with false starts that could be avoided with the right input (which you miss due to isolation)
  1994. # [20:54] <tantek> zewt - the CG mechanics setup those lists by default. It's just bad UX, or rather, email-list-silo based UX (which is a traditional assumption of most standards orgs)
  1995. # [20:54] <grigs> zewt: blame the tool makers, not the CG users.
  1996. # [20:54] <tantek> grigs - from my understanding the recommendation to document persuasive use-cases is quite prevalent
  1997. # [20:54] <tantek> \
  1998. # [20:55] * Joins: nick_evans (~nicholas@static-98-113-167-42.nycmny.fios.verizon.net)
  1999. # [20:55] <tantek> e.g. http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
  2000. # [20:55] <tantek> steps 1 and 2
  2001. # [20:55] <tantek> 1. Research the use cases and requirements by discussing the issue with authors and implementors.
  2002. # [20:55] <tantek> 2. Come up with a clear description of the problem that needs to be solved
  2003. # [20:55] * Quits: TabAtkins_ (jackalmage@50-0-151-4.dsl.dynamic.sonic.net) (Ping timeout: 248 seconds)
  2004. # [20:56] <scottjehl> tantek did the CG not follow that process in your opinion?
  2005. # [20:56] * Joins: jrschuhs (~jrschuhs@129-7-150-176.dhcp.uh.edu)
  2006. # [20:56] <grigs> tantek: that seems fair. perhaps we got a lot of bad advice during the process. hard to figure out where we went astray.
  2007. # [20:57] * Quits: adactio (~adactio@cust217-dsl91-135-3.idnet.net) (Quit: adactio)
  2008. # [20:57] <tantek> scottjehl - no - based on my request to see a simple wiki page of use-cases and there not being one.
  2009. # [20:57] <tantek> the blog post was an excellent start
  2010. # [20:57] <tantek> but blog posts are snapshots
  2011. # [20:57] <tantek> they're not "living"
  2012. # [20:57] * jrschuhs is now known as rainerschuhsler
  2013. # [20:57] <tantek> grigs - "bad advice during the process" - yes that's what happens on mailing lists / support forums.
  2014. # [20:58] <grigs> tantek: and the alternative is?
  2015. # [20:58] <grigs> tantek: i thought you were suggesting support forums. i think i missed your earlier point.
  2016. # [20:58] <tantek> 1. document your research on an open wiki page, 2. post URLs on IRC etc. to gather feedback
  2017. # [20:59] <tantek> posting actual "content" on email lists is pretty much a waste of time
  2018. # [20:59] <jgraham> To be clear tantek's views on how to do things are personal.
  2019. # [20:59] <Wilto> tantek: This sounds a lot like what I did with http://wiki.whatwg.org/wiki/Adaptive_images?
  2020. # [20:59] <tantek> jgraham - no, the data fits my generazliations.
  2021. # [20:59] <tantek> generalizations even.
  2022. # [20:59] <jgraham> So you claim
  2023. # [20:59] <tantek> the bad advice that the respimg folks got on the whatwg list is just the latest example
  2024. # [20:59] <tantek> no, not claim - have URLs
  2025. # [20:59] <tantek> people already posted them above
  2026. # [21:00] <jgraham> Anyway the point that you should collect use cases first and present use cases before solutions is sound
  2027. # [21:00] <scottjehl> jgraham we certainly did that
  2028. # [21:00] <jgraham> scottjehl: That isn't clear
  2029. # [21:00] <tantek> scottjehl - I have to agree with jgraham on that - that part wasn't clear.
  2030. # [21:01] <jgraham> At least the wiki page I have seen that claims to have use cases mostly has solutions
  2031. # [21:01] <tantek> posting use-cases on a wiki page helps make it *more* clear
  2032. # [21:01] <othermaciej> tantek: what bad advice do you think the respimg guys got on the whatwg mailing list?
  2033. # [21:01] * Quits: necolas_ (~necolas@80.231.76.54) (Ping timeout: 265 seconds)
  2034. # [21:01] * Joins: esc_ (~esc_ape@178.115.248.12.wireless.dyn.drei.com)
  2035. # [21:01] <othermaciej> (interested in hearing because it would be good to ensure future contributors get good advice)
  2036. # [21:01] <tantek> jgraham - agreed. intermingling a particular syntax among use-cases is not helpful.
  2037. # [21:01] <Wilto> No one responded to my post linking http://wiki.whatwg.org/wiki/Adaptive_images to tell me that it wasn’t the correct way to handle use cases.
  2038. # [21:01] <Wilto> It just got ignored, I assume because it is “done wrong.”
  2039. # [21:01] <tantek> Wilto - what post? to a mailing list?
  2040. # [21:01] <Wilto> Yes.
  2041. # [21:01] <tantek> Wilto - most email is ignored
  2042. # [21:01] <grigs> wilto: yeah, tantek did. he said it includes picture element.
  2043. # [21:01] <tantek> it's an inherent problem with the medium
  2044. # [21:01] <tantek> especially lists
  2045. # [21:02] <tantek> "someone else will handle it"
  2046. # [21:02] <Wilto> Eesh.
  2047. # [21:02] <jgraham> Wilto: At the time I tried to suggest that you focused more on use cases. Apparently I wasn't cler nough nd didn't follow thorugh. Sorry.
  2048. # [21:02] <grigs> Wilto: i missed his comment when it went past the first time, but it is in the irc logs.
  2049. # [21:02] <Wilto> I mean, that is fair: this was mentioned, and you guys did try to help. I think I just misinterpreted the feedback somewhat.
  2050. # [21:02] <grigs> Wilto: nevermind. i misunderstood.
  2051. # [21:03] <Wilto> But, yeah—nothing on the mailing list.
  2052. # [21:03] <scottjehl> the CG is where we were told to post and plan it, though. @wilto constantly asked around to ensure we were following the procedures that would get us into the conversation. If that was an inadequate location for planning the feature, we would have loved to have been told that before a completely new solution was invented.
  2053. # [21:03] <grigs> Yeah. :-(
  2054. # [21:04] <Wilto> Dead-on as always, scottjehl.
  2055. # [21:05] <zewt> mail to the whatwg list always gets a reply ... but hixie is overloaded, so sometimes it takes a *long* time
  2056. # [21:05] <jgraham> I think the big thing lacking from the CG was implementors. You are unlikely to get people to implement something that they don't know about and haven't given feedback on
  2057. # [21:05] <jgraham> The place where implementors (except Microsoft) typically work on HTML is WHATWG
  2058. # [21:05] * Joins: anon (aa8c6801@gateway/web/freenode/ip.170.140.104.1)
  2059. # [21:05] <grigs> jgraham: amen. that is what I asked about specifically BEFORE the CG was created: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034790.html
  2060. # [21:06] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
  2061. # [21:06] * Joins: Guest1064 (~anonymous@87.115.113.220)
  2062. # [21:06] <grigs> If there is anything that bums me out about this, it is the fact it was perfectly predicable and despite our efforts, seemingly unavoidable.
  2063. # [21:07] <zewt> the mail you're replying to was wrong; whatwg is definitely the place for that discussion, IMO
  2064. # [21:07] <jgraham> FWIW the CG might have been a good place to gather *requirements*
  2065. # [21:07] * Joins: weinig (~weinig@2620:149:4:1b01:dae:2278:8d0c:bd0c)
  2066. # [21:07] <scottjehl> this is all very hard to hear now, naturally
  2067. # [21:07] <smaug____> Web Audio API is horrible. Hard to even start reviewing because everything is so under-defined
  2068. # [21:08] <odinho> scottjehl: http://odin.s0.no/web/srcset/polyfill.htm
  2069. # [21:08] <jgraham> grigs: So we will do better next time :)
  2070. # [21:08] <odinho> scottjehl: So, come with all the bugs. :P
  2071. # [21:09] <zewt> (don't know who "ronjec viktor" is, don't recall seeing his name before)
  2072. # [21:09] * Joins: CCD (~fragile@host86-132-138-217.range86-132.btcentralplus.com)
  2073. # [21:09] <tantek> jgraham - yes, CGs are plenty fine places to gather and even prioritize requirements and use-cases
  2074. # [21:09] <Wilto> I’m not comfortable saying “oh well, this is a forgone conclusion because the process is broken; better luck next time.”
  2075. # [21:09] <tantek> but I think bikeshedding a solution is too tempting for any group to avoid
  2076. # [21:10] <jgraham> Wilto: There is no "conclusion" yet
  2077. # [21:10] <tantek> grigs, Wilto, scottjehl, more on the problems of doing most work on email lists (rather than doing most work on wikis instead) http://microformats.org/wiki/wiki-better-than-email
  2078. # [21:10] <Wilto> Fair.
  2079. # [21:10] <jgraham> Not much has happened really
  2080. # [21:10] * tantek agrees with jgraham
  2081. # [21:11] <jgraham> Hixie has been convinced that a set of requirements exist that are worth solving
  2082. # [21:11] <zewt> lots of very useful discussions like this happen on email; it's when people go to a wiki that I cringe at the distracting waste of time
  2083. # [21:11] <tantek> there's still quite the opportunity to define prioritized requirements and use-cases
  2084. # [21:11] <Wilto> Oh no—by no means to I consider this a done deal.
  2085. # [21:11] <jgraham> Whether or not these are the same requirements that you have is still unclear
  2086. # [21:11] <Wilto> do I.
  2087. # [21:11] <jgraham> There is no implementation and so no lock-in
  2088. # [21:11] <tantek> zewt - I mostly see discussions either repeated, or based in theory in email
  2089. # [21:12] <grigs> Slightly different topic: I have a question about a use case that I’ll document on the stub page later today.
  2090. # [21:12] * Parts: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
  2091. # [21:13] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
  2092. # [21:13] <grigs> One of the use cases that I see is for the image changing at different sizes. I used a Nokia Browser page as an example on the mailing list: http://browser.nokia.com/smartphones.html
  2093. # [21:13] <zewt> tantek: a wiki doesn't stop email; it just duplicates it
  2094. # [21:14] <grigs> The browser for Meego image changes depending on the viewport width.
  2095. # [21:14] <scottjehl> jgraham: why isn't the feature driven by web developers' well-known documented needs? I think the web development community has been very clear about the requirements we've needed for this, placing them in the place we were told would be noticed by implementors and spec writers. Why didn't these use cases drive the spec? Is the problem truly that our planning was in the wrong location on the web?
  2096. # [21:14] <grigs> I see this as being something that a lot of sites would do with header graphics on home pages. There aren't many examples in the wild because you can't do it with img yet.
  2097. # [21:15] * Quits: pablof (~pablof@144.189.101.1) (Ping timeout: 240 seconds)
  2098. # [21:15] * Joins: frenkie (~frenkie@dhcp-077-251-134-060.chello.nl)
  2099. # [21:15] <jgraham> scottjehl: I think you are overestimating the clarity of the requirements
  2100. # [21:15] <grigs> I'm pretty sure to support this use case, the change in image has to be aware of breakpoints because not only does the image change, but also things like whether or not the text next it to floats also changes.
  2101. # [21:16] * Joins: cafesofie (~user@ool-18e4c9a0.dyn.optonline.net)
  2102. # [21:16] <scottjehl> I don't think anyone involved in the CG was unclear about them
  2103. # [21:17] <grigs> For example, it seems likely that Apple would need something like this if they ever implemented as responsive design as their header images contain text and are <img> tags.
  2104. # [21:17] * Joins: Guest1064 (~anonymous@87.115.113.220)
  2105. # [21:17] * Quits: chippper (627ca660@gateway/web/freenode/ip.98.124.166.96) (Quit: Page closed)
  2106. # [21:18] <odinho> scottjehl: The use cases I saw on the blog seems to be covered by Hixie in his email. -- There's maybe one of cropping pictures (doing a landscape and portrait) that I'm not really sure I agree with, -- but it's in the current srcset spec right now. So that use case is also working.
  2107. # [21:18] <grigs> Anyways, the questions I have are 1) how to document use cases when you don’t have existing sites doing it, but seems likely 2) does the language I’m using make sense (e.g., header images). I fear I don’t have the right terminology to explain what I mean.
  2108. # [21:18] * Joins: manu1_ (~chatzilla@pool-71-171-16-71.nwrknj.east.verizon.net)
  2109. # [21:19] <scottjehl> grigs: perhaps, but often even a large image, when compressed well, is small enough in filesize that negotiation isn't necessary. I see this more useful for photography - say an article lead feature image. Dramatically different file sizes at different dimensions.
  2110. # [21:19] <tantek> zewt - actually it does, because it makes it trivial for anyone to reply with a URL and say - already discussed, see this.
  2111. # [21:19] <tantek> email duplicates email
  2112. # [21:19] * gwicke_away is now known as gwicke
  2113. # [21:20] <scottjehl> anyway, both use cases are kind of the same
  2114. # [21:20] <grigs> scottjehl: ha ha. your comment makes it clear my fear that i'm not explaining myself clearly is well-founded. :-)
  2115. # [21:20] * Joins: mswartz (~textual@64.119.159.250)
  2116. # [21:20] <tantek> scottjehl " web development community has been very clear about the requirements we've needed for this" - if anything the lack of such clarity should be obvious from this IRC conversation!
  2117. # [21:20] * Quits: manu1 (~chatzilla@pool-96-240-175-117.ronkva.east.verizon.net) (Ping timeout: 260 seconds)
  2118. # [21:20] * manu1_ is now known as manu1
  2119. # [21:21] * grigs going to lunch. back later.
  2120. # [21:21] <zewt> tantek: that's already trivial; a link to list archives
  2121. # [21:21] <scottjehl> tantek rehashing things we've already agreed upon in the wrong channel is all. These are the same use case
  2122. # [21:21] * Quits: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com) (Quit: ta-ra chuck)
  2123. # [21:21] <odinho> Wilto: Could you also quote what you are replying to, and answer at the bottom of that? I know it's a common concern, but when reading so much email on my phone as I'm doing now, it's nicer and easier to read/follow when people write it in that style on WHATWG list.
  2124. # [21:21] <tantek> "Why didn't these use cases drive the spec?" - were the use cases linked to with permalinks in all discussions of them? (I think not)
  2125. # [21:22] <Wilto> Sure thing, odinho. My mistake.
  2126. # [21:22] <jgraham> grigs: That use case is described as something like "on a large viewport width, a large wide image is loaded. On a smaller viewport a different image (e.g. a crop of the original) is loaded that is narrower allowing a different layout more sutiable for the screen size" or something
  2127. # [21:22] <tantek> "Is the problem truly that our planning was in the wrong location on the web?" - to some extent yes. Some places on the web are more findable than others. E.g. wiki pages are FAR more findable than archived emails (which may be just a fraction of a message in a longer thread which takes too long to re-read and parse)
  2128. # [21:23] * Quits: CCD (~fragile@host86-132-138-217.range86-132.btcentralplus.com) (Quit: Linkinus - http://linkinus.com)
  2129. # [21:23] <tantek> it's pretty simple actually. stop putting substantial content into email lists assuming people will see it and/or find it. they won't. this has been repeatedly shown/understood.
  2130. # [21:23] * Quits: PendragonDev (~IceChat77@ip-64-134-189-67.public.wayport.net) (Quit: Man who run behind car get exhausted)
  2131. # [21:23] <tantek> put substantial content on the web where it can be trivially found by search engines. wikis tend to be very good for that.
  2132. # [21:24] <zewt> i find mailing list conversations constantly; stuff on wikis is more hidden
  2133. # [21:24] * Joins: joshlockhart (~joshlockh@twdp-174-109-189-157.nc.res.rr.com)
  2134. # [21:24] <tantek> if someone asks you to use an email list, use it only to communicate very short summaries and permalinks to the aforementioned wiki pages
  2135. # [21:24] <zewt> gross
  2136. # [21:24] <odinho> Wilto: Thanks. :-)
  2137. # [21:24] * jernoble is now known as jernoble|afk
  2138. # [21:24] <scottjehl> tantek: re: permalinks: Fair enough, but we had no idea that any of our documentation was inadequate for the working group. We would have been thrilled if whatwg asked us to clarify portions to aid in their planning. No contact at all.
  2139. # [21:24] * Joins: sanjayb (~sanj@122.179.176.179)
  2140. # [21:24] <tantek> google (bing etc.) find thing things on wikis MUCH more easily than mailing lists
  2141. # [21:24] <zewt> wikis are pretty much useless for any kind of discussion
  2142. # [21:24] <tantek> so is email
  2143. # [21:25] <tantek> irc is a bit better
  2144. # [21:25] <zewt> uh, no it isn't?
  2145. # [21:25] * miketaylr is now known as miketaylrawaylol
  2146. # [21:25] <zewt> i've had countless useful discussions on email, so the claim just doesn't make any sense
  2147. # [21:25] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
  2148. # [21:26] <scottjehl> zewt sorry, my claim?
  2149. # [21:26] <tantek> scottjehl - there is no "whatwg" to have "asked" you to "clarify portions" - that's an illusion perpetrated by some individuals
  2150. # [21:26] <tantek> there is the editor of the spec, Hixie
  2151. # [21:26] <zewt> (your what?)
  2152. # [21:27] <scottjehl> zewt disregard sorry
  2153. # [21:27] <tantek> and there is the support forum known as the whatwg email lists, where people who claim to be a part of or not of it claim to speak on its behalf
  2154. # [21:27] <odinho> Email is nice for discussions, -- irc is nice for more rapid-fire and other types of discussion (even less permanent than email, and shorter bursts, no as thought out). -- Wiki's are the place to always update while you're having the discussion, filling out and having a nice permanent page for all the important points and conclusions being done whilst discussing in another forum.
  2155. # [21:27] * jonlee is now known as jonlee|afk
  2156. # [21:27] * jonlee|afk is now known as jonlee
  2157. # [21:28] <jgraham> You know this whole doublespeak thing of saying "support forum" instead of "mailing list" gets old fast
  2158. # [21:28] <tantek> etherpad is a nice realtime improvement upon wikis also - works better for some discussions
  2159. # [21:28] <zewt> http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent
  2160. # [21:28] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  2161. # [21:28] <tantek> jgraham - I don't think you understand what "doublespeak" means.
  2162. # [21:28] <scottjehl> yeah, picture planning originated in etherpad
  2163. # [21:28] <tantek> it's more like, acts like a duck, probably is a duck
  2164. # [21:28] <tantek> email lists that act like support forums may as well be considered support forums
  2165. # [21:29] <odinho> zewt: The hilighting makes things easier to follow. But still, it's really horrendous to read IRC logs when you want info. It's much better, but still very hard to read email discussions when you want to find out of something. Wiki's (or normal authored web pages) are better for that.
  2166. # [21:29] * Quits: anon (aa8c6801@gateway/web/freenode/ip.170.140.104.1) (Quit: Page closed)
  2167. # [21:29] <zewt> (i didn't say any of that, heh)
  2168. # [21:29] <odinho> zewt: Think if the HTML spec was the entire email archive, -- you just had to read through it (most often some of the last emails) to find out what happened :]
  2169. # [21:29] <tantek> hmm krijnhoetmer.nl appears to be slow to respond for me
  2170. # [21:29] <bjankord> CG was a great place to read info, far better than IRC logs or email lists
  2171. # [21:29] <scottjehl> +1
  2172. # [21:30] <bjankord> CG was also open to everyone
  2173. # [21:30] <bjankord> The best ideas rise to the top this way
  2174. # [21:30] <zewt> odinho: you seem to be responding to things i didn't say :)
  2175. # [21:31] * Joins: mkanat (mkanat@nat/google/x-znqjevxmhnykdspx)
  2176. # [21:31] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  2177. # [21:32] <odinho> 21:19 < zewt> http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent
  2178. # [21:32] <scottjehl> ...that the formatting of it was insufficient was never communicated to us, but we would have gladly made any changes that would have helped.
  2179. # [21:32] <odinho> zewt: You said that irc was sort of permanent.
  2180. # [21:32] <necolas> if the mailing list is the place to communicate with the whatwg / hixie, then perhaps it should be acknowledged that it is up to whatwg / hixie to communicate with other parties via the place they prefer to be involved (e.g. CG or w/e)
  2181. # [21:32] <scottjehl> Loads of developers actually thought they were taking the right steps to help plan this feature.
  2182. # [21:33] <zewt> odinho: ... none of what you said has anything to do with that :)
  2183. # [21:33] * Joins: jmather (~jmather@mail.bojigroup.com)
  2184. # [21:33] <zewt> i never said anything about reading IRC logs
  2185. # [21:33] * Joins: pablof (~pablof@144.189.101.1)
  2186. # [21:33] <zewt> only responding to "less permanent"
  2187. # [21:34] <bjankord> entering lurk mode
  2188. # [21:35] <scottjehl> http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/
  2189. # [21:35] * Quits: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  2190. # [21:35] <odinho> zewt: I talked about it, -- and your comment seemed to be pointed at me.
  2191. # [21:35] * Quits: foolip (~philip@node-7lfba0hyoe7wdhmug.a0.ipv6.opera.com) (Read error: Connection reset by peer)
  2192. # [21:35] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  2193. # [21:36] <MarcDrummond> The thing which I find disappointing is that there seems to be a whole lot of discussion about process going on here, and not a lot of discussion of the spec change.
  2194. # [21:36] <zewt> you said irc isn't permanent, which sounds like you don't know about the public logs, so i showed them to you; nothing more
  2195. # [21:36] <MarcDrummond> Obviously, process is important, but what we really care about is the implementation for responsive images.
  2196. # [21:37] * Joins: foolip_ (~philip@node-7lfbcq9y5f9l3btb6.a0.ipv6.opera.com)
  2197. # [21:37] <zewt> MarcDrummond: that belongs on the list, most of the time
  2198. # [21:38] <MarcDrummond> And so the wheel continues to spin.
  2199. # [21:38] <zewt> ...
  2200. # [21:38] <jgraham> MarcDrummond: If you have points that require real-time interaction feel free to discuss them here
  2201. # [21:38] <jgraham> If you have points that you want documented, use the wiki or the mailing list
  2202. # [21:39] * Joins: tobyo (~tobyo@cpe-24-165-22-166.san.res.rr.com)
  2203. # [21:39] * jernoble|afk is now known as jernoble
  2204. # [21:39] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  2205. # [21:39] <jmather> scottjehl: thanks for the link
  2206. # [21:40] <odinho> zewt: Hehe, I know very well about the krijnhoetmer.nl public logs. :-) I ever wrote a irc log indexer internally for Opera.
  2207. # [21:41] <tantek> thanks scottjehl for the ALA link - I added it to: http://www.w3.org/wiki/Images#see_also
  2208. # [21:41] <tantek> (which you should feel free to edit directly as well)
  2209. # [21:41] * Quits: erichynds (~ehynds@64.206.121.41)
  2210. # [21:42] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  2211. # [21:42] <MarcDrummond> One concern that I have, as an author, with srcset, is locking dimensions to pixels. I may want to define an image in ems, so that it can flex with text size changes, since my layout is defined with ems. Even though the image would degrade, it would still stay in proportion to the design.
  2212. # [21:42] * miketaylrawaylol is now known as miketaylr
  2213. # [21:42] * Joins: jarib (~jarib@unaffiliated/jarib)
  2214. # [21:42] <odinho> MarcDrummond: It has nothing to do with how the picture is presented. None whatsoever.
  2215. # [21:43] <jmather> MarcDrummond: I think srcset only sets rules on when to use which image, you can size it with css width/hight as normal
  2216. # [21:43] <odinho> MarcDrummond: You can write 100000000w for a picture that is 234px wide.
  2217. # [21:43] <scottjehl> sure thing
  2218. # [21:43] <tantek> MarcDrummond, when there's a breakdown (as seems obvious in this area), it makes sense to unwind to the point of where the breakdown in order to fix it and make progress again towards a solution for responsive images. It's pretty clear that the breakdown occurred at a difference of use-cases etc., so we're trying to figure out how to best resolve/communicate that and reach a rough consensus on use-cases (and their priorities).
  2219. # [21:43] <tantek> A solution that fails to solve the "important" use-cases is useless.
  2220. # [21:43] * Quits: sicking (~chatzilla@nat/mozilla/x-lvqdtqihpcubzkhh) (Ping timeout: 244 seconds)
  2221. # [21:43] <tantek> s/solution/implementation etc.
  2222. # [21:44] * Joins: rharr (~rharr@rrcs-98-100-9-178.central.biz.rr.com)
  2223. # [21:44] <zewt> (discussing here is fine, of course, but discussion *is* going on on the list, and if you want to make points that the wider audience--rather than whoever happens to be here right now--will see, that's the place to do it)
  2224. # [21:44] <jmather> scottjehl: this is totally OT, but i've been following your trip on twitter -- absolutely fantastic. It must be incredible.
  2225. # [21:45] <jgraham> Right, the Aw Bh syntax is *somewhat* like a max-width:Apx max-height:Bpx media query
  2226. # [21:45] <tantek> zewt - apparently the list has a wider audience that includes sufficient misinformation (the "go away" email on whatwg) to actually *harm* discussion.
  2227. # [21:45] <jgraham> Uh, +viewport somewhere
  2228. # [21:46] <zewt> tantek: that's uncommon, and present in all media
  2229. # [21:46] <MarcDrummond> I thought somebody said above that nobody reads email, or at least not in a timely manner. Was that in relation to the listserv or emails sent directly to a person?
  2230. # [21:46] <jgraham> It basically means "don't display this image unless the viewport is at least A x B"
  2231. # [21:46] <tantek> zewt - nope. such miscommunication is quickly corrected in places like IRC. but not apparently email.
  2232. # [21:46] <scottjehl> jmather ah! Kind of you to say, thanks :)
  2233. # [21:46] <tantek> this is a failing of email, and especially heavy lists.
  2234. # [21:46] <tantek> too much crap goes by that no one bothers to correct, so it gets propagated.
  2235. # [21:46] <ShaneHudson> Talking of the list.. I posted to it earlier, I got a reply from Matt Wilcox but it is not in the archive... I did reply to him, so did I not send it properly? I had the list as a cc
  2236. # [21:46] <jgraham> MarcDrummond: tantek has an aversion to mailing lists which he spreads with evangelical fervour
  2237. # [21:47] <jmather> scottjehl: not kind really… I'm just jealous. Hah.
  2238. # [21:47] <tantek> jgraham - you can stop the ad hominem anytime you like.
  2239. # [21:47] <jgraham> tantek: Which part isn't true?
  2240. # [21:47] <tantek> I'm simply communicating based on actual experiences (with citations)
  2241. # [21:47] <othermaciej> tantek dislikes email and mailing lists more than most, Hixie (person who actually does much of the editing) likes email and mailing lists more than most
  2242. # [21:47] <tantek> you're on the otherhand simply being defensive about emailing lists
  2243. # [21:47] <odinho> othermaciej: Nice summary.
  2244. # [21:48] <jgraham> tantek: "Citations" being more or less anecdotes
  2245. # [21:48] <tantek> othermaciej - right, whatwg list works as inbox for Hixie, beyond that, it's effectively a support forum.
  2246. # [21:48] <jgraham> I'm saying that overall the WHATWG list has been super-effective
  2247. # [21:48] <othermaciej> in my observation, the whatwg list is reasonably functional, and to the extent it has failure modes, "support forum" does not strike me as a fair characterization thereof
  2248. # [21:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  2249. # [21:49] <tantek> jgraham - to URLs of actual occurrences yes. on the otherhand all you present is knee-jerk defensive reactions in IRC. anecdotes vs. IRC defensiveness, anecdotes are more persuasive.
  2250. # [21:49] <jgraham> And wikis have all sorts of problems that you don't mention e.g. people unwilling to trample other people's edits, not knowing which stuff is significant, edit/revert wars, etc.
  2251. # [21:49] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  2252. # [21:49] <jgraham> But I am not really interested in discussing the merits of these things
  2253. # [21:49] <jmather> scottjehl: I was a little disheartened when Jen pointed me to your picture implementation though. I thought I had something novel… :D
  2254. # [21:49] <tantek> then why do you keep bringing it up?
  2255. # [21:50] <othermaciej> maybe I don't understand what is meant by "support forum" but I imagine it means questions like "how do I use <video> on my website to play Flash videos?" or whatever, which seem rare
  2256. # [21:50] <tantek> othermaciej - it's a support forum for standards development for folks who don't realize they need a support forum.
  2257. # [21:50] <jgraham> The fact is that in order to engage with WHATWG/Hixie the mailing list is the primary veichle
  2258. # [21:50] <bjankord> Agreed
  2259. # [21:50] <tantek> nah, the whatwg list is a nice convenient public inbox for Hixie, nothing more really.
  2260. # [21:50] <jgraham> But you keep trying to discourage its use
  2261. # [21:50] <scottjehl> dropping off.
  2262. # [21:50] <othermaciej> whatwg is culturally friendly to use of a wiki in my experience, but if you avoid use of the mailing list entirely, you're gonna have a bad time
  2263. # [21:51] <jgraham> and are trying to coin some phrase to keep people away from it (the support forum thing)
  2264. # [21:51] <tantek> othermaciej, sure, because Hixie prefers it as his inbox, so it makes sense to send emails to whatwg accordingly.
  2265. # [21:51] * Joins: GAmini (407dba52@gateway/web/freenode/ip.64.125.186.82)
  2266. # [21:52] <tantek> jgraham, I'm not trying to discourage you from contributing to a support forum, please go on doing so.
  2267. # [21:52] <jgraham> See there we go again
  2268. # [21:52] <jgraham> It is tiresome
  2269. # [21:52] <jgraham> Plese stop
  2270. # [21:52] <jgraham> We are not children
  2271. # [21:52] <othermaciej> tantek: it is kind of trollish to refer to a communication medium repeatedly using a term that its participants would not self-apply
  2272. # [21:52] <tantek> primarily Hixie's inbox?
  2273. # [21:53] <othermaciej> "support forum"
  2274. # [21:54] <othermaciej> the whatwg.org site identifies it as "A discussion list for feedback on the specs", and says "The WHAT Working Group discusses issues and new proposals on an open and public mailing list, whatwg@whatwg.org. Discussion from interested parties is welcome."
  2275. # [21:54] <othermaciej> in my experience, many active participants on the list see it that way as well
  2276. # [21:54] <tantek> othermaciej, perhaps those that tend to realize it's more of a support forum then go ahead and spend their energies elsewhere, leaving only those who haven't yet realized it. so it's not necessarily unreasonable that current active participants would not self-apply the description.
  2277. # [21:54] * Quits: raphc (~rc@92.103.77.27) (Ping timeout: 272 seconds)
  2278. # [21:55] * Joins: saba (~foo@unaffiliated/saba)
  2279. # [21:55] <tantek> btw - I would say the same about public-html as well FWIW.
  2280. # [21:55] <othermaciej> you may well have a point that discussion lists have intrinsic dysfunctions by nature
  2281. # [21:55] <tantek> sure, there are intrinsic dysfunctions, that's perhaps a broader statement.
  2282. # [21:55] <othermaciej> but referring to the discussion list with a dismissive term is somewhat rude and not a very effective way to make that point
  2283. # [21:55] <tantek> I mean more that discussion lists tend to become support forums, and have seen this occur with pretty much every standards list.
  2284. # [21:55] <othermaciej> doing so is likely to generate more heat than light
  2285. # [21:55] <jgraham> I am unaware of any communication medium that doesn't have some dysfunction
  2286. # [21:56] <tantek> othermaciej - if it helps a few more folks come to the support forum realizations and then spend their energies more effectively elsewhere (or focus their list posts accordingly), then that provides a net benefit.
  2287. # [21:57] <jgraham> And for any reasonable definition of "support forum" the whatwg list isn't. People almost never ask how-to type questions there.
  2288. # [21:57] <tantek> you're right that it will/does cause some to react defensively and simply dig-in to support a tradition.
  2289. # [21:57] <jgraham> Anyway like I say, this is dull
  2290. # [21:57] <MarcDrummond> Wilto has does an excellent job writing up a description of the current conundrum, and why picture would likely work far better than srcset: http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/
  2291. # [21:58] <othermaciej> tantek: mentioning a few times that "mailing lists tend to turn into support forums, in my experience" or something like that seems like a fine and effective way to make the point
  2292. # [21:58] <tantek> right, it's not an explicit support forum, it's an implicit support forum. people don't ask "how to" questions, people ask for features etc. which are implicit "how do I do this" type questions.
  2293. # [21:58] * Joins: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net)
  2294. # [21:58] <othermaciej> tantek: thereafter always using the term "support forum" to refer to the list is likely to cause more disruption and meta-discussion than effective persuasion
  2295. # [21:58] <ShaneHudson> I was surprised to see he was able to ublish to ALA so quickly,I would expect to wait for ages!
  2296. # [21:58] <jmather> tantek: I just joined the chat here, but i wanted to tell you, you're coming off as someone who seems to have an axe to grind, and nobody suitable to grind it with. I don't know what you're expecting to get out of the exchange you're engaging in but I hope it's worth it.
  2297. # [21:58] <tantek> MarcDrummond, why limit yourself to two possible solutions?
  2298. # [21:58] <tantek> when the use-cases aren't even broadly understood, prioritized, and agreed upon?
  2299. # [21:59] <othermaciej> particularly since the core of a community is likely most invested in its traditions, yet also ultimately needs to be influenced if there's a desire to change the process'
  2300. # [21:59] <tantek> othermaciej - I'm not sure about that, I think if Hixie is influenced, that's sufficient for change (in the spec or elsewhere)
  2301. # [22:00] <tantek> the "community" doesn't really have much power in that way
  2302. # [22:01] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  2303. # [22:01] <tantek> jmather, as a counter to your "axe to grind", I'd offer only the fact that it's jgraham who has used terms like "doublespeak" and "evangelical" in a directed personal attack manner, not I. Such ad hominem behavior is usually an indication of failure to engage in more substantial discussion.
  2304. # [22:02] <othermaciej> well, if you want to point out to Hixie that his mailing list is a support forum and encourage him to stop using it (as much), it might be less disruptive to do that elsewhere
  2305. # [22:02] <ShaneHudson> So is Hixie in charge of the entire spec? Still trying to get my head around the pecking order
  2306. # [22:02] <necolas> tantek: agreed. it shouldn't be about one early proposal vs another.
  2307. # [22:02] <tantek> ShaneHudson, yes, Hixie is the editor of HTML.
  2308. # [22:02] <othermaciej> Hixie derives his influence in large part from being responsive to other influential people
  2309. # [22:03] <jmather> tantek: Like I said, I just entered the room here recently, so I don't have historical context, but i'd hope if I were coming off poorly someone would let me know, so I was just trying to do you a favor. Not trying to be rude, just maybe suggesting to grab a breather and reassess of what you're doing right now is worth the effort. :)
  2310. # [22:03] <annevk> tantek: is there a wiki page for your suggested process or do I have to extract it from the IRC logs somehow?
  2311. # [22:03] * annevk can probably read a little backlog
  2312. # [22:03] <tantek> othermaciej, I've discussed this with Hixie, and for him, using the list as a personal public inbox works for him, so I'm not going to argue with that. we all have our own personal ways to get our work done.
  2313. # [22:03] <ShaneHudson> tantek: Thanks.. I didn't realise before there was one person in charge
  2314. # [22:03] <tantek> annevk - I was citing whatwg FAQ earlier.
  2315. # [22:03] <necolas> i'd just like to reiterate the point that "forward hixie's email to the CG" doesn't really constitute what i would consider an acceptable level of outreach to the wider community
  2316. # [22:03] * Joins: garand (4086afc1@gateway/web/freenode/ip.64.134.175.193)
  2317. # [22:03] <othermaciej> that being said, he <3s email as a communication channel, and it's unlikely he could be convinced to use it much less without very good reson
  2318. # [22:04] <tantek> jmather - you're right, this discussion is likely beyond the point of diminishing returns.
  2319. # [22:04] <annevk> tantek: I thought your point was that the mailing list didn't work; I was wondering what you think would be better
  2320. # [22:04] <MarcDrummond> tantek: In theory, there are an infinite number of solutions. In practice, numerous web developers have coalesced around the picture solution on one hand, while WHATWG has published srcset as the proposed solution, with very little discussion (or use cases).
  2321. # [22:04] <tantek> annevk - I've continuously reiterated the request for well documented use-cases.
  2322. # [22:04] <ShaneHudson> tantek: I am working on the use-cases now :)
  2323. # [22:04] <tantek> which from my understanding is what WHATWG tends to prefer ;)
  2324. # [22:04] <annevk> tantek: there's http://wiki.whatwg.org/wiki/Adaptive_images
  2325. # [22:04] * Quits: rainerschuhsler (~jrschuhs@129-7-150-176.dhcp.uh.edu) (Quit: Linkinus - http://linkinus.com)
  2326. # [22:05] <MarcDrummond> tantek: But I'm quessing your question was rhetorical, since you know all that.
  2327. # [22:05] <tantek> annevk - that page is problematic because it presumes <picture> too much
  2328. # [22:05] <annevk> tantek: and they have been provided via email too, I think Hixie mentioned them upfront
  2329. # [22:05] * Quits: garand (4086afc1@gateway/web/freenode/ip.64.134.175.193) (Client Quit)
  2330. # [22:05] <annevk> tantek: easy enough to read around that
  2331. # [22:05] <jgraham> annevk: Beter to edit around it
  2332. # [22:05] <jgraham> i.e. rewrite the page
  2333. # [22:05] <othermaciej> annevk: do you understand how the "DOM Scripting and Bandwidth" item on that paye is a use case?
  2334. # [22:05] <tantek> annevk - better is: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/
  2335. # [22:05] <jgraham> But some people wanted accounts
  2336. # [22:05] <tantek> but that's not on a wiki page
  2337. # [22:05] <jgraham> Do you have admin access?
  2338. # [22:05] <tantek> so it can't be edited/ prioritized etc.
  2339. # [22:06] <ShaneHudson> annevk: We came to the decision that use-cases are all over the places, so we are putting together a page on the wiki to define them once and for all
  2340. # [22:06] <annevk> othermaciej: I don't agree with all the use cases :)
  2341. # [22:06] <ShaneHudson> http://www.w3.org/wiki/Images
  2342. # [22:06] <annevk> jgraham: I do
  2343. # [22:06] <jgraham> Someone also started a page on the W3C wiki, but you need a W3C ccount to edit that
  2344. # [22:06] <annevk> haha
  2345. # [22:06] <annevk> four places already
  2346. # [22:06] <tantek> annevk - exactly, we need this on a wiki so we can all contribute to the use-cases
  2347. # [22:06] <annevk> way to go internet :)
  2348. # [22:06] <ShaneHudson> (I am writing it at the moment, but that is the page it will be)
  2349. # [22:06] * Joins: jarek (~jarek@bcr1.neoplus.adsl.tpnet.pl)
  2350. # [22:06] * Quits: jarek (~jarek@bcr1.neoplus.adsl.tpnet.pl) (Changing host)
  2351. # [22:06] * Joins: jarek (~jarek@unaffiliated/jarek)
  2352. # [22:06] <tantek> thanks ShaneHudson
  2353. # [22:07] * Quits: eric_carlson (~eric@17.212.152.104) (Quit: eric_carlson)
  2354. # [22:07] <jgraham> tantek: Which of the muliple wikis it is on did you have in mind
  2355. # [22:07] <othermaciej> <http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/> is cool, would be nice to consolidate that with one of the wiki-based efforts
  2356. # [22:07] <jgraham> (all with non-overlapping sets of authorised users)
  2357. # [22:07] <jmather> othermaciej: I think someone is working on that...
  2358. # [22:07] <tantek> othermaciej - my conclusion exactly
  2359. # [22:07] <annevk> tantek: anyway I was talking about your meta point, the mailing list being a "support forum"
  2360. # [22:07] <ShaneHudson> In fact, if everyone wants to post or email (shane@shanehudson.net) what use-cases you think there are then I will compile them with the others
  2361. # [22:07] <jmather> but i could have misunderstood what's going on here. :D
  2362. # [22:07] * Joins: eric_carlson (ericc@nat/google/x-pyurtiwfinnqjfms)
  2363. # [22:07] <Philip`> Someone should set up a Tumblr with a list of all the wikis
  2364. # [22:07] <annevk> tantek: you mentioned that irl before, but I didn't quite what you meant or what you want to replace it with
  2365. # [22:07] * Joins: malydok (~marek@moma.t16.ds.pwr.wroc.pl)
  2366. # [22:08] <tantek> jgraham - re: which wiki, I asked, and people didn't seem to have a preference. so given that WHATCG exists right now, I suggested w3.org/wiki (not the respimg community wiki) so that anyone with a w3c account could edit/contribute
  2367. # [22:08] <jgraham> That seems to exclude most developers
  2368. # [22:09] <tantek> annevk - it's more of a transition than a replacement outright. the more content can be published in places that can be edited/updated/linked-to, the better. email for sending around links to such content is fine.
  2369. # [22:09] <jgraham> Also, http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ is indeed very nice
  2370. # [22:09] <jmather> jgraham: which is kind of what is causing the current uproar, which might not want to be perpetuated...
  2371. # [22:09] <tantek> annevk - here's some more reading on it: http://microformats.org/wiki/wiki-better-than-email
  2372. # [22:09] <tantek> jgraham - yes, even just moving that blog post to a wiki for iteration would be a huge help
  2373. # [22:09] <ShaneHudson> jgraham: I will add those points in that article to the wiki. Please stop moaning, instead helping would be appreciated
  2374. # [22:10] <tantek> I think we just need to give ShaneHudson some time to update w3.org/wiki/Images :)
  2375. # [22:10] * Quits: danielfilho (~daniel@187.31.77.7) (Quit: danielfilho)
  2376. # [22:10] <jmather> I don't think Anselm would be upset if someone copy/pasted it.
  2377. # [22:10] * jonlee is now known as jonlee|afk
  2378. # [22:10] * anatolbroder just wants to tell thank you to othermaciej and other nice guys who brought the srcset attribute
  2379. # [22:11] <othermaciej> very little of the credit goes to me!
  2380. # [22:12] <othermaciej> I did suggest the name "srcset" instead of "set", but otherwise most of the design and spec credit goes to hober and Hixie (as well as to people who provided use cases)
  2381. # [22:12] * Quits: frenkie (~frenkie@dhcp-077-251-134-060.chello.nl) (Quit: frenkie)
  2382. # [22:14] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
  2383. # [22:14] <tantek> annevk - since you asked, here's some more documentation on the matter: http://www.wikinomics.com/blog/uploads/wiki_collaboration2.jpg from http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/
  2384. # [22:15] * Quits: brucel (~brucel@cpc5-smal11-2-0-cust151.perr.cable.virginmedia.com) (Ping timeout: 272 seconds)
  2385. # [22:16] <jmather> Can I ask a question and have everyone just assume I'm not trolling and give me an honest answer? Because I'm honestly curious why srcset doesn't reuse media query "powers."
  2386. # [22:16] <jgraham> ShaneHudson: I am not moaning. I think I am suggesting that the W3C wiki is a bad choice of venue. But I don't want to stop you doing the work
  2387. # [22:16] * Joins: nickd_ (180c6b1d@gateway/web/freenode/ip.24.12.107.29)
  2388. # [22:17] * nickd_ is now known as _nickd
  2389. # [22:17] * Joins: adactio (~adactio@cust217-dsl91-135-3.idnet.net)
  2390. # [22:17] <annevk> tantek: mkay, I think we use wikis pretty often actually; they just haven't been used in this instance
  2391. # [22:17] <jmather> jgraham: can developers not get w3c logins? Is that an issue? or is it just that developers aren't likely to already have w3c logins and having it be a barrier to participate?
  2392. # [22:17] * Joins: vasko333 (~vasko_din@46.40.94.64)
  2393. # [22:17] <tantek> jgraham - if you could provide a link to your criticisms of the w3c wiki, I'd like to understand that better. thanks.
  2394. # [22:17] * Joins: import-logic (~ambience@cpe-066-057-225-104.nc.res.rr.com)
  2395. # [22:17] <jgraham> tantek: How does one get an account?
  2396. # [22:17] <tantek> annevk - agreed. that was part of my point.
  2397. # [22:17] <annevk> tantek: see e.g. timed tracks, the recent canvas additions
  2398. # [22:17] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  2399. # [22:17] <ShaneHudson> jmather: it is easier to access the w3c wiki than it is the whatwg, which is why we decided on it
  2400. # [22:18] <ShaneHudson> General question (perhaps tantek could answer).. I presume everyone is fine with me writing the wiki in British English?
  2401. # [22:18] * Quits: cheron (~cheron@unaffiliated/cheron) (Quit: Leaving.)
  2402. # [22:18] <tantek> jgraham, right at the top of the home page: http://www.w3.org/wiki/Main_Page
  2403. # [22:18] <tantek> Request a Public W3C Account to get started.
  2404. # [22:18] * Joins: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202)
  2405. # [22:18] <tantek> where Public W3C Account links to:
  2406. # [22:18] <tantek> http://www.w3.org/Help/Account/Request/Public
  2407. # [22:18] <MarcDrummond> Wish somebody would answer jmather's very reasonable question.
  2408. # [22:19] * JohnAlbin is now known as JohnAlbin_zzzzzz
  2409. # [22:19] <tantek> since it's right at the top of the home page, I'm not sure how that could be made more obvious
  2410. # [22:19] <import-logic> ShaneHudson: I don't see why it would matter, if anyone had a problem with that they would be way too picky :)
  2411. # [22:19] <jmather> ShaneHudson: ok, seems fair enough to me then. I was just curious if it was a "restricted membership" or something. I think it's fair to say if developers are stumped by a signup form they probably shouldn't participate. :D
  2412. # [22:19] <tantek> (i.e. not sure that adding it to an FAQ would help any)
  2413. # [22:19] * Quits: vasko333 (~vasko_din@46.40.94.64) (Remote host closed the connection)
  2414. # [22:19] <jgraham> tantek: It sounds a lot like it is for people who are becoming invited experts
  2415. # [22:19] <import-logic> jmather: lol'd
  2416. # [22:19] <jgraham> Anyway if it works for people I don't care
  2417. # [22:20] * Joins: aki_ (~aki_@CPE-72-128-75-73.wi.res.rr.com)
  2418. # [22:20] * doublec_ is now known as doublec
  2419. # [22:20] <tantek> jgraham really? the prose seems to make it clear there are many reasons: "Public accounts are necessary for a number of interactions with W3C, including ..."
  2420. # [22:20] * Joins: espadrine (~thaddee_t@nat/mozilla/x-mxhbowpmlthsaghx)
  2421. # [22:21] * Quits: doublec (~doublec@cd.pn) (Changing host)
  2422. # [22:21] * Joins: doublec (~doublec@unaffiliated/doublec)
  2423. # [22:21] <tantek> if you'd like to suggest different prose, I'm sure we could ask W3C to improve the content.
  2424. # [22:21] <annevk> afaik they can be created by anyone
  2425. # [22:21] <annevk> if people want an account on the WHATWG wiki btw I can create them
  2426. # [22:21] <jgraham> I'm reading the bit that says "W3C Public Accounts are for individuals who are not Member employees and who require access to the W3C Web site to register for W3C events and as part of the Invited Expert process."
  2427. # [22:21] <tantek> jmather, exactly, perhaps consider the sign-up form to be a light-weight captcha ;)
  2428. # [22:21] <annevk> we disabled account creation because of the amount of spam :(
  2429. # [22:21] <jmather> jgraham: it seems the CG account and the w3c account are one in the same (or somewhere along the line long ago i signed up with my new password -- which would be really weird.)
  2430. # [22:21] <jgraham> Neither of which is the case here
  2431. # [22:21] <jreading> marcDrummond & jmather: srcset doesn't do MQ because there is some concern over the "statefulness" of MQ over new spec'd solution. why it is considered a bug and not a feature I'm not sure
  2432. # [22:22] * Quits: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net) (Ping timeout: 272 seconds)
  2433. # [22:22] <annevk> jreading: MQs don't handle the pixel density case
  2434. # [22:22] <jgraham> jmather: If all the people who are interested in contributing have accounts there, that's fine
  2435. # [22:22] <tantek> jgraham - that text, e.g. "not Member employees" is nowhere on the page I linked to: http://www.w3.org/Help/Account/Request/Public so I'm not sure where you're getting that from
  2436. # [22:22] <jmather> annevk: I thought they did?
  2437. # [22:22] <annevk> jreading: they can query it, but you need to set the pixel density
  2438. # [22:22] * Joins: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be)
  2439. # [22:23] <jgraham> http://www.w3.org/wiki/index.php?title=Special:UserLogin&returnto=Main_Page then "Account Request Form"
  2440. # [22:23] * jonlee|afk is now known as jonlee
  2441. # [22:23] <tantek> a-ha! thanks
  2442. # [22:23] * Quits: _nickd (180c6b1d@gateway/web/freenode/ip.24.12.107.29) (Quit: Page closed)
  2443. # [22:24] <tantek> that page, http://www.w3.org/Help/Account/ , is quite confusing :/
  2444. # [22:24] <jmather> jreading: hrm… i haven't seen anything about statefulness… link?
  2445. # [22:24] <jmather> annevk: which pixel density case? link?
  2446. # [22:25] <annevk> jmather: you cannot do <img src=lala srcset="tralla 2x"> in a way that works properly using the <picture> proposal
  2447. # [22:25] <MarcDrummond> annevk: Why not?
  2448. # [22:25] <jmather> annevk: device-pixel-ratio: 2 in the media query should do it, no?
  2449. # [22:26] <annevk> jmather: how does that downscale "trallla"?
  2450. # [22:26] <annevk> "lala" is 10x10; "tralla" is obviously 20x20
  2451. # [22:26] <jmather> the width/height defined to the pixel element forms the size from what I understand (if I get your question right)
  2452. # [22:26] <annevk> if you just display tralla it would be way bigger
  2453. # [22:27] <ShaneHudson> Is resolution and DPI technically synomynous?
  2454. # [22:27] <annevk> jmather: so each source element would always have a width/height attribute?
  2455. # [22:27] <annevk> ShaneHudson: sure
  2456. # [22:27] <annevk> jmather: because all the <picture> examples got this wrong
  2457. # [22:27] <jreading> width/height attrs
  2458. # [22:27] * Joins: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com)
  2459. # [22:27] <MarcDrummond> annevk: You would provide the 2x version only if 2x is needed and another version for the standard. You can do that with MQs and picture just fine.
  2460. # [22:27] <ShaneHudson> annevk: thanks
  2461. # [22:27] <annevk> jmather: so nobody seems to be knowing what is going on
  2462. # [22:27] <jmather> annevk: from my understanding, sizing would work the same with srcset and picture
  2463. # [22:27] <annevk> jmather: and including them all over seems bloat
  2464. # [22:27] * Quits: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202) (Quit: Page closed)
  2465. # [22:27] <jreading> I may need to read through the email threads but, i don't know why the idea of tokenizing the MQ state in a global attr is not being throw around… both <picture> and srcset rely on too much repetition
  2466. # [22:28] <scottjehl> img: max-width: 100%; is commonly used in responsive layouts. It'd address that
  2467. # [22:28] <annevk> jmather: again, how does <picture> downscale it if you don't set height/width?
  2468. # [22:28] <annevk> scottjehl: that doesn't work for icons
  2469. # [22:28] <jreading> and why not work to improve MQs instead of creating a whole new spec outside of that...
  2470. # [22:28] <scottjehl> icons?
  2471. # [22:28] <MarcDrummond> annevk: why prioritize avoiding code bloat over clarity for authors and extensibility?
  2472. # [22:29] <annevk> jreading: MQ is about reading device info, it's not about sizing images
  2473. # [22:29] <jmather> annevk: I'm not the expert but i'd assume if we knew the ratio was 2 and had no other indicator, the browser could assume to display as 50% to producee a properly dimensioned image
  2474. # [22:29] <annevk> MarcDrummond: dunno, you think including height/width attributes all over is better?
  2475. # [22:29] <tantek> ok, I'm going to step back from this discussion until ShaneHudson has said he's got a draft of consolidated use-cases on w3.org/wiki/Images
  2476. # [22:29] <annevk> jmather: we don't know the ratio
  2477. # [22:29] <jmather> annevk: no other width/height would be included than with srcset
  2478. # [22:29] <jmather> annevk: but we do
  2479. # [22:29] <annevk> jmather: how?
  2480. # [22:29] * Joins: rakm (~rakm@sonic.mochaleaf.com)
  2481. # [22:29] <scottjehl> icons are the use case the makes picture impractical?
  2482. # [22:30] <jmather> device-pixel-ratio knows the density
  2483. # [22:30] <scottjehl> the/that
  2484. # [22:30] <jmather> and then downloading the picture gets the dimensions
  2485. # [22:30] <annevk> scottjehl: no
  2486. # [22:30] <annevk> jmather: what if the ratio of the device is greater than 2?
  2487. # [22:30] * Quits: graememcc (~chatzilla@host86-140-179-108.range86-140.btcentralplus.com) (Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120310193349])
  2488. # [22:30] <annevk> jmather: you need to know the ratio of the image, not the device
  2489. # [22:30] <jmather> on a 2x image, 1/2 the width/height would be the natural display size
  2490. # [22:30] <annevk> but the MQ applies to the device, not the image...
  2491. # [22:30] <jmather> annevkhwo often do you include images with no width/height?
  2492. # [22:31] <jmather> I've never done it, at least recently
  2493. # [22:31] <annevk> jmather: I do it all the time, but I'm told I'm not a normal author
  2494. # [22:31] <jmather> always at least width
  2495. # [22:31] <annevk> but you are shifting the argument now
  2496. # [22:31] <jmather> but then my main job is maintaining a CMS, so I have a different angle than a lot of people :)
  2497. # [22:31] <annevk> and again
  2498. # [22:31] <scottjehl> very common in responsive design to omit width and height attrs
  2499. # [22:31] <annevk> all the <picture> examples thus far got this wrong
  2500. # [22:31] <jmather> Not trying to shift the argument, just answering your questions
  2501. # [22:32] <scottjehl> annevk - I'm unclear what "this" is that you're referring to
  2502. # [22:32] <MarcDrummond> annevk: I really don't understand the concern of what to do if device is not 2x. Authors are going to include the standard res version AND a HD version. Or Super HD. Or whatever. I don't understand what the issue is with that?
  2503. # [22:32] <annevk> scottjehl: it's not just icons, you wouldn't want to stretch a big photo all the time either, it would not look great
  2504. # [22:32] <jmather> scottjehl: but even then you would still have width: 100% or whatnot in the css applied to it somewhere, right?
  2505. # [22:32] * Joins: dreadnaut (~Miranda@188-221-64-204.zone12.bethere.co.uk)
  2506. # [22:32] <scottjehl> jmather yes max-width: 100% is the usual fluid images CSS
  2507. # [22:32] <jmather> right
  2508. # [22:33] <jmather> annevk's argument is what happens when there is /no/ width/height guideline
  2509. # [22:33] <tantek> ShaneHudson: re: "everyone is fine with me writing the wiki in British English?" - I think that's fine for the W3C wiki. W3C specs use US English, and as does the microformats wiki. http://microformats.org/wiki/en-us and http://www.w3.org/2001/06/manual/#Spelling
  2510. # [22:33] <annevk> MarcDrummond: <img src=x srcset="y 2x"> x is 10x10; y is 20x20
  2511. # [22:33] <annevk> MarcDrummond: tell me how to do that with <picture>
  2512. # [22:33] <jreading> <picture> <source media="device-pixel-densiity:2" src="2xbig.jpg" width="50%">
  2513. # [22:33] * Joins: atadams (80f901c2@gateway/web/freenode/ip.128.249.1.194)
  2514. # [22:33] <jreading> how's that?
  2515. # [22:33] <annevk> that's not the same
  2516. # [22:34] <jreading> .picture {width:100%}
  2517. # [22:34] <scottjehl> no no. width: 100% would stretch an image, sure. But max-width: 100% never goes beyond the dimensions of the image itself
  2518. # [22:34] <ShaneHudson> annevk: I am not paying much attention here at the moment, please let me know if you have found something all the other articles (of which I am using to compile the wiki) have gotten wrong
  2519. # [22:34] <ShaneHudson> tantek: Thanks, I don't think I am ready to write the actual spec quite yet :p
  2520. # [22:34] * Quits: weinig (~weinig@2620:149:4:1b01:dae:2278:8d0c:bd0c) (Quit: weinig)
  2521. # [22:34] <annevk> scottjehl: it would be displayed four times the size if you just use max-width
  2522. # [22:34] <ShaneHudson> Hard enough writing a wiki haha
  2523. # [22:34] <MarcDrummond> annevk: <picture alt=""> <source src="x.jpg" /> <source src="y.jpg" media="min-device-pixel-ratio: 2" /> <img src="x.jpg" /> </picture>
  2524. # [22:34] <annevk> MarcDrummond: yeah that fails
  2525. # [22:35] <MarcDrummond> annevk: Why?
  2526. # [22:35] <annevk> MarcDrummond: if y is selected it would be displayed four times as big as x
  2527. # [22:35] <jmather> annevk: why?
  2528. # [22:35] <jgraham> FWIW I think this is reenforcing my belief that media queries are only a superficially good match for this use case
  2529. # [22:35] <MarcDrummond> annevk: I don't see why that would be the case.
  2530. # [22:35] <annevk> the reason is this
  2531. # [22:35] <annevk> MQ asks the device if it's pixel ratio is at least 2; device says yes
  2532. # [22:35] <scottjehl> annevk: it'll still fit to a parent container's width at most, given that rule. This is trivial to work with. We have tested picture in this way and it worked as expected
  2533. # [22:36] <annevk> browser thus selects y
  2534. # [22:36] <tantek> ShaneHudson - just figured I'd give you a heads-up and provide citations accordingly ;)
  2535. # [22:36] <annevk> browser starts laying out y
  2536. # [22:36] * Joins: acarback (~Adium@static-71-179-165-244.bltmmd.fios.verizon.net)
  2537. # [22:36] <annevk> its 20x20
  2538. # [22:36] <annevk> there's no information about DPI associated with the image thus the browser uses 1 CSS pixel for each image pixel
  2539. # [22:36] * Parts: acarback (~Adium@static-71-179-165-244.bltmmd.fios.verizon.net)
  2540. # [22:36] <MarcDrummond> annevk: That association goes in the CSS.
  2541. # [22:36] <annevk> and you get something that's four times as big as x
  2542. # [22:36] <jreading> <picture alt="" width="100%">    <source src="x.jpg" />     <source src="y.jpg" media="min-device-pixel-ratio: 2" width="50%" />    <img src="x.jpg" /> </picture>
  2543. # [22:37] <annevk> MarcDrummond: are you saying your example was incomplete?
  2544. # [22:37] <jreading> pave the freakin' cowpaths
  2545. # [22:37] <jmather> annevk: I see where you're coming from, but I don't think it actually works out as a problem in actual practice.
  2546. # [22:37] <annevk> jreading: that's not the same as my example
  2547. # [22:37] <annevk> jmather: it's a problem in all the <picture> examples
  2548. # [22:37] <scottjehl> jmather +1
  2549. # [22:37] <jmather> annevk: in theory, yes, but scottjehl has done quite a bit of testing on this thus far and found it to not be the case
  2550. # [22:37] <jmather> logically, I totally see your point
  2551. # [22:38] * Joins: richw (560acfe2@gateway/web/freenode/ip.86.10.207.226)
  2552. # [22:38] <jmather> but scott says he hasn't seen this particular issue actually occur in the wild
  2553. # [22:38] <jgraham> Isn't that going to break if the pixel ratio is not exactly 2
  2554. # [22:38] <jmather> and he's done quite a bit of leg-work regarding picture
  2555. # [22:38] <annevk> well he's wrong
  2556. # [22:38] <jmather> annevk: umm, not sure how actual results from testing an implementation directly are … wrong.
  2557. # [22:38] <MarcDrummond> annevk: Why do you say he's wrong. Have you tested this? He has.
  2558. # [22:39] * Joins: nathanstaines (~nathansta@cpc36-camd13-2-0-cust393.20-2.cable.virginmedia.com)
  2559. # [22:39] * Joins: jared (324e4d86@gateway/web/freenode/ip.50.78.77.134)
  2560. # [22:39] * jared is now known as Guest62853
  2561. # [22:39] <jgraham> They can be wrong if they only test a subset of all devices (e.g. only phones avaliable today) and don't account for future devices or other formats
  2562. # [22:39] <annevk> I can tell he's wrong because I know how media queries and images work
  2563. # [22:39] * Joins: ajpiano (~ajpiano@li98-57.members.linode.com)
  2564. # [22:40] <TabAtkins> He has seriously attempted to view an image that is authored as, say, 5 inches wide and 192dpi, and seen it lay out as 5 inches on the screen?
  2565. # [22:40] * Joins: darcyclarke (~darcyclar@dsl-66-185-205-103.vianet.ca)
  2566. # [22:40] <scottjehl> no the testing we did was more... deliver a higher density image to a retina iphone
  2567. # [22:40] <TabAtkins> If you're using explicit sizes on the <img>, it'll "work", because the browser is downscaling.
  2568. # [22:41] <MarcDrummond> annevk: Inmost cases, a picture is going to be defined with a width that is a certain percentage of its parent. That definition is going to go in the CSS. The picture will fill that width, rather than just simply expanding out to any old size.
  2569. # [22:41] <TabAtkins> And in a retina environment, the downscaling will work well.
  2570. # [22:41] <jmather> I don't think we have any 3x displays to test on yet annevk
  2571. # [22:41] * Quits: gwicke (~gabriel@212.255.28.33) (Read error: Connection reset by peer)
  2572. # [22:41] <annevk> jmather: not sure how that's an argument
  2573. # [22:41] <MarcDrummond> annevk: Yes, if you don't have a width defined, it's going to go all over the place. But that defeats the entire point of responsive images anyhow.
  2574. # [22:41] * Joins: gwicke (~gabriel@212.255.28.33)
  2575. # [22:41] <annevk> scottjehl: I'd be interested in a pointer to the test
  2576. # [22:42] <jmather> annevk: basically just that there's time to solve it
  2577. # [22:42] <annevk> jmather: it doesn't work now either
  2578. # [22:42] <annevk> jmather: unless you specify width/height all the time which is rather insane
  2579. # [22:42] <scottjehl> Example: a picture element sitting inside a 500px wide column. CSS could be... picture { max-width: 100% }. Regardless of the source in play, the image won't expand beyond its container. An HD media query would make a denser image. This is the sort of testing we did. Is this different than what we're talking about?
  2580. # [22:42] <annevk> if you ask me anyway
  2581. # [22:42] <jmather> so, specify width/height? :)
  2582. # [22:43] <jmather> I dunno.
  2583. # [22:43] <jreading> scottjehl: that's what I'm trying to figure out wtf they are saying...
  2584. # [22:43] <jmather> What does srcset do with a 2x image on a 3x display?
  2585. # [22:43] <TabAtkins> Whatever the UA decides is appropriate.
  2586. # [22:45] <scottjehl> did my example make sense?
  2587. # [22:45] <TabAtkins> Yeah, that example works.
  2588. # [22:45] <annevk> scottjehl: if you have a 500px width and you create a 500 and 1000 wide image then sure it'll work if you define the width somewhere
  2589. # [22:45] <scottjehl> that's what I imagine to be the 95% use case
  2590. # [22:45] <TabAtkins> If you set a size, the "original" size doesn't matter.
  2591. # [22:45] <jmather> TabAtkins: but what is spec'd to happen?
  2592. # [22:45] <annevk> it doesn't seem at all clean to me to not have that semantic embedded
  2593. # [22:45] <TabAtkins> jmather: Literally what I just said.
  2594. # [22:45] <scottjehl> right. this fact can be used to our advantage. How is this a failing of picture?
  2595. # [22:45] <jmather> TabAtkins: that sounds like IE all over again. Not trying to start aright, just saying, that sounds highly … open to … alternative implementations.
  2596. # [22:46] <annevk> scottjehl: it requires a bunch of extra attributes
  2597. # [22:46] <TabAtkins> scottjehl: The only issue is that deciding when to send the "high-dpi version" (that is, the 1000px-wide image) may be best made by data that you don't have easy access to.
  2598. # [22:46] <scottjehl> what attributes?
  2599. # [22:46] <annevk> width/height
  2600. # [22:46] <annevk> if CSS is disabled the image will be way large
  2601. # [22:46] <TabAtkins> Here, I just now wrote a blog post about it so I can stop explaining why it's best to do resolution negotation by just telling the browser about it: http://www.xanthir.com/blog/b4Hv0
  2602. # [22:47] <annevk> *otherwise
  2603. # [22:47] <scottjehl> tabatkins that's a very different subject, no?
  2604. # [22:47] <scottjehl> annevk no width or height attrs are used here
  2605. # [22:47] <TabAtkins> scottjehl: Not really, no.
  2606. # [22:47] * Quits: atadams (80f901c2@gateway/web/freenode/ip.128.249.1.194) (Quit: Page closed)
  2607. # [22:47] <annevk> scottjehl: exactly, but you need to
  2608. # [22:47] <MarcDrummond> annevk: The point of responsive images is to maintain hierarchy of images to content at various container sizes. By default, that means defining the relationship of images to their container. Again, usually as a percentage of the width of the parent. That is done in the CSS for all images (and can be segmented out by classing, etc.). So yes, there will be widths, and this will work.
  2609. # [22:47] <TabAtkins> If you're doing *anything* with high-res images, you want the browser to be the one deciding when to request them.
  2610. # [22:47] <annevk> scottjehl: because otherwise with CSS disabled it'll turn ugly
  2611. # [22:47] <jmather> TabAtkins: your first paragraph after tl;dr is … i believe highly inccorect
  2612. # [22:48] <jmather> that's the central starting point for any responsive image implantation, i think
  2613. # [22:48] <jmather> that or ipad3… either way
  2614. # [22:48] <scottjehl> annevk... disabling css on a retina ipad is the reason picture isn't practical?
  2615. # [22:48] * Joins: tgecho (~tgecho@66-55-201-102.gwi.net)
  2616. # [22:49] <MarcDrummond> What's the percentage of users out there with retina displays that have CSS disabled but images enabled? It has to be pretty darned low.
  2617. # [22:49] <jmather> annevk: can you even disable css on an iPad in safari?
  2618. # [22:50] * jmather has never even thought to try
  2619. # [22:50] <annevk> that was just to illustrate a point
  2620. # [22:50] <annevk> that you want the semantic that the image is twice its actual size in the markup
  2621. # [22:50] <MarcDrummond> What point? What use case are you highlighting where this wouldn't work?
  2622. # [22:50] <annevk> so that if you do anything with that image it's known what is going on
  2623. # [22:50] <scottjehl> partially kidding there, but seriously, this doesn't seem like a real problem we're facing
  2624. # [22:51] * Quits: darcyclarke (~darcyclar@dsl-66-185-205-103.vianet.ca) (Quit: Leaving...)
  2625. # [22:51] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Read error: Connection reset by peer)
  2626. # [22:51] <jmather> annevk: thus why with picture you instruct the element to it's size and then source is used to fill the element
  2627. # [22:51] * Joins: fabuloso_ (~fabuloso@unr0cae.fiu.edu)
  2628. # [22:51] * Joins: Methapod (~anthony@203.b.005.mel.iprimus.net.au)
  2629. # [22:51] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
  2630. # [22:51] * Quits: fabuloso_ (~fabuloso@unr0cae.fiu.edu) (Client Quit)
  2631. # [22:51] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
  2632. # [22:52] * Joins: fabuloso_ (~fabuloso@unr0cae.fiu.edu)
  2633. # [22:52] <jmather> annevk: which is why the styling/sizing applies to picture and then whatever source is selected is used to fill it
  2634. # [22:52] <TabAtkins> jmather: Interesting. private message me to discuss?
  2635. # [22:52] <annevk> jmather: that doesn't work if you want to vary both width and pixel density
  2636. # [22:53] <jmather> TabAtkins: sure, but I'm not sure it really merits it… I just think it would be difficult to talk about responsive images without having a retina display on the forefront of the conversation
  2637. # [22:53] <annevk> scottjehl: e.g. you hit that problem as soon as you draw the image on a <canvas>
  2638. # [22:53] <scottjehl> I could easily update the picture demo to include a high-density source
  2639. # [22:53] <annevk> scottjehl: because instead of only taking up 500px it would take up 1000px
  2640. # [22:53] <jmather> the iPad/iphone retina displays are what threw so much fuel on the fire of getting something working
  2641. # [22:53] <TabAtkins> jmather: I meant relative to your assertion that my tl;dr paragraph is wrong.
  2642. # [22:54] * Quits: cafesofie (~user@ool-18e4c9a0.dyn.optonline.net) (Ping timeout: 240 seconds)
  2643. # [22:54] <annevk> scottjehl: whereas with srcset we know the image is only 500px because of the 2x indicator
  2644. # [22:54] <scottjehl> that also seems fairly avoidable to me
  2645. # [22:54] <jmather> TabAtkins: not your tl;dr, first para after.
  2646. # [22:54] * Joins: sicking (~chatzilla@nat/mozilla/x-oixmvwucyeqaizct)
  2647. # [22:54] <TabAtkins> jmather: Oh, that's even more interesting if you think it's wrong.
  2648. # [22:54] <annevk> jmather: yeah and only Apple managed to make a proposal that works
  2649. # [22:54] <annevk> thus far anyway
  2650. # [22:55] * Joins: teleject (~christoph@208.66.176.1)
  2651. # [22:55] <scottjehl> that's unfair, I think
  2652. # [22:55] <krijnh> Quiet day on the internets today, what's happening?
  2653. # [22:55] <jmather> TabAtkins: the ascertation that the CG didn't take iPhone display into account is the only thing I have issue with, though perhaps you just got a different take on it than I did.
  2654. # [22:55] * Quits: teleject (~christoph@208.66.176.1) (Client Quit)
  2655. # [22:55] <jmather> annevk: the only time that comes in to play is when no dimensions of any kind are set on picture
  2656. # [22:56] <TabAtkins> jmather: Oh, okay. Well, the proposals that the CG put forward weren't taking resolution into account, afaict.
  2657. # [22:56] <jgraham> krijnh: Heh. Going for gold in your own logs?
  2658. # [22:56] <annevk> jmather: actually no, that would always occur
  2659. # [22:56] <jmather> i don't know how to get any sort of statistics on that, but i would have to bet it's fairly low
  2660. # [22:56] <jreading> my recommendation is toss bandwidth MQs, tokenize MQ and use that in the picture element, add bandwidth to headers. It's not like images are the only bandwidth concern
  2661. # [22:56] <annevk> jmather: unless there's a semantic that tells the pixel density
  2662. # [22:56] <TabAtkins> jreading: Note my blog post linked above - bandwidth is *not* the only consideration you want to make, and it's not static.
  2663. # [22:57] <jmather> annevk: it doesn't need pixel density info
  2664. # [22:58] <jmather> it needs to know how many css pixels the image has to fill
  2665. # [22:58] <scottjehl> what works seems highly subjective here.
  2666. # [22:58] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  2667. # [22:58] <scottjehl> sorry, gotta drop off again. thanks
  2668. # [22:58] <jreading> Tab: seems like bandwidth MQ is the only sticking point for why MQs fail with respimgs, no?
  2669. # [22:58] <jmather> TabAtkins: depends on what context you mean
  2670. # [22:58] * Joins: weinig (~weinig@2620:149:4:1b01:111f:22c2:794b:7ee2)
  2671. # [22:59] <jmather> resolution of the linked image, no. And that's an interesting piece of meta data that could lead to some fun stuff I think
  2672. # [22:59] <jmather> but i don't think it's really required
  2673. # [22:59] <ShaneHudson> Would there ever be any need for different file formats to be shown? Thinking if one is better for lower quality while one is better for higher?
  2674. # [22:59] <MarcDrummond> annevk: It really seems you are beating an imaginary issue into the ground.
  2675. # [23:00] <jmather> at least from a content guy's perspective… I have a box, 100x100 in css pixels
  2676. # [23:00] <jmather> I want it filled with an image
  2677. # [23:00] <jmather> if it's a high resolution screen, i want them to use this other image, because it has 2x the info, and will look sharper
  2678. # [23:00] * Joins: rharr_ (~rharr@rrcs-98-100-9-178.central.biz.rr.com)
  2679. # [23:01] <jmather> ShaneHudson: that's something that really interested me about picture as well
  2680. # [23:01] <jmather> not so much in that i think we need it
  2681. # [23:01] * Quits: greenplastic (~anonymous@71-87-1-124.static.eucl.wi.charter.com) (Quit: greenplastic)
  2682. # [23:01] <jmather> but that it would give room for new file formats to grow
  2683. # [23:01] <jmather> like, say, a stereographic image format, perhaps?
  2684. # [23:01] <jmather> it's neither here nor there, but I liked that picture opened up the opportunity for someone else to be able to explore that.
  2685. # [23:02] * Quits: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be) (Ping timeout: 244 seconds)
  2686. # [23:02] <annevk> MarcDrummond: hey man, I'm just telling you what's wrong with <picture>
  2687. # [23:02] <annevk> MarcDrummond: at the end of the day, I don't really care what happens here
  2688. # [23:02] <MarcDrummond> annevk: To me, the use case of "Author adds retina display image but can't be bothered to define a width" is not a persuasive use case.
  2689. # [23:02] <annevk> feel free to ignore me
  2690. # [23:02] * Joins: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net)
  2691. # [23:03] * ojan_away is now known as ojan
  2692. # [23:03] <annevk> MarcDrummond: even if they add width, it would still blow up on <canvas>
  2693. # [23:03] <MarcDrummond> annevk: I do care. As do a lot of other developers/authors. Feel free to pay attention to our concerns!
  2694. # [23:03] <annevk> MarcDrummond: as I mentioned before
  2695. # [23:03] <jmather> annevk: you're saying one issue that applies in only the most minimal of instances and can be worked around rather trivially, at least as far as I have been able to ascertain. I'm not trying to minimize your argument, I'm just trying to phrase it how it's coming across.
  2696. # [23:03] <TabAtkins> MarcDrummond: More important is the use-case "author adds retina display image, but doesn't want to send it to normal-dpi screens, and doesn't want to send it to retina screens on low bandwidth, and..."
  2697. # [23:03] * Quits: rharr (~rharr@rrcs-98-100-9-178.central.biz.rr.com) (Ping timeout: 260 seconds)
  2698. # [23:04] <jmather> TabAtkins: picture covers for that well
  2699. # [23:04] <annevk> jmather: you're coming accross as someone who doesn't want to hear about problems with <picture>
  2700. # [23:04] * Quits: Guest62853 (324e4d86@gateway/web/freenode/ip.50.78.77.134) (Quit: Page closed)
  2701. # [23:04] <TabAtkins> jmather: Based on the last thing I've seen of <picture>, it doesn't, unless you hack in @srcset functionality.
  2702. # [23:05] <jmather> annevk: I figured as much. I'm trying not to, but it's hard. I understand the point your'e trying to make, but i don't think it's as big of an issue as you seem to think it is, is all.
  2703. # [23:05] <annevk> that ease of authoring is not a serious concern; or drawing images with a higher pixel density on <canvas> is not a concern
  2704. # [23:05] <TabAtkins> In which case the difference between "<picture> with <source srcset>" and "<img srcset>" is verbosity and slight differences in how you do fallbacks.
  2705. # [23:05] * Quits: rharr_ (~rharr@rrcs-98-100-9-178.central.biz.rr.com) (Ping timeout: 272 seconds)
  2706. # [23:05] <MarcDrummond> TabAtkins: So, image displays ONLY for retina displays with sufficient bandwidth, otherwise no image at all? That also seems unlikely.
  2707. # [23:05] * Joins: SimpleQuark (~SimpleQua@64.124.62.236)
  2708. # [23:05] <jmather> TabAtkins: <picture><sourcr src="image@2.jpg" media="min-device-pixel-ratio: 2"><source src="image.jpg"></picture> I think
  2709. # [23:06] <jmather> well, aside from bandwidth, granted
  2710. # [23:06] <jmather> but if a bandwidth mq were added, easy enough
  2711. # [23:06] <annevk> a bandwidth MQ? haha
  2712. # [23:06] * Quits: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net) (Quit: dgathright)
  2713. # [23:07] <gsnedders> Have we not been over why MQ don't work for bandwidth often enough yet?
  2714. # [23:07] <jmather> annevk: I wasn't trying to make a joke… :D I'm not sure why that's so funny though. If the browser can be trusted to figure it out, why couldn't it expose it to an mq?
  2715. # [23:07] <MarcDrummond> The reality is that MQs offer a lot more possibilities for addressing issues like bandwidth than the goofy syntax in srcset that doesn't resemble anything else in HTML.
  2716. # [23:07] * Joins: cpearce (~cpearce@60.234.54.74)
  2717. # [23:07] <annevk> jmather: expose it how?
  2718. # [23:07] <TabAtkins> jmather: Once again, read my blogpost <http://www.xanthir.com/blog/b4Hv0>. To do that *well*, you need *at least* a bandwidth MQ, and bandwidth MQs have very bad behavior.
  2719. # [23:07] <annevk> jmather: did you read Hixie's email explaining the problems with bandwidth and how they're shifting from size to latency etc.?
  2720. # [23:08] <annevk> jmather: btw, your media queries thus far miss the required parenthesis and would therefore fail
  2721. # [23:08] <gsnedders> FWIW, I don't like the srcset syntax at first glance, but that's a syntatual issue
  2722. # [23:08] <jmather> I haven't seen Hixie's email, no. But TabAtkins seems to propose letting the browser make those bandwidth aware decisions, and so if the browser can make a decision, it could be exposed in mq in some form as well
  2723. # [23:08] <annevk> jmather: ease of authoring is important ;)
  2724. # [23:08] * Parts: akselkreis (~Adium@rrcs-50-75-52-51.nys.biz.rr.com)
  2725. # [23:09] <kevinSuttle> Think about hotel wifi on a laptop vs an iPhone on wifi at home. What should a bandwidth API tell us in that case?
  2726. # [23:09] <davatron5000> jmather: +1
  2727. # [23:09] <jmather> annevk: I'm just trying to get the general point across is all and hopefully get an idea of where you guys are coming from with srcset
  2728. # [23:09] * Quits: rdebeasi (ada04aae@gateway/web/freenode/ip.173.160.74.174) (Quit: Page closed)
  2729. # [23:09] <annevk> I didn't come up with srcset
  2730. # [23:09] * Joins: danielfilho (~daniel@187.31.77.7)
  2731. # [23:09] <annevk> I don't really care for it either
  2732. # [23:09] <jmather> kevinSuttle: I have no idea
  2733. # [23:09] <annevk> but given the alternative...
  2734. # [23:09] <TabAtkins> jmather: It can't be cleanly exposed in an MQ manner. The way it's going to be handled is with image-set(), which is basically the same as @srcset.
  2735. # [23:10] <gsnedders> It's not us-v-them like many are putting forward. Plenty of us have issues with srcset… and bigger issues with the picture proposal.
  2736. # [23:10] <jmather> but TabAtkins wanted the browser to account for bandwidth in it's downloading provision
  2737. # [23:10] <kevinSuttle> @Jmather: Exactly. Which was part of my point here: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-780 We're solving the wrong problem.
  2738. # [23:10] <jmather> I'm not trying to make it us-vs-them, just trying to understand srcset as i still don't like it, and was hoping more information could help that.
  2739. # [23:11] * Quits: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net) (Read error: Operation timed out)
  2740. # [23:11] <zewt> shouldn't you understand it before deciding you don't like it :)
  2741. # [23:11] <jmather> zewt: gut instincts are there for a reason :)
  2742. # [23:11] <jmather> not to say they can't be wrong
  2743. # [23:12] <jreading> so i think the srcset folks agree with me that bandwidth MQ is a bad idea
  2744. # [23:12] <jreading> also, seems that's the ONLY sticking point
  2745. # [23:12] <jreading> so lose it
  2746. # [23:12] <gsnedders> jmather: Someone saying an issue with picture (or bandwidth MQs, etc.) doesn't mean they like srcset is my point
  2747. # [23:12] <jmather> gsnedders: true enough
  2748. # [23:13] * Quits: joshlockhart (~joshlockh@twdp-174-109-189-157.nc.res.rr.com) (Quit: joshlockhart)
  2749. # [23:13] <zewt> (you can do bandwidth without trying to actually strictly define it, eg. as i suggested with the file-size hint)
  2750. # [23:13] <kevinSuttle> No one seems to be able to answer why we're only focused on images. Is it because we have indirect control by not having to deal with audio/video codecs?
  2751. # [23:13] <annevk> zewt: but not in MQs
  2752. # [23:13] <annevk> MQs are about device capabilities
  2753. # [23:13] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
  2754. # [23:13] <TabAtkins> jmather: Once you accept that bandwidth MQs are bad, and so you accomodate resolution negotiation some other way, it boils down to a preference for more verbose but possibly more readable (<picture>) versus more compact and typeable (<img srcset>).
  2755. # [23:13] <jmather> kevinSuttle: I think it's mainly because video/audio is considered "done" with the tags
  2756. # [23:13] <annevk> whereas we are concerned here with capabilities from the image
  2757. # [23:13] <zewt> annevk: i'm talking about srcset, don't know much of anything about MQ
  2758. # [23:13] <annevk> such as its size and aspect ratio
  2759. # [23:14] <gsnedders> jmather: Nah, they aren't done. They can always have more done to them, as can img.
  2760. # [23:14] <jmather> TabAtkins: at which point with html , verbose and readable usually wins
  2761. # [23:14] <zewt> and file size, which is a relative representation of content quality (relative to the other options, at least)
  2762. # [23:14] <jreading> and if the concern is the flipping on/off of bandwidth MQ, make them behave differently or lose it
  2763. # [23:14] <TabAtkins> jmather: That's an arguably point. ^_^
  2764. # [23:14] <jmather> Unfortunately I have to take off now :)
  2765. # [23:14] <annevk> using device queries (=MQs) for resource selection is the wrong solution (for <video> too imo)
  2766. # [23:14] <kevinSuttle> @Jmather: I don't think the media elements are done until they're consistent. Why is it OK to serve one file size of video/audio to any browser, but not images?
  2767. # [23:14] <jmather> TabAtkins: it does seem to go back and forth, but I do like matt's argument that picture is less error brone
  2768. # [23:15] <jmather> kevinSuttle: because html video sucks. :D
  2769. # [23:15] <MarcDrummond> The thing that really gets me is that all of the objections with picture seem to revolve around, you didn't document your use cases! You didn't post things in the right places! But srcset comes along, without well-documented use cases, and bam, it's in, because Hixie likes it. And since this is a dictatorship, it feels like we're a mob storming a gate, rather than being able to debate things with some hope of coming to a reasona
  2770. # [23:15] <annevk> jmather: I haven't seen much people make mistakes with srcset yet, plenty with <picture> though...
  2771. # [23:15] <jmather> Not a good answer, but it is my own, hah. I end up using youtube/vimeo for everything video… just avoid that issue altogether.
  2772. # [23:15] <jreading> so bandwidth MQ is out and <picture> is back in, right?
  2773. # [23:16] <zewt> (nothing screams troll like calling someone a "dictator"; do you even know how standards work?)
  2774. # [23:16] <jmather> alright, c-ya guys. Gotta run.
  2775. # [23:16] <kevinSuttle> @jmather haha. no one is arguing that. My point is that those media elements are handled by a server that determines quality. Why can't we do the same with images?
  2776. # [23:16] <annevk> me too
  2777. # [23:16] <TabAtkins> MarcDrummond: I don't think anyone credible has actually made those objections. Use-cases were well-documented, and no one gives a fuck where it was posted.
  2778. # [23:16] <TabAtkins> MarcDrummond: HTML is a benevolent dictatorship, but that seems to be a successful model for tech.
  2779. # [23:17] <gsnedders> It doesn't matter whether the use-cases are documented in one place or fourty. It'd be nice for the former, but…
  2780. # [23:17] * Quits: fabuloso_ (~fabuloso@unr0cae.fiu.edu) (Quit: fabuloso_)
  2781. # [23:17] <MarcDrummond> zewt: Thank you for your condescension.
  2782. # [23:17] <jmather> kevinSuttle: I think it's an accessibility thing… it's harder to expect someone to install/maintain a server for basics like images than it is for video, probably because of the amount of usage of images as opposed to video -- but -- gosh, i really have to run. HAH…
  2783. # [23:17] <zewt> TabAtkins: it's not, since implementors effectively have (as a unit, not individually) veto power
  2784. # [23:17] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  2785. # [23:17] * Joins: raphc (~rc@ppp-sei21-46-193-160.67.wb.wifirst.net)
  2786. # [23:17] <TabAtkins> zewt: Yeah, sure. But most of the time, on most issues, we let Hixie do his thing on the assumption that he makes good choices.
  2787. # [23:17] * Joins: duecaja (~jamesduec@cpe-24-93-190-62.neo.res.rr.com)
  2788. # [23:18] <gsnedders> zewt: Well, as a unit of two or more
  2789. # [23:18] <gsnedders> Not necessarily as a unit of all of them.
  2790. # [23:18] <zewt> gsnedders: sure--just didn't want to claim that they *individually* have veto power (it just gets muddier when just one vendor balks)
  2791. # [23:19] <gsnedders> zewt: Yeah, I was just trying to clarify more than correct *you*. I think you know well enough how things work.
  2792. # [23:19] * Quits: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42) (Quit: Page closed)
  2793. # [23:19] * Quits: jmather (~jmather@mail.bojigroup.com) (Quit: jmather)
  2794. # [23:19] <bjankord> What happens when Hixie makes bad choices?
  2795. # [23:19] * Joins: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42)
  2796. # [23:20] <zewt> everyone tells him :)
  2797. # [23:20] <bjankord> Does he listen?
  2798. # [23:20] <bjankord> Does he care?
  2799. # [23:20] <TabAtkins> If he doesn't, browsers do what they want anyway.
  2800. # [23:20] <TabAtkins> And that means the spec doesn't match brwosers, which lowers the reputation of the spec and it's power in general.
  2801. # [23:20] <TabAtkins> So yes, it's ultimately the slave of the browsers.
  2802. # [23:20] * Hixie pops his head in and then ducks the incoming tomatoes
  2803. # [23:21] <tantek> but at least they're high-resolution tomatoes.
  2804. # [23:21] <bjankord> +1
  2805. # [23:21] <Hixie> 'sup people
  2806. # [23:21] <Hixie> please direct your ire at me :-)
  2807. # [23:21] <adactio> Oh hai.
  2808. # [23:21] <Hixie> happy to answer any questions
  2809. # [23:22] * zewt BEAM
  2810. # [23:22] <davatron5000> Hixie: You have lots of explaining' to do [/rickyricardo]
  2811. # [23:22] <bjankord> Hixie: Is there any chance the picture element would be reconsidered
  2812. # [23:22] * Quits: dcheng (~dcheng@74.125.59.65) (Quit: leaving)
  2813. # [23:22] <kevinSuttle> OK guys, gotta run. @Hixie: I'd love your feedback on this comment: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-780 Will check in in a bit.
  2814. # [23:22] <bjankord> I've heard if it is revised there is a chance that it will be reconsidered
  2815. # [23:23] * Quits: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
  2816. # [23:23] <Hixie> bjankord: if there is new information, absolutely
  2817. # [23:23] <Hixie> bjankord: however generally speaking it's better to talk about use cases, not solutions
  2818. # [23:23] <Hixie> bjankord: and to point out what is wrong with the existing solutions
  2819. # [23:24] <Hixie> bjankord: so e.g. "srcset="" doesn't address use case X" or "srcset="" is overly complicated for use case X"
  2820. # [23:24] <necolas> Hixie: by "existing solutions" do you mean @srcset?
  2821. # [23:24] <adactio> Apparently, according to zewt, referring to Hixie as a dictator automatically means you're a troll. By which definition, TabAtkins is a troll for describing the WHATWG as a benevolent dictatorship. "My mixed messages: let me show you them."
  2822. # [23:24] <Hixie> necolas: now, yes
  2823. # [23:24] <zewt> zzz
  2824. # [23:24] <TabAtkins> adactio: Welcome to a multitude of opinions.
  2825. # [23:24] <jgraham> In other news TabAtkins and zewt are the same person
  2826. # [23:24] <zewt> :|
  2827. # [23:25] <Hixie> adactio: referring to me as a dictator doesn't automatically mean you're a troll, but it does mean you're talking about process and not the technical stuff, which usually isn't helpful
  2828. # [23:25] <TabAtkins> adactio: That's why references to the "cabal" are so misleading. ^_^
  2829. # [23:25] <annevk> there's disagreement in the cabal?
  2830. # [23:25] <annevk> quick krijn, disable public logging!
  2831. # [23:25] <jgraham> annevk: Not in #secret-treehouse
  2832. # [23:25] <Hixie> bjankord: (the point being that agreement that there is a problem to solve is more important than getting agreement on the solution)
  2833. # [23:25] <adactio> zewt: Seriously, almost every contribution you've made here has been unconstructive and unhelpful, particularly people new to the process just trying to figure out how things are supposed to work.
  2834. # [23:25] <jgraham> Just for show
  2835. # [23:25] <annevk> jgraham: ssssh
  2836. # [23:26] <bjankord> Hixie: Would examples of use cases of picture element be helpful, or you specifically looking for use cases of srcset?
  2837. # [23:26] <tantek> adactio, I thought the accepted term was BDFL per http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life
  2838. # [23:26] * Joins: dcheng (~dcheng@74.125.59.65)
  2839. # [23:26] <zewt> (I don't feel like dignifying that with a reply, beyond this one)
  2840. # [23:26] * Quits: KDN (~kdn@90.149.135.254) (Quit: KDN)
  2841. # [23:26] <Hixie> bjankord: use cases don't mention solutions
  2842. # [23:26] <necolas> Hixie: we can consider it progress that it is now agreed that there is a problem to solve
  2843. # [23:26] <Hixie> bjankord: srcset and <picture> are solutions
  2844. # [23:26] <MarcDrummond> Hixie: One of my concerns with srcset is how radically different its syntax is from anything else in HTML. Whereas picture fits the markup pattern established from audio and video. Using similar markup, even if it is slightly more verbose, would help to make this important new feature easier for many to understand and for it to be adopted.
  2845. # [23:26] <zewt> bjankord: you're approaching this as "what arguments can I make to convince you to use picture", instead of "what problems do I want to solve that srcset does not"
  2846. # [23:27] <Hixie> MarcDrummond: one of the lessons we learnt from <video> is that hte <source> pattern is a bad one, unfortunately
  2847. # [23:27] * Joins: jarek (~jarek@aeap36.neoplus.adsl.tpnet.pl)
  2848. # [23:27] * Quits: jarek (~jarek@aeap36.neoplus.adsl.tpnet.pl) (Changing host)
  2849. # [23:27] * Joins: jarek (~jarek@unaffiliated/jarek)
  2850. # [23:27] * Joins: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
  2851. # [23:27] * Parts: tgecho (~tgecho@66-55-201-102.gwi.net)
  2852. # [23:27] * Joins: tgecho (~tgecho@66-55-201-102.gwi.net)
  2853. # [23:28] <davatron5000> The problem with the <source> pattern is multiple codecs across various browsers. not @media, imo.
  2854. # [23:28] * Quits: mswartz (~textual@64.119.159.250) (Quit: Computer has gone to sleep.)
  2855. # [23:28] <MarcDrummond> Hixie: Just curious, in what ways is that markup pattern considered bad? I hadn't heard that.
  2856. # [23:28] <Hixie> MarcDrummond: it leads to all kinds of problem e.g. with the parser needing to notify the rendering logic so that all the sources can be considered; the problem with orphan sources being grafted in random places; the problem with dealing with inter-element content; the problems with verbosity; etc.
  2857. # [23:28] <bjankord> I feel like both can be used to solve the same problem, one is just more verbose then the other. But there is a solution that makes <picture> less verbose then srcset - https://gist.github.com/2702067
  2858. # [23:28] <zewt> if the use cases lead to picture, that's fine, but it's not great when the goal is to use a particular solution and to go looking for arguments for it
  2859. # [23:28] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  2860. # [23:28] <Hixie> MarcDrummond: also we really haven't had much luck with media="" on <Source> so far for <video>
  2861. # [23:28] <ShaneHudson> Hixie: Hey Hixie, did you read that we are going to be focusing on defining use-cases to focus on since everybody has their own opinions? I am writing a base for it at the moment at http://www.w3.org/wiki/index.php?title=Images currently trying to compile all the different use-cases from everywhere
  2862. # [23:28] <Hixie> bjankord: you're still talking about solutions not problems :-)
  2863. # [23:28] <zewt> *blink*
  2864. # [23:29] <MarcDrummond> Hixie: Thanks. Helpful to understand those problems.
  2865. # [23:29] <Hixie> ShaneHudson: i think i listed the use cases that led to srcset="" in my big e-mail, are there others?
  2866. # [23:29] <necolas> Hixie: so what is the lesson learned from the <source> problems? that sounds like part of the problem was adding something to the draft without working out the problems it might result in
  2867. # [23:29] <Hixie> necolas: numerous lessons, e.g. the ones i just mentioned.
  2868. # [23:30] <necolas> sure, but those are lessons about the actual details
  2869. # [23:30] * Quits: eric_carlson (ericc@nat/google/x-pyurtiwfinnqjfms) (Quit: eric_carlson)
  2870. # [23:30] <bjankord> Hixie: Thanks for the feedback, good to know what direction to go from here.
  2871. # [23:30] <tantek> is there a wiki.whatwg.org equivalent to http://microformats.org/wiki/irc-people where people note their IRC nickname, perhaps link to their website etc.? it would be useful to know who is a browser implementer for example.
  2872. # [23:30] <TabAtkins> Do you mean "the lesson is: don't use <source> children"?
  2873. # [23:30] <jgraham> necolas: The problem is that oftentimes we don't realise what the problems are until after people have worked hard at making interoperable implementations
  2874. # [23:30] <ShaneHudson> Hixie: Well we realised that all the solutions have been focusing on different use-cases
  2875. # [23:30] * Quits: nicksergeant (~Nick@74.112.37.250) (Ping timeout: 250 seconds)
  2876. # [23:30] <ShaneHudson> tantek: good idea
  2877. # [23:31] <annevk> TabAtkins: it's not equivalent to max-width
  2878. # [23:31] <annevk> TabAtkins: because it would be used for a viewport of 700px
  2879. # [23:31] <annevk> (re mailing list)
  2880. # [23:31] <TabAtkins> annevk: Oh. So it's equivalent to min-width?
  2881. # [23:31] <Hixie> TabAtkins: well it's not that simple, i'm not sure how we'd have done otherwise for <video>. but certainly "don't assume it's a good pattern".
  2882. # [23:31] * TabAtkins thinks the microsyntax for MQ is a bad idea.
  2883. # [23:31] <Hixie> ShaneHudson: in the threads i replied to i'm not sure that was the case, but it's certainly possible.
  2884. # [23:31] * Quits: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
  2885. # [23:31] <annevk> TabAtkins: it's not a MQ microsyntax though
  2886. # [23:32] <Hixie> microsyntax for MQ?
  2887. # [23:32] <annevk> TabAtkins: e.g. 2x is not something MQ can do
  2888. # [23:32] <Hixie> srcset="" isn't mq
  2889. # [23:32] <TabAtkins> Hixie: The "100w 100h" part.
  2890. # [23:32] <TabAtkins> annevk: Yes, I'm only talking about the w/h part.
  2891. # [23:32] <Hixie> that's just describing the environment for the image, it's not a mq-equivalent
  2892. # [23:32] <jgraham> that is a really limited subset of mq
  2893. # [23:32] <Hixie> it doesn't evaluate to true or false
  2894. # [23:32] <necolas> the fact that we're stuck with <source> suggests that it might have been prematurely added to the draft. stuff like parser & rendering logic, orphan sources, verbosity seem like they wouldn't have needed implementation to be considered potential problems
  2895. # [23:33] <Hixie> necolas: everything is "prematurely" added to the standard. we can't learn the lessons until things are implemented, at which point it's too late.
  2896. # [23:33] <jgraham> necolas: Video had *lots* of discussion and changes to the design
  2897. # [23:33] <TabAtkins> Hixie: I think you're misunderstanding me. That, or you've complicated the w/h thing in a way that's non-obvious beyond what MQ can do.
  2898. # [23:33] <necolas> im just interested if that is considered one of the lessons learnt, rather than trying to make judgements
  2899. # [23:33] <adactio> Hixie: I'm genuinely confused. You keep saying "provide use cases, not preferred solutions" (which is excellent advice IMHO) but you've gone and put a preferred solution into the HTML: The Living Standard document. Again: mixed messages.
  2900. # [23:33] <Hixie> TabAtkins: i don't understand the relevance of mq here
  2901. # [23:33] <zewt> jgraham: it's describing the image, and leaving what to do with it to the implementation (I believe), which is a different approach
  2902. # [23:33] <annevk> adactio: based on the use cases to date
  2903. # [23:33] * Joins: zachleat_ (~zachleat@ext-B14-1658.omhq.uprr.com)
  2904. # [23:34] <jgraham> zewt: Well it's not actually describing the image
  2905. # [23:34] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Remote host closed the connection)
  2906. # [23:34] <zewt> jgraham: describing attributes about the image
  2907. # [23:34] <Hixie> necolas: the lessons learnt are those i listed above, about how the multi-element pattern for url selection has technical implications that are good to avoid if possible
  2908. # [23:34] <necolas> jgraham: in those discussions, were concerns about verbosity, orphan <source>, rendering logic discussed? or did it not occur at the time?
  2909. # [23:34] * Quits: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com) (Read error: Connection reset by peer)
  2910. # [23:34] * zachleat_ is now known as zachleat
  2911. # [23:34] <TabAtkins> Hixie: Adding "500w" to a src acts like either min-width or max-width (I'm not sure off the top of my head), throwing away that source if it doesn't pass the test.
  2912. # [23:34] <jgraham> It's describing some things about the browser environment that will be used to pick the right image
  2913. # [23:34] <TabAtkins> Hixie: Correct?
  2914. # [23:34] * Joins: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
  2915. # [23:34] * Joins: hartless (6c496899@gateway/web/freenode/ip.108.73.104.153)
  2916. # [23:34] <Hixie> necolas: the problem with <video> is we don't really have a good alternative for handling it other than <source> (and <track>)
  2917. # [23:35] <Hixie> necolas: so it's not that we made a bad decision
  2918. # [23:35] <Hixie> necolas: it did teach us that the decision is not as obviously good as one would have thought
  2919. # [23:35] <Hixie> TabAtkins: not really
  2920. # [23:35] <Hixie> TabAtkins: the browser can pick whichever image it wants
  2921. # [23:35] <Hixie> TabAtkins: there's a recommended algorithm that picks the image based on some priorities
  2922. # [23:35] <necolas> Hixie: i'm not suggesting that. i'm simply curious if the experience also had an impact on the criteria you consider before adding new things (in general) to the draft now
  2923. # [23:36] <Hixie> TabAtkins: but even that algorithm doesn't knock things out necessarily
  2924. # [23:36] <jgraham> Hixie: BTW "return a random image" in the spec is wrong
  2925. # [23:36] <necolas> you live and learn
  2926. # [23:36] <Hixie> TabAtkins: e.g. if you only have one image and it has 100w, it doesn't matter if the width is 50 or 200, it'll be used
  2927. # [23:36] <jgraham> "return an image according to an algorithm of the UA's choosing" would be right
  2928. # [23:36] * Quits: duecaja (~jamesduec@cpe-24-93-190-62.neo.res.rr.com) (Quit: duecaja)
  2929. # [23:36] <Hixie> necolas: yes, all the lessons we learn with everything we do impact how we make future decisions
  2930. # [23:37] <hober> jgraham: agreed
  2931. # [23:37] <Hixie> jgraham: did i really say "random" in the spec text?
  2932. # [23:37] * Quits: GAmini (407dba52@gateway/web/freenode/ip.64.125.186.82) (Quit: Page closed)
  2933. # [23:37] <jgraham> "Optionally, return the URL of a random entry in candidates, and that entry's associated pixel density, and then abort these steps."
  2934. # [23:37] <necolas> Hixie: so do you have any concerns that something like @srcset might start to get implemented, and be problematic, before further discussion and exploring of the problem-space can occur?
  2935. # [23:37] <Hixie> jgraham: oh man. let me fix that.
  2936. # [23:38] <TabAtkins> Hixie: Yeah, the "if nothing matches, choose X" is fine. But aside from that, it acts like a strict filter, right?
  2937. # [23:38] <jgraham> Heh
  2938. # [23:38] <Hixie> necolas: of course. that happens with everything we do.
  2939. # [23:38] <jgraham> TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates
  2940. # [23:38] <Hixie> necolas: at the end of the day though it's better to have something mediocre than nothing at all.
  2941. # [23:39] <ShaneHudson> Right I have got to the point where I will be writing gobblygoop. Have updated http://www.w3.org/wiki/Images but it is certainly not up to Hixie's standard! tantek and anyone else please feel free to add/edit/destroy as you wish. I will carry on with it tomorrow if I am wanted to
  2942. # [23:39] <Hixie> TabAtkins: well, modulo the way the UA can do whatever it wants, sure
  2943. # [23:39] <necolas> Hixie: in which case, what was compelling enough to add it to the draft before further discussion could take place?
  2944. # [23:39] <zewt> TabAtkins: step 16 means "the browser can come up with its own decision/heuristics", from what I understand
  2945. # [23:39] <zewt> (the "random" line they're talking about)
  2946. # [23:39] <MarcDrummond> Hixie: I think a big concern with srcset is that it locks down the vectors for what is considered to simply width and height and device resolution. Media queries seem to offer more flexibility for the future for other ways to vary image source beyond just width, height and device resolution.
  2947. # [23:40] <zewt> TabAtkins: eg. you can make more complex decisions (like "we're a small device, but the viewport is zoomable and we have lots of bandwidth, so let's download the high-res one anyway")
  2948. # [23:40] <Hixie> necolas: there was a clear (imho) statement of a problem that needed resolving, there had already been a broad investigation of the solution space, and the discussion was no longer progressing. That's usually the point at which I try to go through all the e-mails and distill the discussion into a decision, which we then see if the browser vendors are ok with implementing.
  2949. # [23:41] <jgraham> MarcDrummond: FWIW I consider that an advantage unless there are other axes along which we have a clear need to vary stuff
  2950. # [23:41] <Hixie> MarcDrummond: the format is intentionally extensible
  2951. # [23:41] * Quits: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com) (Quit: tkadlec)
  2952. # [23:41] <Hixie> MarcDrummond: but in general unless there's something specific you have in mind, it's good to not be open-ended.
  2953. # [23:41] <jgraham> Using a syntax that suggests lots of things *ought* to work but finding out that they don't, or that they have bad perf. characteristics is not good
  2954. # [23:41] <annevk> wow http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html is an instant classic
  2955. # [23:41] <zewt> TabAtkins: (oh. it says as much in the note right below it. :)
  2956. # [23:42] <Hixie> jgraham: fixed
  2957. # [23:42] <annevk> so this whole "create a CG" thing traces back to someone who to my knowledge doesn't contribute a whole lot and a suggestion that person got from dom
  2958. # [23:42] <MarcDrummond> Hixie: For example, media queries offer the ability to provide a different version specifically for print. The srcset syntax does not seem as capable of handling such a use case.
  2959. # [23:43] <jgraham> Hixie: Thanks
  2960. # [23:44] <TabAtkins> Okay, so yes, the "XXXw" syntax is equivalent to a "min-width" MQ, and the same for h and min-height, except that it has an escape clause for when nothing matches.
  2961. # [23:44] <zewt> annevk: i'm surprised nobody (if nobody actually did) responded to that "not the place" mail with a correction, since it seems pretty much opposite to the attitude of the list
  2962. # [23:44] <Hixie> TabAtkins: certainly they're in a similar space, sure
  2963. # [23:44] * Joins: duecaja (~duecaja@cpe-24-93-190-62.neo.res.rr.com)
  2964. # [23:44] <annevk> zewt: yeah
  2965. # [23:45] <Hixie> MarcDrummond: i do not believe that use case came up in the whatwg discussions, though i may have missed it. but as it happens, srcset="" does handle that case, i even gave an (indirect) example of it in the spec.
  2966. # [23:45] <TabAtkins> zewt: I think I just ignored the email. The responsive images stuff generated a bunch of noise, so I only skimmed things.
  2967. # [23:45] <annevk> zewt: doesn't seem like anyone got through in time :(
  2968. # [23:45] <Hixie> MarcDrummond: (assuming the only thing you need for print images is an even higher res)
  2969. # [23:45] <zewt> (it's also pretty odd for someone apparently new to a list to come on and tell people what they can talk about)
  2970. # [23:45] <necolas> Hixie: given that the problem has been discussed and explored for quite some time, i think it could have been wise to invite a few more days/weeks of discussion. it would have allowed a bit more time for the developers with interests to be included in the discussion of the more recent proposals.
  2971. # [23:46] <zewt> i wasn't following those threads; too much traffic vs. not enough personal interest in the subject
  2972. # [23:46] <annevk> zewt: yep, guess I'll be doing more careful reading of threads I'm not too interested in going forward
  2973. # [23:46] <tantek> ShaneHudson, ok, since you said good idea, here's a stub. I added a few folks that I recognized from here in the channel recently and in the Recent Changes on the wiki - please feel free to add yourself(ves) and others: http://wiki.whatwg.org/wiki/Irc-people
  2974. # [23:46] <Hixie> necolas: discussion is always welcome, and can continue even with a proposal in the spec. it's not like browser vendors will immediately implement what we put in!
  2975. # [23:46] <annevk> at least to make sure nobody is pointing people away from where they should be...
  2976. # [23:46] * Quits: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com) (Quit: Colloquy for iPad - http://colloquy.mobi)
  2977. # [23:47] <Hixie> necolas: if there is information that should lead to a different solution being selected, whether it's given before or after the first draft is specced doesn't matter
  2978. # [23:47] <MarcDrummond> Hixie: Another option for the print use case would be providing a grayscale image. I don't think the srcset solution would make it easy to do that.
  2979. # [23:47] <Hixie> MarcDrummond: are you aware of anyone trying to do that?
  2980. # [23:47] <ShaneHudson> Hixie: Could I have an account on the whatwg wiki please?
  2981. # [23:47] <zewt> MarcDrummond: that'd be an easy addition: add a greyscale flag
  2982. # [23:47] <Hixie> ShaneHudson: e-mail?
  2983. # [23:47] <ShaneHudson> Hixie: shane@shanehudson.net
  2984. # [23:48] <TabAtkins> zewt: I don't think that's scalable, honestly. Translating a significant set of MQ into the srcset microsyntax is silly.
  2985. # [23:48] <necolas> Hixie: that's true.
  2986. # [23:48] <jgraham> TabAtkins: Is there any evidence it is a significant set?
  2987. # [23:48] <Hixie> ShaneHudson: account details in the mail
  2988. # [23:48] <TabAtkins> jgraham: I dunno.
  2989. # [23:48] <ShaneHudson> Hixie: Thank you :)
  2990. # [23:49] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
  2991. # [23:49] <Hixie> i didn't see anyone asking for colour. i saw an e-mail mentioning it and all it got iirc was a reply saying that it was not necessary and no disagreement.
  2992. # [23:49] <Hixie> hence it not being one of the use cases i considered
  2993. # [23:49] <TabAtkins> 'A
  2994. # [23:49] <necolas> Hixie: in which case, do you feel that perhaps a better job needs to be done of communicating with the wider developer community about the process etc.
  2995. # [23:49] <TabAtkins> Actually, looking over MQ, the only one I might consider useful is the grayscale one.
  2996. # [23:49] <MarcDrummond> Hixie: No, I don't know of somebody trying to do that (though there certainly could be interest in that), but it seems that would be easier to handle with media queries than having to create a different flag like grayscale for every use case. What is the issue with media queries?
  2997. # [23:49] <TabAtkins> So, shrug.
  2998. # [23:50] <zewt> Hixie: fwiw (thinking about the monochrome thing--not proposing it), "file.jpg w:1000 h:800 x:1.5" might be marginally better for future uses, eg. "c:mono" seems better than something like "monoc"
  2999. # [23:50] <ShaneHudson> necolas: defintely agree with you there. Until yesterday I had no idea anyone could join whatwg, thought we could only go as far as the working group.
  3000. # [23:50] <Hixie> necolas: i am not convinced we could have gotten any more useful input on this. we got literally hundreds of e-mails on it. what input do you think we could have gotten that we didn't get?
  3001. # [23:50] <necolas> Hixie: rather than this addition to the draft being viewed positively as evidence that the whatwg agrees that there is a problem worth solving, it has instead been interpreted as further evidence of a disconnect between the interested parties. that's unfortunate
  3002. # [23:50] <divya> necolas++
  3003. # [23:51] <annevk> Hixie: maybe we should rename "Contribute" to "Join" on http://www.whatwg.org/
  3004. # [23:51] <TabAtkins> necolas: That's honestly something that could be corrected by you and others. You *know* it's untrue. (If you haven't yet been convinced, then it's hopeless.)
  3005. # [23:51] <Hixie> MarcDrummond: we try to design to use cases, not to open-ended problem spaces. If it's not a problem, and the only things that matter are width, height, and pixel density, then it's better to optimise for those and have a terse syntax than to require verbose media queries for every image.
  3006. # [23:51] <Hixie> zewt: it could just be "mono"
  3007. # [23:51] <annevk> although it does state pretty clearly already everyone can make proposals
  3008. # [23:51] <necolas> TabAtkins: again, you seem to think it is *our* job to correct your failings
  3009. # [23:51] <divya> exactly
  3010. # [23:52] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
  3011. # [23:52] <annevk> but "Join" is nicer and more what we mean than "Contribute" I think; it's a community after all
  3012. # [23:52] <Hixie> ShaneHudson: any idea why you didn't think the whatwg was open? i mean, we're pretty radically open and say so everywhere we can...
  3013. # [23:52] <necolas> Fortunately, hixie has done a better job of explaining the situation
  3014. # [23:52] * Joins: joeellis (b8bf3910@gateway/web/freenode/ip.184.191.57.16)
  3015. # [23:53] <jgraham> Pretty sure the only kind of community you have to join is a gated one
  3016. # [23:53] <Hixie> necolas: well i am certainly eager to reduce any disconnect, but i don't know how to do it. I don't think two extra weeks of discussion would have made any difference there if the result was the same (which, unless there is new information that hadn't yet been raised, it would have been)
  3017. # [23:53] <necolas> As I said for the beginning, IMO what has been going on is more an issue of miscommunication. But that doesn't mean it should just be dismissed and not considered a problem that the whatwg might be wise to want to remedy.
  3018. # [23:53] <TabAtkins> necolas: Dunno why you think it's productive to point fingers. There was a communication mismatch, largely caused by Hixie operating as usual, but with a lot of people new to the process having some (unknown) expectation of how it should work that wasn't met.
  3019. # [23:53] <annevk> jgraham: so leave Contribute? :)
  3020. # [23:53] <TabAtkins> Shrug.
  3021. # [23:53] <Hixie> annevk: done
  3022. # [23:54] <jgraham> annevk: I think so :)
  3023. # [23:54] <necolas> TabAtkins: to be fair, you were the one who started suggesting that the problem lay with *us* and "egos" etc.
  3024. # [23:54] <ShaneHudson> Hixie: well I wanted to get involed with the spec etc about a year ago.. I went onto the w3c and everything I saw was about paying to be a business member etc. So I avoided for a few months. Eric Meyer and I spoke on twitter about it, and I then emailed the w3c support team, they told me that although you have to pay to be a member of the w3c there is the community groups. It was not until yesterday that I realised the working group was also free to co
  3025. # [23:54] <TabAtkins> Hixie's not the best communicator, but he's not a troll either. ^_^ If people new to the process are misinterpreting, and you know who they are and already have a connection to them, feel free to correct them!
  3026. # [23:54] <Hixie> jgraham: we tried contribute for a while, let's try join for a while and see if it helps :-)
  3027. # [23:54] <necolas> I just felt that it wasnt a good situation for anyone to not have developers feel invested in these processes in some form. I didn't expect to be shooed away for saying so.
  3028. # [23:55] <zewt> when i decided to look at specs, i just subscribed to webapps and whatwg and started reading, heh
  3029. # [23:55] <TabAtkins> necolas: I was trying my best to understand what you were saying. ^_^ If still seems to boil down to "the words he said weren't what I was expecting, even though the content is more-or-less okay".
  3030. # [23:55] <Hixie> ShaneHudson: ah, yeah, if you approached the w3c then i could see why you'd get that impression
  3031. # [23:55] <zewt> (couldn't say how I stumbled across the lists in the first place)
  3032. # [23:55] <Hixie> ShaneHudson: unfortunately we cannot control the w3c's messaging
  3033. # [23:55] <Hixie> necolas: i'm eager to change things to be more welcoming for developers and users and anyone else who isn't currently contributing
  3034. # [23:55] <necolas> TabAtkins: well people are entitled to disagree over proposals. any frustration centred around that is distinct from those of people feeling disconnected.
  3035. # [23:55] <Hixie> necolas: if you have any ideas i'm all ears
  3036. # [23:56] <Hixie> necolas: but i don't think just talking more would have achieved that
  3037. # [23:56] <adactio> TabAtkins: If you're still trying to understand how this all appears to people outside the WHATWG, Wilto has done a good job of summarising here: http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/
  3038. # [23:56] <zewt> if there's anything whatwg doesn't lack, it's talking more :)
  3039. # [23:56] <ShaneHudson> Hixie: I think maybe a ALA article or something that everybody reads, explaining how we can get involved. Perhaps there is already and I just hadn't seen anything
  3040. # [23:56] <Hixie> necolas: since we had already been talking about this for months at least (the earliest mail in the thread i just replied to with that big mail was from january)
  3041. # [23:56] <divya> Hixie: completely agreed.
  3042. # [23:56] <necolas> TabAtkins: and fwiw, no hard feelings. i know you have the right intentions
  3043. # [23:57] <divya> Hixie: at this point my only concern is as a dev i am having a hard time understanding how learning yet another syntax would make srcset adoption better or less painful.
  3044. # [23:57] <necolas> Hixie: i think talking more would actually help. but just as you expect the talking directed to the spec-work to be via the mailing list, developers expect the communication directed at them to be via channels that *they* use or can easily consume
  3045. # [23:57] <TabAtkins> adactio: I know how people can misinterpret things here. I've been subject to it myself before. :/ Doesn't mean that anything's wrong, just that people can have wrong expectations sometimes, and we can't please everyone.
  3046. # [23:58] * Joins: bradbice (~bradbice@209.117.183.2)
  3047. # [23:58] <TabAtkins> divya: Heh, every single CSS property in existence is a brand new microsyntax to learn. ^_^
  3048. # [23:58] <Hixie> ShaneHudson: good idea. any idea how one of us can go about writing an article for ALA?
  3049. # [23:59] <adactio> I share divya's concern. I'm not wedded to picture or srcset but I do think that "Avoid needless complexity" is a design principle that we should remember in this (and every other) case.
  3050. # [23:59] <annevk> isn't sharing the syntax with image-set therefore good?
  3051. # [23:59] <adactio> Hixie: write the article. Send it to ALA. I can put you in touch if you want.
  3052. # [23:59] <divya> TabAtkins: at the minimum they have adaptability, or some level of consistency with other syntaxes
  3053. # [23:59] <TabAtkins> annevk: It's the "NNNw NNNh" part that's new.
  3054. # Session Close: Wed May 16 00:00:00 2012

The end :)