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

Options:

# Session Start: Tue May 15 00:00:00 2012
# Session Ident: #whatwg
# [00:00] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
# [00:05] * Quits: tomasf (~tom@2002:55e5:dbde:0:b821:7ed1:5147:a7ef) (Quit: tomasf)
# [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?
# [00:10] * Joins: othermaciej (~mjs@17.244.9.246)
# [00:11] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
# [00:12] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
# [00:12] <zcorpan> matjas: https://twitter.com/zcorpan/status/202156793277857794
# [00:15] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
# [00:21] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
# [00:26] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
# [00:26] * Joins: isherman (isherman@nat/google/x-xblgydwaeazbrvzc)
# [00:27] * Quits: necolas (~necolas@5ade1e67.bb.sky.com) (Remote host closed the connection)
# [00:29] * Joins: shepazu (~shepazu@81.253.2.12)
# [00:30] * Quits: twisted` (~twisted@p5DDBAB67.dip.t-dialin.net) (Ping timeout: 265 seconds)
# [00:32] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
# [00:35] * Joins: KevinMarks (~KevinMark@64.65.178.199)
# [00:39] * Joins: cygri (~cygri@089-101-028170.ntlworld.ie)
# [00:42] * Joins: Druide__ (~Druid@p5B05C14C.dip.t-dialin.net)
# [00:44] * Quits: Druide_ (~Druid@p5B137EE6.dip.t-dialin.net) (Ping timeout: 265 seconds)
# [00:44] * jonlee is now known as jonlee|afk
# [00:47] <zcorpan> Hixie: you need to fire 'error' when the fetch fails (srcset)
# [00:48] <Velmont> zcorpan: Where are you reading?
# [00:48] <zcorpan> Velmont: http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#attr-img-srcset
# [00:51] <Velmont> zcorpan: Cool. Sending me to the benchmark page :P
# [00:51] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [00:51] <zcorpan> at least without running scripts :-)
# [00:51] <Velmont> Oh, it was not as slow as before now. Opera must have fixed a bug or something.
# [00:51] <TabAtkins> Hixie: Why are you making up new units for that?
# [00:53] * jonlee|afk is now known as jonlee
# [00:56] * Joins: onar (~onar@17.216.36.168)
# [00:56] * Quits: onar (~onar@17.216.36.168) (Client Quit)
# [00:56] * Joins: onar (~onar@17.216.36.168)
# [00:57] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
# [00:57] <Hixie> zcorpan: why?
# [00:57] <Hixie> TabAtkins: they're not units, just ways to distinguish which is present
# [00:58] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
# [00:58] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Read error: Connection reset by peer)
# [00:58] <zcorpan> Hixie: you fire load if it's successful. why not error?
# [00:58] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
# [00:58] <Hixie> zcorpan: nothing happens if it's not successful
# [00:58] <Hixie> zcorpan: so why bother telling anyone?
# [00:58] <Hixie> zcorpan: (think of a case like you've gone offline and then resize the window)
# [00:59] <Hixie> (i originally wanted to use another event if the image changed)
# [00:59] <zcorpan> Hixie: hmm. dunno. maybe it's better to just emit a message to the error console...
# [01:00] <Hixie> that's certainly reasonable
# [01:01] * Joins: nessy (Adium@nat/google/x-tigiucgjejqytoey)
# [01:02] <othermaciej> is the use of "breakpoint" in that one proposal a common term of art in web design?
# [01:02] <othermaciej> or design in general?
# [01:03] <TabAtkins> othermaciej: I've heard it commonly, though this could be due to a twitter bubble around me.
# [01:03] <othermaciej> I keep imagining stopping in gdb
# [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?
# [01:03] * Joins: MikeSmith (~MikeSmith@81.253.8.113)
# [01:03] <Hixie> i don't understand the question
# [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.
# [01:04] <Hixie> but maybe it's better if i just reply to the zillions of e-mails already on the list
# [01:04] <Hixie> rather than starting yet another conversation here :-)
# [01:04] * Joins: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [01:04] <Velmont> Hixie: hehe :] I'm in those.
# [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.
# [01:04] * Parts: cygri (~cygri@089-101-028170.ntlworld.ie)
# [01:05] <TabAtkins> From a layout perspective, resolution only has an effect on the intrinsic size of an image.
# [01:05] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Ping timeout: 260 seconds)
# [01:05] <Velmont> TabAtkins: Yes, -- I'm asking if it would be allowed to change height×width ratio in srcset.
# [01:05] <TabAtkins> If you set @width and @height, sending a 32dpi versus a 192dpi image is identical, except that one has more detail.
# [01:05] <TabAtkins> Velmont: It doesn't change the ratio. You might misunderstand what the w/h numbers are doing.
# [01:06] <Velmont> Ah.
# [01:06] <TabAtkins> They're equivalent to using a max-width/height Media Query.
# [01:06] <Velmont> It's not talking about the picture. It's actually a viewport mediaquery hint?
# [01:07] <Velmont> Hmmm. Okay. I thought normal.jpg (800x600), then hd@2.jpg 2x, hd@2.jpg 800w 600h would be equal.
# [01:07] <Velmont> That's making that usage clearer, yes. :P
# [01:07] <TabAtkins> Is there a reason for the strange spacing in your last line?
# [01:08] <TabAtkins> (I'm wondering if I'm missing some characters that should be there.)
# [01:08] <Velmont> TabAtkins: Heh, no... I really wanted to \n\tEXAMPLEHERE
# [01:09] <TabAtkins> Ah, kk.
# [01:10] * Quits: othermaciej (~mjs@17.244.9.246) (Quit: othermaciej)
# [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.
# [01:11] <TabAtkins> I suspect they'd be good enough, based on what I've heard of use-cases so far.
# [01:12] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
# [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.
# [01:14] <Velmont> The smartphone probably wants to fetch one it can show in portrait and landscape anyway.
# [01:14] <TabAtkins> I dunno!
# [01:15] <Velmont> And I guess people are not using 2048x200 pictures on a real device. -- Or maybe they are. Hmm, headers might be.
# [01:15] * Quits: mven (~mven__@169.241.49.57) (Ping timeout: 260 seconds)
# [01:15] <TabAtkins> Yup, that's a use-case.
# [01:15] <Velmont> I should think before I speak.
# [01:15] <TabAtkins> ^_^
# [01:15] <Velmont> Will sound so much wiser.
# [01:15] <Velmont> :D
# [01:16] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
# [01:16] * Quits: danheberden (~danheberd@li225-35.members.linode.com) (Quit: oh noes)
# [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)
# [01:19] * Joins: danheberden (~danheberd@li225-35.members.linode.com)
# [01:19] * Quits: danheberden (~danheberd@li225-35.members.linode.com) (Excess Flood)
# [01:20] * Joins: danheberden (~danheberd@li225-35.members.linode.com)
# [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.
# [01:23] <Velmont> zewt: So you are actually hindering an extra image fetch here.
# [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".
# [01:28] * Quits: twisted` (~twisted@p5DDB9484.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
# [01:33] * Joins: othermaciej (~mjs@17.245.104.240)
# [01:35] * Joins: seventh (seventh@69.80.107.71)
# [01:37] <zewt> gluh
# [01:38] <zewt> it needs to not be possible for sites to prevent you from pasting into form fields
# [01:38] <zewt> sites that stop you from copying and pasting your email address into confirm fields need to burn in a ditch
# [01:38] * Joins: mkanat (mkanat@nat/google/x-judurruwkwigdzov)
# [01:38] * Quits: othermaciej (~mjs@17.245.104.240) (Quit: othermaciej)
# [01:39] <TabAtkins> Yus.
# [01:39] <zcorpan> http://xkcd.com/970/
# [01:39] <zewt> "we will deliberately waste your time"
# [01:40] * Joins: othermaciej (~mjs@17.245.104.240)
# [01:40] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Quit: The computer fell asleep)
# [01:40] * Joins: KevinMarks (~KevinMark@64.65.178.199)
# [01:41] * Quits: seventh (seventh@69.80.107.71) (Remote host closed the connection)
# [01:42] * Quits: drublic (~drublic@frbg-5f730166.pool.mediaWays.net) (Remote host closed the connection)
# [01:43] * Joins: seventh (seventh@69.80.107.71)
# [01:45] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Ping timeout: 245 seconds)
# [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.
# [01:48] <zcorpan> or where there are restrictions on the password such that you can't pick anything sane, like with bredbandsbolaget
# [01:48] * Joins: richwild (560acfe2@gateway/web/freenode/ip.86.10.207.226)
# [01:48] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
# [01:49] <zewt> in general password rules just make everyon capitalize their password and add "1"
# [01:49] <zewt> they're a pretty good sign that whoever's running the site doesn't think things through
# [01:49] <TabAtkins> Yes.
# [01:49] <richwild> Yes1
# [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
# [01:50] <zewt> well non-ascii is asking for trouble, heh
# [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.
# [01:50] <zewt> (re: normalization)
# [01:50] <Philip`> TabAtkins: Maybe they're storing your password in a fixed-width database field
# [01:50] <TabAtkins> Unless they're not hashing your password before storing (which would make it fixed-length).
# [01:51] <TabAtkins> Philip`: See what I just said. ^_^
# [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
# [01:52] <TabAtkins> My password generator, at least, has the ability to *almost* satisfy those requirements.
# [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.
# [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
# [01:53] <TabAtkins> Philip`: Those banks are idiots. :/
# [01:53] <TabAtkins> I mean, if you just ask for three characters, that's a pretty decent chance of randomly guessing correctly.
# [01:53] <richwild> What do you think they must be storing?
# [01:53] <jamesr_> TabAtkins: they store a hash of each character!
# [01:54] <TabAtkins> jamesr_: Brilliant!
# [01:54] <Philip`> TabAtkins: They ask for 3 digits of the 4-digit PIN too
# [01:54] <TabAtkins> ...
# [01:54] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Quit: tantek)
# [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)
# [01:55] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
# [01:57] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Client Quit)
# [01:59] * Joins: ukai (ukai@nat/google/x-lbibgcnkmjnxsvuc)
# [01:59] <TabAtkins> Shrug. The right solution to that is a fob that provides OTPs. :/
# [01:59] <Hixie> which, ironically, is also somewhat common in europe
# [01:59] <Hixie> natwest has both sent me hardware and requires me to log in as Philip` describes
# [02:01] <TabAtkins> lolwut
# [02:03] <Philip`> I think they require the card-reading hardware device just for relatively high risk operations, like setting up a new payee
# [02:03] <Hixie> i don't think i've ever had to end up using it
# [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
# [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
# [02:09] <jamesr> zewt, in multi-monitor setups you have to pick (fairly arbitrarly) a device to vsync to
# [02:12] * jernoble is now known as jernoble|afk
# [02:13] <jamesr> the flow control situation is interesting for offscreen stuff
# [02:14] * Quits: ap (~ap@2620:149:4:1b01:c4ea:70e6:9e8a:fecf) (Quit: ap)
# [02:24] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
# [02:25] * Joins: tantek (~tantek@mb40536d0.tmodns.net)
# [02:27] * Quits: tantek (~tantek@mb40536d0.tmodns.net) (Read error: Connection reset by peer)
# [02:27] * Joins: tantek (~tantek@ip-64-134-223-52.public.wayport.net)
# [02:35] * Quits: jsbell (jsbell@nat/google/x-cuowikpwfmtqkizd) (Quit: There's no place like home...)
# [02:38] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [02:38] * Quits: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Read error: Connection reset by peer)
# [02:39] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
# [02:42] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
# [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)
# [02:49] <jamesr_> everything in a page is vsync'd together
# [02:49] <zewt> not if the page spans monitors
# [02:49] <jamesr_> doesn't matter
# [02:50] <jamesr_> everything within a page is rendered at the same time
# [02:50] <zewt> it's not rendering, it's backbuffer flipping
# [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
# [02:50] <zewt> rendering happens when it happens (with webgl)
# [02:50] * Quits: tantek (~tantek@ip-64-134-223-52.public.wayport.net) (Quit: tantek)
# [02:50] <zewt> not with webgl it isn't
# [02:51] <jamesr_> sure it is
# [02:51] <zewt> it isn't? heh
# [02:51] <jamesr_> draw ops in webgl to the webgl backbuffer happen whenever
# [02:51] <jamesr_> those are resolved/flipped/copied into the rest of the system as an independent step (not observable from the web directly)
# [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)
# [02:52] <jamesr_> no
# [02:52] <zewt> the point is that you want to begin rendering right after vsync, and that depends on the monitor
# [02:52] <jamesr_> it has to go to at least one intermediate buffer
# [02:52] <jamesr_> and nothing at all depends on which monitor an element lands on
# [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
# [02:53] <jamesr_> yes. in the multimonitor case, just pick some monitor and go
# [02:54] <jamesr_> i've heard of some non-web systems picking the monitor with the largest area of intersection with the window
# [02:54] <zewt> not some monitor; you want to pick the monitor the element is on, whenever possible
# [02:54] <jamesr_> no
# [02:54] <zewt> can you say something more informative than "no"? heh
# [02:54] <jamesr_> it doesn't make any difference what monitor the element is on
# [02:54] <zewt> why would you ever not do that?
# [02:54] <jamesr_> because individual elements are not flipped independently
# [02:54] <jamesr_> the whole buffer is prepared at once
# [02:54] <jamesr_> and then made available to every monitor
# [02:55] <zewt> how would you know that? heh
# [02:55] <zewt> it's an implementation detail, and a good implementation would sync as close to each monitor as possible
# [02:55] <jamesr_> i know that because i'm an implementor?
# [02:56] <zewt> of every implementation ever?
# [02:56] <jamesr_> an implementation as you describe would be infeasible
# [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
# [02:56] * Quits: MikeSmith (~MikeSmith@81.253.8.113) (Read error: Connection reset by peer)
# [02:56] * Joins: MikeSmith (~MikeSmith@81.253.8.113)
# [02:57] <zewt> (clearly someone at webkit agrees, if their requestAnimationFrame takes an element)
# [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
# [02:58] <jamesr_> you can't cite a nebulous "someone at webkit" against me when that someone is me
# [02:58] <zewt> okay i don't feel like a condescending conversation right now
# [02:58] <zewt> later
# [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
# [02:59] <zewt> uh huh
# [03:00] * jonlee is now known as jonlee|afk
# [03:06] * Quits: edwardbc (~edward.ba@186.176.193.20) (Ping timeout: 252 seconds)
# [03:12] * Quits: othermaciej (~mjs@17.245.104.240) (Quit: othermaciej)
# [03:13] * Quits: pablof (~pablof@144.189.101.1) (Quit: ^z)
# [03:17] * Joins: macpherson (~macpherso@2401:fa00::ea06:88ff:fecc:9412)
# [03:23] * Quits: myndzi (myndzi@c-67-168-184-168.hsd1.wa.comcast.net) (Ping timeout: 272 seconds)
# [03:26] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
# [03:27] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [03:41] * Quits: sicking (~chatzilla@nat/mozilla/x-amcbbrxrrwtkleao) (Remote host closed the connection)
# [03:42] * Joins: ehsan (~ehsan@209.20.29.228)
# [03:51] * Joins: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
# [03:53] * Quits: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
# [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])
# [04:07] * Quits: jamesr_ (jamesr@nat/google/x-tspymionlpbvsbtg) (Quit: jamesr_)
# [04:08] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
# [04:09] * Joins: tantek (~tantek@mf10536d0.tmodns.net)
# [04:10] * Joins: ehsan (~ehsan@209.20.29.228)
# [04:12] * Joins: tomasf (~tom@2002:55e5:dbde:0:b9fc:8df3:2f62:a08f)
# [04:36] * Joins: espadrine (~thaddee_t@63-235-13-3.dia.static.qwest.net)
# [04:38] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
# [04:43] * Quits: tantek (~tantek@mf10536d0.tmodns.net) (Quit: tantek)
# [04:54] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
# [05:01] * ojan_away is now known as ojan
# [05:04] * ojan is now known as ojan_away
# [05:10] * jonlee|afk is now known as jonlee
# [05:26] * Joins: niftylettuce (u2733@gateway/web/irccloud.com/x-piarwytdtjthqwqq)
# [05:36] * Joins: [[zzz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net)
# [05:39] * Quits: [[zz]] (~q@node-1as9.pool-125-25.dynamic.totbb.net) (Ping timeout: 245 seconds)
# [05:44] * [[zzz]] is now known as [[zz]]
# [06:06] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [06:23] * Quits: shepazu (~shepazu@81.253.2.12) (Ping timeout: 252 seconds)
# [06:41] * Quits: MikeSmith (~MikeSmith@81.253.8.113) (Ping timeout: 272 seconds)
# [06:42] * Joins: silentimp (~silentimp@77.87.42.24)
# [06:43] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
# [06:56] * Quits: silentimp (~silentimp@77.87.42.24) (Quit: silentimp)
# [07:22] * Joins: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
# [07:24] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 244 seconds)
# [07:25] * Quits: richwild (560acfe2@gateway/web/freenode/ip.86.10.207.226) (Ping timeout: 245 seconds)
# [07:25] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Ping timeout: 244 seconds)
# [07:25] * Quits: danja (~danny@host94-204-dynamic.13-79-r.retail.telecomitalia.it) (Ping timeout: 244 seconds)
# [07:26] * Joins: danja (~danny@host94-204-dynamic.13-79-r.retail.telecomitalia.it)
# [07:26] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
# [07:27] * Quits: nephyrin (~nephyrin@v-1025.fw1.scl3.mozilla.net) (Ping timeout: 244 seconds)
# [07:27] * Joins: nephyrin (~nephyrin@v-1025.fw1.scl3.mozilla.net)
# [07:28] * Joins: stalled (~stalled@unaffiliated/stalled)
# [07:29] * Joins: Areks (~Areks@rs.gridnine.com)
# [07:30] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
# [07:38] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
# [07:45] * Joins: mishunov (~spliter@142-131-95-178.pool.ukrtel.net)
# [07:48] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
# [07:58] * Quits: KDN (~kdn@90.149.135.254) (Quit: KDN)
# [07:59] * Quits: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr_)
# [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."
# [08:00] <AryehGregor> "equal to"?
# [08:00] <AryehGregor> Oh, I guess everything runs single-threaded, so it's not a deadlock.
# [08:00] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 272 seconds)
# [08:03] * Joins: niloy (~niloy@61.12.96.242)
# [08:06] * Joins: fishd (darin@nat/google/x-umaxkmblauxytytp)
# [08:15] * Parts: mishunov (~spliter@142-131-95-178.pool.ukrtel.net)
# [08:20] * Quits: stalled (~stalled@unaffiliated/stalled) (Read error: Connection reset by peer)
# [08:22] * Joins: stalled (~stalled@unaffiliated/stalled)
# [08:24] <matjas> in which cases must `>` be escaped in HTML? I can only think of unquoted attribute values
# [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.
# [08:26] <AryehGregor> Maybe in <textarea> if preceded by "</textarea", and likewise for <title>?
# [08:27] <AryehGregor> That's not relevant if you're really asking "which characters do I have to escape?" and are already escaping <.
# [08:29] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
# [08:29] * Quits: padenot (~paul@li421-75.members.linode.com) (Quit: WeeChat 0.3.5)
# [08:31] <AryehGregor> There are other cases where ">" isn't allowed, but it can't be escaped in those cases.
# [08:31] <AryehGregor> Like attribute names, or certain configurations within <script>/<style>/comments.
# [08:33] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 245 seconds)
# [08:34] <matjas> AryehGregor: thanks for confirming. that’s indeed the use case here, escaping HTML (and `<` is being escaped)
# [08:35] * Quits: niloy (~niloy@61.12.96.242) (Remote host closed the connection)
# [08:35] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [08:35] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
# [08:37] * Quits: JohnAlbin_zzzzzz (~JohnAlbin@114-36-33-17.dynamic.hinet.net) (Quit: HTTP/1.1 404 JohnAlbin Not Found)
# [08:38] * Quits: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net) (Ping timeout: 252 seconds)
# [08:38] * Joins: padenot (~paul@li421-75.members.linode.com)
# [08:40] * Joins: niloy (~niloy@61.12.96.242)
# [08:40] * Joins: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net)
# [08:43] * Joins: drublic (~drublic@frbg-5d84f2b2.pool.mediaWays.net)
# [08:45] * Joins: KDN (~kdn@pc173-96.hiof.no)
# [08:50] * Quits: decadance (~decadance@204.93.201.197) (Read error: Operation timed out)
# [08:50] * Joins: PalleZingmark (~Adium@217.13.228.226)
# [08:51] * Joins: decadance (~decadance@204.93.201.197)
# [08:52] * Quits: nessy (Adium@nat/google/x-tigiucgjejqytoey) (Quit: Leaving.)
# [08:58] * Joins: Ms2ger (~Ms2ger@91.181.123.95)
# [09:07] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
# [09:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [09:17] * Joins: KevinMarks (~KevinMark@64.65.178.199)
# [09:17] * Joins: Kolombiken (~Adium@217.13.228.226)
# [09:18] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
# [09:18] * Joins: pyrsmk (~pyrsmk@202.182.141.88.rev.sfr.net)
# [09:19] * Joins: nessy (~Adium@49.178.1.98)
# [09:20] * Quits: KDN (~kdn@pc173-96.hiof.no) (Remote host closed the connection)
# [09:20] * Joins: KDN (~kdn@2001:700:a00:ff21:3d71:5a2a:c16e:4d48)
# [09:25] * Quits: Guest31456 (~jondong@123.126.22.58) (Ping timeout: 272 seconds)
# [09:25] * Quits: kinetik (~kinetik@121.98.132.55) (Ping timeout: 255 seconds)
# [09:25] * Joins: spliter_ (~spliter@16-98-112-92.pool.ukrtel.net)
# [09:26] * Parts: spliter_ (~spliter@16-98-112-92.pool.ukrtel.net)
# [09:26] * Joins: kinetik (~kinetik@121.98.132.55)
# [09:26] * Joins: jondong (~jondong@123.126.22.58)
# [09:26] * jondong is now known as Guest32383
# [09:32] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net) (Read error: Connection reset by peer)
# [09:33] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
# [09:33] * Quits: nessy (~Adium@49.178.1.98) (Ping timeout: 252 seconds)
# [09:37] * Quits: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk) (Quit: sarspazam)
# [09:39] <Hixie> phew
# [09:39] <Hixie> finally caught up with the tsunami
# [09:48] * Ms2ger didn't hear about a tsunami in the Bay Area
# [09:48] <Hixie> the responsive tsunami
# [09:48] <Hixie> been replying to that thread for like a week now
# [09:48] <Ms2ger> Oh, have fun with that :)
# [09:48] <Hixie> every night i'm almost done
# [09:48] <Hixie> i come back the next morning
# [09:48] <Hixie> and it's run away again
# [09:48] <Hixie> but i finally caught up!
# [09:48] * Quits: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net) (Read error: Operation timed out)
# [09:49] <Ms2ger> I would suggest fixing some bugs instead ;)
# [09:49] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
# [09:49] <Hixie> bugs are on hold til i deal with mail
# [09:50] <Hixie> which is a far bigger pile right now
# [09:50] <Hixie> though i see from the chart that you've done a good amount of work on the bugs yourself!
# [09:50] <Hixie> nice!
# [09:51] <Ms2ger> Saddening how much junk accumulated, really :)
# [09:51] <Hixie> heh
# [09:54] * Joins: necolas (~necolas@5ade1e67.bb.sky.com)
# [09:55] * Joins: wookiehangover (~wookiehan@c-67-161-138-118.hsd1.co.comcast.net)
# [09:55] * Joins: Necrathex (~Necrathex@82-170-160-25.ip.telfort.nl)
# [09:55] * Joins: tomasf_ (~tomasf@77.72.97.5.c.fiberdirekt.net)
# [09:59] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [09:59] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [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.
# [10:00] <matjas> are the spec short URLs documented anywhere? if not I’ll take a stab at writing it up
# [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
# [10:01] <ShaneHudson> For which one?
# [10:02] <matjas> ShaneHudson: the multi-page and one-page versions of the HTML living standard
# [10:02] <ShaneHudson> Ah, I have only seen the multi page so far
# [10:03] <matjas> Hixie: heads up, http://www.whatwg.org/specs/ is missing a </strong>
# [10:04] * jonlee is now known as jonlee|afk
# [10:06] * Quits: kinetik (~kinetik@121.98.132.55) (Ping timeout: 250 seconds)
# [10:06] * Joins: kinetik (~kinetik@121.98.132.55)
# [10:09] * Quits: mkanat (mkanat@nat/google/x-judurruwkwigdzov) (Quit: Ex-Chat)
# [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!
# [10:09] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
# [10:12] * Joins: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net)
# [10:14] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
# [10:16] * Quits: necolas (~necolas@5ade1e67.bb.sky.com) (Remote host closed the connection)
# [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. :-)
# [10:18] * Joins: remysharp (u4345@gateway/web/irccloud.com/x-sjhqsgmhzfdkbxbt)
# [10:18] <ShaneHudson> Yes, I asked everyone about 5pm GMT two days ago I believe
# [10:19] <ShaneHudson> about 20 people said that they did not like srcset, and nobody said otherwise
# [10:19] * Joins: gwicke (~gabriel@212.255.28.33)
# [10:19] <odinho> ShaneHudson: What you do is reply to Hixie's email that came in just half an hour ago.
# [10:19] <ShaneHudson> I am still reading it, it is extremeley long
# [10:20] <odinho> ShaneHudson: Well, popularity contests is not the best way for specs to be made. Technical discussion and merit, however, is.
# [10:21] <ShaneHudson> True of course, but have you not seen the discussions on the community group?
# [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
# [10:21] <kennyluck> ShaneHudson, you can join the W3C HTML WG and write a change proposal.
# [10:21] <ShaneHudson> I will reply to Hixie's email later today, so that I do not rush it
# [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.
# [10:22] <Ms2ger> [tm], have a look at the DOM4 Makefile ;)
# [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
# [10:23] <Ms2ger> ShaneHudson, joining the HTML WG is generally a waste of time
# [10:23] <odinho> ShaneHudson, kennyluck: No need joining HTML WG... Better to just take it up in WHATWG where it's discussed.
# [10:23] <Ms2ger> If you've got technical arguments for your suggestions, you will find the WHATWG list is enough for you
# [10:24] <odinho> Ms2ger: Heh, implictly saying what the other one is used for?
# [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/
# [10:26] <kennyluck> I am not going to say if that's a waste of time or not. Other people will tell you. :p
# [10:26] <odinho> ShaneHudson: I'm seconding Ms2ger by the way.
# [10:26] <jgraham> Please don't fork the discussion into to a third group
# [10:27] <kennyluck> That I agree. THough writing a change proposal is another thing.
# [10:27] <Ms2ger> A bigger waste of time? :)
# [10:27] <kennyluck> No idea. *shrug*
# [10:27] <odinho> Hehe, I think we can discuss technical on the list first.
# [10:28] <jgraham> Writing a change proposal isn't the best way to get the spec changed
# [10:28] <ShaneHudson> kennyluck: Thank you for the link, I will bookmark it but for now will take the advice of Ms2ger and odinho
# [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.
# [10:28] <jgraham> The best way is to present convincing technical arguments that it is wrong
# [10:29] * Joins: romainhuet (u2533@gateway/web/irccloud.com/x-debfqfzxgozdikxa)
# [10:29] <jgraham> kennyluck: I assume the goal is not "remove srcset" per-se but "enable a good design for adaptive image loading"
# [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)
# [10:29] <odinho> change proposal: http://w3cmemes.tumblr.com/post/22414849805
# [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.
# [10:29] <jgraham> remysharp: What do you mean?
# [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?".
# [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
# [10:30] <odinho> remysharp: That's more or less implied, -- but yes, it should say that.
# [10:30] <jgraham> kennyluck: I hope the actual goal is not to be obstructionist, but to be constructive
# [10:30] <[tm]> Ms2ger: thanks, looking now
# [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.
# [10:31] <jgraham> remysharp: Right, the browser would process the whole image tag at once and load the one correct resource
# [10:31] <ShaneHudson> remysharp: haha!
# [10:31] <jgraham> It's not implied, I assume
# [10:31] <odinho> remysharp: Yes I know yes I know. :P I work in Opera. But it's still a draft under discussion :P
# [10:31] <ShaneHudson> Yes I think we have all seen why the spec needs to be a tightly written as any contract
# [10:31] <jgraham> Without reading the spec, I imagine it specifies which image resource should be displayed
# [10:31] <kennyluck> jgraham, I am being constructive by giving ShaneHudson an answer he is looking for.
# [10:32] <jgraham> Of course a browser could chose to load other resources if it wanted. But a browser *could* do anything
# [10:32] <jgraham> kennyluck: I think it is more constructive to take the question a little less literally.
# [10:32] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
# [10:33] <odinho> remysharp: It's specified.
# [10:33] <odinho> remysharp: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
# [10:33] * Joins: gwicke (~gabriel@212.255.28.33)
# [10:33] * Joins: graememcc (~chatzilla@host86-140-179-108.range86-140.btcentralplus.com)
# [10:34] <remysharp> odinho: uses the word "updates" - should that be "load"?
# [10:34] <remysharp> it seems to suggest it's resetting state (though I've not finished reading)
# [10:34] <odinho> remysharp: load uses that algorithm.
# [10:35] <jgraham> remysharp: first load seems like a special case of update
# [10:35] <jgraham> ShaneHudson: FWIW I am *very* skeptical that anything involving media queries is the right solution
# [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
# [10:36] <jgraham> Becauseit should only be possible to vary on 3 properties: viewport width, viewport height and display density
# [10:36] <othermaciej> (the spec doesn't specify anything about prefetching)
# [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
# [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
# [10:37] <jgraham> Right, prefetching is an optimisation
# [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
# [10:37] <annevk> remysharp: example of a browser vendor messing up that badly?
# [10:37] <remysharp> video
# [10:37] <remysharp> video referrers were missing from implementations
# [10:38] <remysharp> it's not huge, but it was serious enough to nuke a few servers during hotlinking
# [10:38] <remysharp> Specs are hard for "authors" to read - see appcache - and any ambiguity just makes everything harder for all involved
# [10:39] <annevk> sure
# [10:39] <jgraham> Right, that's why specs are hard to read
# [10:39] <jgraham> (not just for authors, but they spend less time doing it)
# [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
# [10:39] <annevk> I was just curious as doing more network requests than required is something all browsers try very hard to avoid
# [10:40] <jgraham> Well, not entirely
# [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.
# [10:40] <odinho> ShaneHudson: That is the best and easiest way to reply and give feedback.
# [10:40] <jgraham> I think many implementations of speculation can cause network requests that are later not used
# [10:40] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
# [10:41] <jgraham> Or starting loading DOM-created elements before they are inserted
# [10:41] * Quits: Ms2ger (~Ms2ger@91.181.123.95) (Ping timeout: 272 seconds)
# [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
# [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.
# [10:44] <odinho> E.g. what the outcome is in different scenarios for the same page :-)
# [10:44] * Joins: karlcow (~karl@nerval.la-grange.net)
# [10:44] <annevk> [tm]: I think you need to modify Overview.src.html quite a bit for that
# [10:44] <jgraham> To be fair, that's only really if you disagree with the requirements presented so far
# [10:44] <annevk> [tm]: e.g. it needs some kind of license switch I guess
# [10:45] <annevk> [tm]: a style sheet switch
# [10:45] * Joins: kenneth_ (kenneth@nat/nokia/x-hdharwlqympylfml)
# [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
# [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
# [10:47] <odinho> :-)
# [10:47] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
# [10:49] * Joins: jarib (~jarib@unaffiliated/jarib)
# [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
# [10:50] <odinho> ShaneHudson: Nope, I was maybe thinking about replying to that.
# [10:51] <jgraham> I don't see how bandwidth will ever be possible to solve in this way
# [10:51] <[tm]> annevk: yeah, no worries
# [10:51] <[tm]> working on it now
# [10:51] <jgraham> And hopefully will become less of a problem over time
# [10:51] <annevk> [tm]: you can probably base it on DOM or something
# [10:51] * Joins: vincentb_ (Adium@teledetection213.teledetection.fr)
# [10:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 260 seconds)
# [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.
# [10:51] <annevk> ShaneHudson: Hixie's email explains why bandwidth cannot be exposed as a meaningful metric
# [10:52] <[tm]> need to get it done before plh goes on vacation, so we can his OK for FPWD transition
# [10:52] <[tm]> annevk: I think I got it done for now
# [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
# [10:52] <annevk> [tm]: he already gave his OK
# [10:52] <odinho> annevk: It doesn't have to be exposed. As it will be an optimization, the browser can choose.
# [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
# [10:52] <odinho> jgraham: Yeah, and we all know how bad that is :P
# [10:52] <jgraham> This turns out to be *very* hard to get right
# [10:52] <odinho> jgraham: But it's easier on phones.
# [10:53] <ShaneHudson> Right I must be going, see you all later
# [10:53] <[tm]> annevk: yeah, that was provisional on me actually getting it ready
# [10:53] <jgraham> odinho: If you are on a data constrained plan, I suggest Opera mini :p
# [10:53] <annevk> [tm]: oh lol, politics
# [10:53] <odinho> jgraham: Because you can trust the OS knows if you're on GPRS, EDGE, 3G, Wifi.
# [10:53] <annevk> [tm]: you'd think he would have heard of pubrules
# [10:53] <jgraham> So?
# [10:54] <jgraham> How to map that to "I want different assets" is decidedly non-obvious
# [10:54] * Parts: vincentb_ (Adium@teledetection213.teledetection.fr)
# [10:54] <jgraham> (on desktop you can also be on various different connection types, including some or all of those)
# [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.
# [10:55] <odinho> jgraham: Same with my main browser on my normal computer. NetworkManager also expose this information to programs running.
# [10:55] <annevk> odinho: it seems you want the smallest image if you're on 3G as well because you're data-constrained
# [10:55] <annevk> odinho: whereas someone with an iPad on 3G with no data constraints might not want that at all
# [10:55] <jgraham> I have been on non-constrained 3G
# [10:55] <jgraham> Right
# [10:55] <annevk> odinho: so that doesn't seem like a meaningful metric
# [10:55] <odinho> annevk: I'm not up to 1GB.
# [10:55] <annevk> odinho: 1GB is constrained
# [10:55] <odinho> Have any of you ever tried using GPRS?
# [10:55] <jgraham> So a user would have to manually map connection type to desired assets
# [10:55] <jgraham> It would be insane
# [10:55] <odinho> It's very slow.
# [10:56] <annevk> odinho: I know
# [10:56] <jgraham> We can't have a feature that requires UI that no one would implement
# [10:56] <odinho> My computer knows when I'm on GPRS.
# [10:56] <odinho> I don't see why it couldn't just take the lightest assets when I am.
# [10:57] <annevk> odinho: how many assets do you think the page is going to provide though?
# [10:57] <jgraham> In that case I would probably turn on turbo/use mini
# [10:57] <jgraham> And not rely on athors to get it right
# [10:58] <annevk> yeah
# [10:58] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [10:58] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [10:59] <odinho> annevk: Well, many sites are CMS driven, mine are, and I guess something like 280w, 576w, 1024w.
# [11:00] <odinho> Yeah, Opera mini/turbo is a better fix, -- but it does rely on proxy servers.
# [11:01] <jgraham> Sure
# [11:01] <jgraham> Anyway, there was a solution to this problem in HTML
# [11:01] <jgraham> lowsrc
# [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.
# [11:01] * Joins: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi)
# [11:01] <jgraham> It didn't really go anywhere
# [11:01] <odinho> So there needs to be no spec change.
# [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.
# [11:03] * Joins: necolas (~necolas@80.231.76.54)
# [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
# [11:03] * Joins: mpt (~mpt@nat/canonical/x-ftikaoatghrwyvmu)
# [11:03] * Quits: mpt (~mpt@nat/canonical/x-ftikaoatghrwyvmu) (Changing host)
# [11:03] * Joins: mpt (~mpt@canonical/mpt)
# [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.
# [11:07] <annevk> that's already allowed
# [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. "
# [11:07] <annevk> rtfs?
# [11:08] <odinho> annevk: I have. I'm not discussing with the spec, I'm discussing with jgraham, which is saying something else :-)
# [11:09] <jgraham> I'm not saying something else
# [11:09] <jgraham> I'm saying having a feature for it in the spec is silly
# [11:10] <odinho> jgraham: It doesn't really need a feature in the spec, -- because the current information should be enough.
# [11:10] <zcorpan> Hixie: "
# [11:10] <zcorpan> This seems like something that's currently relatively easily handled using
# [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
# [11:11] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Read error: Operation timed out)
# [11:12] * Joins: richwild (b0236a65@gateway/web/freenode/ip.176.35.106.101)
# [11:13] <[tm]> annevk: can I add you as a co-editor on the URL spec?
# [11:13] * Joins: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
# [11:14] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
# [11:16] * Quits: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi) (Ping timeout: 244 seconds)
# [11:17] <annevk> [tm]: if arv is going to edit I don't think it's needed for me to be listed there
# [11:19] * Joins: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi)
# [11:22] <[tm]> OK
# [11:23] <[tm]> annevk: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
# [11:23] <[tm]> I made a new make target
# [11:23] <[tm]> WD target
# [11:24] <[tm]> so we just flip it back to the "publish" target after WD publication
# [11:25] <[tm]> anyway, break time here
# [11:25] <annevk> [tm]: what I do these days is generate a TR.html copy so the editor's draft is not affected
# [11:25] <[tm]> thank God almighty
# [11:25] <annevk> heh
# [11:25] * Quits: Lachy (~Lachy@cm-84.215.193.30.getinternet.no) (Quit: Computer has gone to sleep.)
# [11:25] <[tm]> annevk: OK, I can switch it to that later today
# [11:43] * Joins: Lachy (Lachy@nat/opera/x-anyekuhbgiqyykzk)
# [11:46] * Joins: nonge_ (~nonge@p508299DF.dip.t-dialin.net)
# [11:49] * Quits: nonge (~nonge@p50829C68.dip.t-dialin.net) (Read error: Operation timed out)
# [11:51] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
# [11:52] * Joins: jarib (~jarib@unaffiliated/jarib)
# [12:02] * Joins: Isaq (dcff0288@gateway/web/freenode/ip.220.255.2.136)
# [12:02] * Quits: tomasf (~tom@2002:55e5:dbde:0:b9fc:8df3:2f62:a08f) (Quit: tomasf)
# [12:02] * tomasf_ is now known as tomasf
# [12:07] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
# [12:10] * Parts: Isaq (dcff0288@gateway/web/freenode/ip.220.255.2.136)
# [12:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [12:16] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [12:16] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [12:18] * Joins: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [12:18] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
# [12:19] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
# [12:20] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 244 seconds)
# [12:23] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 265 seconds)
# [12:23] <annevk> hmm
# [12:24] <annevk> people on the WHATWG list don't seem to understand how pixel density affects images in practice
# [12:24] <annevk> oh well
# [12:29] <othermaciej> people seem not to get the fact that the pixel density you provide affects how the image renders
# [12:29] <othermaciej> I'm not sure why this is hard to grasp (apparently)
# [12:30] <othermaciej> people doing native iOS development seem to understand how 2x images fit into the picture
# [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
# [12:31] * Joins: nessy (~Adium@124-169-129-81.dyn.iinet.net.au)
# [12:32] <annevk> or I give feedback on how constraining URLs is not a good idea
# [12:32] <annevk> "I've seen no objections about that aspect in the Community Group thread, where a number of authors have given feedback."
# [12:32] <annevk> well I just gave you some
# [12:33] <jgraham> Yeah, the implication that the source of the feedback somehow trumps its actual merit is distressing
# [12:35] * Quits: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net) (Quit: tantek)
# [12:36] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [12:42] * Joins: mpt (~mpt@nat/canonical/x-cepzvudaeikfjrzv)
# [12:42] * Quits: mpt (~mpt@nat/canonical/x-cepzvudaeikfjrzv) (Changing host)
# [12:42] * Joins: mpt (~mpt@canonical/mpt)
# [12:44] * annevk stops with http://xkcd.com/386/ and goes to do something else
# [12:49] <othermaciej> heh
# [12:58] <annevk> so should we add new Range()?
# [12:59] * Joins: val__ (~val@c0017-1-82-245-14-126.fbx.proxad.net)
# [13:01] <[tm]> annevk: fyi, I reverted http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html to being unmolested
# [13:02] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
# [13:02] <[tm]> and made a TR.html for the TR version
# [13:02] <[tm]> http://dvcs.w3.org/hg/url/raw-file/tip/TR.html
# [13:02] <annevk> ta
# [13:03] <annevk> [tm]: you should probably change the <title> and "Living Draft" in the <h2> does not work either for a TR publication
# [13:05] <[tm]> hai
# [13:06] * Joins: Ms2ger (~Ms2ger@vpnh210.ugent.be)
# [13:11] * Joins: maikmerten (~maikmerte@port-92-201-49-70.dynamic.qsc.de)
# [13:12] <annevk> AryehGregor: how is the detach() experiment going?
# [13:13] <annevk> Ms2ger: should we add baseLang?
# [13:13] <annevk> we should have a better name ideally...
# [13:14] <Ms2ger> What's baseLang?
# [13:15] <annevk> language of the node/element
# [13:15] <annevk> as determining it through script is non-trivial
# [13:16] <Ms2ger> Hmm
# [13:16] <annevk> can baseURI still be null btw?
# [13:16] <annevk> DOMString? looks like a bug if everything starts with about:blank
# [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
# [13:22] <annevk> respec :/
# [13:24] <[tm]> yeah
# [13:25] <annevk> emailed some feedback to public-webapps
# [13:26] <annevk> I assumed he's subscribed since I didn't find an email address
# [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])
# [13:40] * Joins: skylamer` (cgskylamer@78.90.213.55)
# [13:43] * Quits: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
# [13:43] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [13:48] <annevk> language barrier ftl https://www.w3.org/Bugs/Public/show_bug.cgi?id=17042
# [13:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [13:49] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [13:53] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
# [13:53] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [13:56] <annevk> zcorpan: hey yt?
# [13:56] <annevk> zcorpan: you reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=16712
# [13:57] <annevk> zcorpan: I'm trying to figure out how you could ever hit that case 2
# [13:57] * Quits: krijn (u2319@gateway/web/irccloud.com/x-xkjyqwvqxbdmgfei)
# [13:57] <annevk> zcorpan: because it seems case 1 covers it aleady
# [13:58] <zcorpan> annevk: the element doesn't have a prefix
# [14:01] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
# [14:02] * Joins: smaug (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
# [14:02] <annevk> zcorpan: exactly, so its namespace prefix equals prefix
# [14:02] * Quits: smaug____ (~chatzilla@193-64-20-179-nat.elisa-mobile.fi) (Ping timeout: 272 seconds)
# [14:03] <annevk> zcorpan: they're both null
# [14:03] * smaug is now known as smaug____
# [14:03] <zcorpan> annevk: /prefix/ is "bar"
# [14:04] * Joins: jarib (~jarib@unaffiliated/jarib)
# [14:04] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [14:05] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [14:05] <annevk> zcorpan: right
# [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?
# [14:06] <annevk> zcorpan: hmm I guess so
# [14:06] <annevk> aah namespaces
# [14:06] <zcorpan> :)
# [14:07] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [14:08] <zcorpan> "or whose namespace prefix is null and local name is "xmlns" if prefix is null:"
# [14:08] <zcorpan> (possibly also check the namespace of the "xmlns" attribute)
# [14:08] <annevk> I think I'll add some words for clarity
# [14:08] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
# [14:11] * Quits: skylamer` (cgskylamer@78.90.213.55) (Remote host closed the connection)
# [14:16] <annevk> man this is some long sentence :(
# [14:22] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
# [14:23] <[tm]> annevk: kinuko is a woman, btw
# [14:25] <zcorpan> annevk: looks good
# [14:25] <[tm]> and she is subscribed to public-webppas
# [14:27] <annevk> cool cool
# [14:28] <annevk> is it just the -o or -ko that indicates the name of a woman in Japan?
# [14:32] <annevk> Ms2ger: garbage collection in DOM
# [14:32] * Quits: Ms2ger (~Ms2ger@vpnh210.ugent.be) (Ping timeout: 260 seconds)
# [14:32] <annevk> Ms2ger: where should we put that
# [14:32] <annevk> yeah leave the channel alright
# [14:32] * Joins: erichynds (~ehynds@64.206.121.41)
# [14:32] <annevk> chicken
# [14:33] <[tm]> annevk: -ko
# [14:34] <charlvn> there are japanese men who also have names ending in -o or -ko afaik
# [14:34] <[tm]> yeah
# [14:34] <charlvn> although i think -ko is more common with female names
# [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
# [14:36] * Joins: Ms2ger (~Ms2ger@vpnh064.ugent.be)
# [14:36] <annevk> ah, the chicken returns :)
# [14:36] <[tm]> I think the men's names are usually -hiko
# [14:37] <charlvn> [tm]: sounds right
# [14:38] <Ms2ger> Hah
# [14:38] <Ms2ger> annevk, in the closet?
# [14:39] <annevk> ideally, but smaug____ wants it
# [14:39] <annevk> HTML has http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection
# [14:39] <smaug____> what do I want?
# [14:39] <annevk> garbage collection notes in DOM
# [14:40] <smaug____> not really gc, but definition of ownership
# [14:40] <smaug____> or definition in which cases certain objects won't be deleted
# [14:40] <Ms2ger> Everything owns everything :)
# [14:41] <smaug____> whether gc is used internally, is implementation detail
# [14:42] <annevk> not really sure we have to say much then
# [14:43] <annevk> other than that sentence of HTML
# [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
# [14:46] <smaug____> "Unless disconnect() is called, MutationObserver observes node as long as the node exists"
# [14:46] <smaug____> something like that
# [14:47] <annevk> that doesn't mean much
# [14:49] <smaug____> it doesn't ?
# [14:49] <smaug____> it means that the MutationObserver doesn't die even if you don't keep a reference to it
# [14:57] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
# [14:59] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [15:05] * Quits: KDN (~kdn@2001:700:a00:ff21:3d71:5a2a:c16e:4d48) (Quit: KDN)
# [15:06] * Joins: KDN (~kdn@pc173-96.hiof.no)
# [15:10] * Quits: KDN (~kdn@pc173-96.hiof.no) (Ping timeout: 260 seconds)
# [15:15] * Joins: ehsan (~ehsan@209.20.29.228)
# [15:15] * Joins: davidb (~davidb@66.207.208.98)
# [15:20] * Joins: necolas_ (~necolas@80.231.76.54)
# [15:20] * Quits: necolas (~necolas@80.231.76.54) (Read error: Connection reset by peer)
# [15:20] * Quits: val__ (~val@c0017-1-82-245-14-126.fbx.proxad.net) (Ping timeout: 245 seconds)
# [15:20] * Quits: [[zz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net) (Remote host closed the connection)
# [15:21] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
# [15:24] <[tm]> btw, http://lists.w3.org/Archives/Public/public-whatwg-archive/ is not available
# [15:24] <[tm]> *now available
# [15:25] * Joins: [[zz]] (~q@node-9rj.pool-182-53.dynamic.totbb.net)
# [15:25] <annevk> yeah noticed that yesterday
# [15:25] <annevk> very cool
# [15:26] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
# [15:26] <[tm]> now we should figure out how to add an Archived-at header to whatwg@whatwg.org messages
# [15:30] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Ping timeout: 256 seconds)
# [15:37] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
# [15:38] * Joins: JohnAlbin (~JohnAlbin@114-36-33-17.dynamic.hinet.net)
# [15:38] * Joins: MacTed (~Thud@63.119.36.36)
# [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
# [15:40] * necolas_ is now known as necolas
# [15:42] * Joins: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se)
# [15:46] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Remote host closed the connection)
# [15:46] * Quits: ehsan (~ehsan@209.20.29.228) (Remote host closed the connection)
# [15:46] * Joins: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
# [15:48] * Quits: JVoracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
# [15:48] * Joins: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
# [15:49] * Joins: KDN (~kdn@90.149.135.254)
# [15:51] <zcorpan> [tm]: archived-at would be nice
# [15:55] * Joins: dbaron (~dbaron@nat/mozilla/x-hqhzmdpkxbxypemi)
# [15:55] <dbaron> anybody know of a description of the advantages of WebVTT over TTML (or some subset thereof)?
# [15:58] <annevk> dbaron: http://lists.w3.org/Archives/Public/public-html/2010May/0160.html
# [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?
# [16:00] <dbaron> (may or may not actually be the case, but under discussion)
# [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
# [16:01] <annevk> and draconian error handling for a text format which would be a first as far as browser technology goes
# [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
# [16:02] <zewt> brb reboot
# [16:02] <annevk> TTML is badly designed
# [16:02] <annevk> that's why we went with WebVTT
# [16:03] <zewt> actually no reboot
# [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
# [16:05] <dbaron> so what's going on is:
# [16:05] * Joins: jdong_bot_ (~jdong_bot@106.3.63.56)
# [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
# [16:05] * Joins: ehsan (~ehsan@66.207.208.98)
# [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
# [16:05] <zewt> that sounds BS
# [16:05] <zewt> (in the "not true" sense, not "it's stupid" sense)
# [16:06] <zewt> (not that it wouldn't be the latter too :)
# [16:07] <annevk> I heard about (b) too
# [16:07] <dbaron> something from http://www.fcc.gov/encyclopedia/video-programming-accessibility-advisory-committee-vpaac
# [16:07] <annevk> (a) does not matter much; W3C charters groups to work on silly stuff all the time
# [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!"
# [16:08] <zewt> http://lists.w3.org/Archives/Public/public-texttracks/2012Apr/0001.html
# [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
# [16:09] <dbaron> apparently it would be VPAAC WG1
# [16:09] <Ms2ger> espadrine, Ha. Ha. Ha.
# [16:09] <dbaron> apparently the bigger problem is that everybody implements a different subset of TTML
# [16:10] <annevk> isn't the bigger problem that it's a terrible format?
# [16:11] <dbaron> meant the bigger problem with the requirement
# [16:11] <annevk> thanks zewt
# [16:11] <dbaron> but yes, that too
# [16:11] <zewt> there's nothing else leading to the "something something federal requirement" noise, right?
# [16:12] <annevk> during the F2F glenn mentioned it and a couple of people were like "yup that's correct; tough luck WebVTT guys"
# [16:12] * Quits: richwild (b0236a65@gateway/web/freenode/ip.176.35.106.101) (Quit: Page closed)
# [16:13] <odinho> Hehe, yeah, fear struck.
# [16:13] <zewt> "that" glenn? heh
# [16:13] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [16:13] <annevk> other glenn!
# [16:13] <dbaron> SMPTE-TT is a profile (with additions) of TTML, no?
# [16:13] <dbaron> not a container for it as that message implies?
# [16:13] <zewt> captioning isn't rocket science; if you need *profiles* of a captioning format, something seems badly amiss
# [16:14] <jgraham> Well clearly something *is* badly amiss
# [16:14] <zewt> something usually is
# [16:14] * Joins: richw (b0236a65@gateway/web/freenode/ip.176.35.106.101)
# [16:14] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [16:15] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: No route to host)
# [16:15] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [16:16] <annevk> dbaron: looks like a super-subset, yes
# [16:17] <annevk> as in, it supersets a subset of TTML
# [16:17] <jgraham> Isn't that what we call a "different format"?
# [16:17] <annevk> it uses namespaces so it's cool
# [16:18] <zewt> heh
# [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
# [16:18] <zcorpan> does it have 18 new namespaces?
# [16:18] <[tm]> and look for "apparatus"
# [16:18] <zewt> annevk: someone on the webgl list said he wants to push for using the URL-namespacing-gimmick to identify webgl extensions
# [16:18] <zewt> raaaaaaaaage
# [16:18] <zewt> re: xml tried that. it sucked. stop it
# [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 ?
# [16:19] <annevk> zewt: "feature" in object does not work anymore?
# [16:19] <annevk> zewt: but yeah, ...
# [16:19] <zewt> oh everything works fine
# [16:19] <zewt> he just wanted to change to urls because *crickets*
# [16:20] <odinho> [tm]: They sure say a lot of apparatus all over the place!
# [16:20] * dbaron heads back indoors
# [16:21] <zewt> fortunately he didn't go on to push it, but it's astonishing that nonsense keeps cropping up
# [16:22] <jgraham> Those damn crickets
# [16:22] <annevk> http://cdn.memegenerator.net/instances/400x/20446042.jpg
# [16:23] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net) (Ping timeout: 245 seconds)
# [16:24] <[tm]> odinho: the section "A. Apparatus Subject to Section 203 of the Act
# [16:25] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [16:25] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [16:27] <odinho> [tm]: Page 65 seems interesting. But nothing about TTML.
# [16:27] <[tm]> odinho: "If a
# [16:27] <[tm]> video programming owner provides captions to a video programming distributor or provider using the
# [16:27] <[tm]> Society of Motion Picture and Television Engineers Timed Text format (SMPTE ST 2052-1:2010:
# [16:27] <[tm]> “Timed Text Format (SMPTE-TT)” 2010) (incorporated by reference, see § 79.100), then the VPO has
# [16:27] <[tm]> fulfilled its obligation to deliver captions to the video programming distributor or provider in an
# [16:27] <[tm]> acceptable format.
# [16:28] <[tm]> and "The VPAAC proposed that the Commission require a single standard interchange format
# [16:28] <[tm]> so that video programming does not need to be re-captioned to comply with different standards.
# [16:28] <[tm]> 508
# [16:28] <[tm]> The
# [16:28] <[tm]> VPAAC proposed SMPTE-TT as the standard interchange format
# [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.
# [16:29] <odinho> But that last thing is not written in-doc as requirement, I guess? They only propose that as single standard?
# [16:30] <[tm]> odinho: they are careful to not say it is "mandatory"
# [16:30] <[tm]> but instead "safe harbor"
# [16:30] <[tm]> I don't know that that particular term of art means
# [16:30] <[tm]> e.g., "unlike adopting SMPTE-TT as the mandatory interchange or delivery format, commenters explain that a
# [16:30] <[tm]> safe harbor approach would balance goals of efficiency, certainty, and consumer access with needed
# [16:32] <odinho> e will also provide in our rules that devices that implement SMPTE-TT
# [16:32] <odinho> will be deemed in compliance with our rules, while simultaneously allowing devices to achieve the same
# [16:32] <odinho> functionality without implementing that standard.5
# [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.
# [16:33] * Joins: grandmasChoad (~chatzilla@vpn.space150.com)
# [16:33] <odinho> So it seems it can be done ;-)
# [16:34] * Parts: grandmasChoad (~chatzilla@vpn.space150.com)
# [16:36] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 244 seconds)
# [16:36] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
# [16:37] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
# [16:37] * Joins: niloy (~niloy@61.12.96.242)
# [16:38] * Joins: mpt (~mpt@canonical/mpt)
# [16:43] * Quits: espadrine (~thaddee_t@63-235-13-3.dia.static.qwest.net) (Quit: espadrine)
# [16:44] * Joins: raphc (~rc@92.103.77.27)
# [16:46] * Quits: raphc (~rc@92.103.77.27) (Client Quit)
# [16:47] * Joins: raphc (~rc@92.103.77.27)
# [16:47] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [16:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 244 seconds)
# [16:52] * Joins: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp)
# [16:53] * Joins: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com)
# [16:54] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [16:54] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [17:04] <zcorpan> Hixie: which characters are supposed to be paragraph separators in WebVTT for the purpose of bidi?
# [17:04] <zcorpan> just Bidi_Class=Paragraph_Separator ?
# [17:05] * Quits: jdong_bot_ (~jdong_bot@106.3.63.56) (Remote host closed the connection)
# [17:05] <zcorpan> tr9 isn't really explicit about which characters it wants to consider paragraph separators
# [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
# [17:09] * Quits: erichynds (~ehynds@64.206.121.41)
# [17:09] * Joins: TabAtkins_ (~jackalmag@50-0-151-4.dsl.dynamic.sonic.net)
# [17:10] <odinho> I surely don't understand why some people are so agressively against srcset. And noone can say why.
# [17:10] <odinho> (... reading twitter)
# [17:10] * Joins: espadrine (~thaddee_t@nat/mozilla/x-qwzuhuzvufelhgan)
# [17:12] <zcorpan> oh, i think i found the definition of "newline function" now
# [17:12] * Joins: edwardbc (~edward.ba@186.176.193.20)
# [17:12] <[tm]> odinho: you can save yourself the confusion by not reading twitter :)
# [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
# [17:13] <zcorpan> so it's just B class
# [17:13] * Quits: charlvn (~charlvn@cl-2393.ams-05.nl.sixxs.net) (Quit: leaving)
# [17:21] * Quits: dbaron (~dbaron@nat/mozilla/x-hqhzmdpkxbxypemi) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [17:23] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Quit: The computer fell asleep)
# [17:23] * Joins: KevinMarks (~KevinMark@64.65.178.199)
# [17:23] <TabAtkins_> odinho: Because http://w3cmemes.tumblr.com/post/22831818920/the-css-wgs-primary-failure-mode , that's why.
# [17:27] * Quits: espadrine (~thaddee_t@nat/mozilla/x-qwzuhuzvufelhgan) (Quit: espadrine)
# [17:27] <annevk> "If you don't set your image's resolution appropriately, you'll get unexpected sizing effects." is not actually true
# [17:27] <annevk> browsers ignore the DPI set in the image
# [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.
# [17:28] <TabAtkins_> At least, it won't be the same as a 96dpi image at 1x.
# [17:28] <odinho> TabAtkins_: Yeah, thinking that. But saying it alound feels wrong... :]
# [17:28] * Quits: KevinMarks (~KevinMark@64.65.178.199) (Ping timeout: 260 seconds)
# [17:28] <annevk> TabAtkins: it's way easier to think about it in terms of pixel density rather than resolution
# [17:29] * Quits: Kolombiken (~Adium@217.13.228.226) (Ping timeout: 240 seconds)
# [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.
# [17:29] * Joins: espadrine (~thaddee_t@nat/mozilla/x-dgdzmbmmirpyrvqw)
# [17:29] * ericc|afk is now known as eric_carlson
# [17:29] <annevk> TabAtkins: e.g. everything from 90-130 is typically treated as 1x
# [17:29] <TabAtkins_> annevk: Do image programs talk about pixel density? I thought they explicitly talked about "dpi" when saving an image.
# [17:29] * Quits: richt (richt@nat/opera/x-cddvplkbghseomcj) (Remote host closed the connection)
# [17:29] <annevk> TabAtkins: whereas 260-330ppi would be 2x
# [17:30] <annevk> TabAtkins_: in an image program you would just make an image with twice the amount of pixels in each direction
# [17:30] * Quits: twisted` (~twisted@p5DDB9484.dip.t-dialin.net) (Quit: Computer has gone to sleep.)
# [17:30] <annevk> TabAtkins_: you don't use the dpi setting because it is already ignored by browsers (and has to for compatibility)
# [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.
# [17:30] <annevk> I sort of thought everyone involved in the discussion knew this...
# [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
# [17:31] <annevk> you have a 10x10 image and a 20x20 image
# [17:31] <TabAtkins_> annevk: Uh, yes, I know.
# [17:31] <annevk> the latter you set as 2x
# [17:31] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [17:31] <annevk> you don't have to care about dpi
# [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.
# [17:31] <annevk> which is nice because it various all over
# [17:32] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [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).
# [17:32] <TabAtkins_> And when you talk about resolution, people will want to do that.
# [17:32] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [17:32] * Quits: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Quit: tomasf)
# [17:32] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [17:33] <jgraham> When people talk about "size" they mean "in pixels", no?
# [17:33] <annevk> if it's double resolution it's width and height will be larger
# [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.
# [17:33] <odinho> TabAtkins_: <img src=10x10 srcset="20x20.jpg 2x"> is exactly equivalent to <img src=20x20.jpg width=10 height=10>
# [17:33] <TabAtkins_> odinho: Yes, I know.
# [17:34] <annevk> you cannot create an image of 10x10 with more detail and have it rendered as 10x10
# [17:34] <TabAtkins_> annevk: Yes, I know.
# [17:34] <annevk> there's no such thing
# [17:34] <annevk> well then I've no idea what you're talking about
# [17:34] <odinho> :S
# [17:35] * Quits: Ms2ger (~Ms2ger@vpnh064.ugent.be) (Ping timeout: 245 seconds)
# [17:35] <jgraham> annevk: TabAtkins_ seems to (sometimes) be using "size" to mean something that can be measured with a ruler
# [17:35] <TabAtkins_> If you create a "5 inch wide" image at 192dpi, browsers will display it as 10 inches wide.
# [17:35] <jgraham> It seems clearer to me to always use "size" to mean something in pixels
# [17:36] <jgraham> Because, y'know, working out what real world dimensions you get isn't that easy or helpful
# [17:37] <annevk> TabAtkins_: aren't all images stored as pixels in the end?
# [17:37] <TabAtkins_> annevk: Yes?
# [17:37] <annevk> so then I'm not sure why we have to talk about inches
# [17:37] <TabAtkins_> The point is author expectations.
# [17:37] <annevk> I think authors deal in pixels too
# [17:37] <TabAtkins_> I'm not *sure* if authors think that way, but I suspect that some do. I dunno.
# [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?
# [17:37] <annevk> I certainly do when creating images
# [17:37] <odinho> Ah, they're doomed anyway if they think about stuff like that.
# [17:37] <annevk> necolas: <img> parsing is a lost cause
# [17:37] <odinho> Some print guys do, and they're always way off. Have to explain.
# [17:37] <TabAtkins_> necolas: Changing the parsing of the <img> element is a lost cause.
# [17:38] <annevk> necolas: adding attributes does not affect parsing
# [17:38] <TabAtkins_> Dammit, annevk, why are you 2 seconds faster than me?
# [17:38] <necolas> adding attributes doesn't help with polyfilling either
# [17:38] <odinho> TabAtkins_: In europe?
# [17:38] <annevk> TabAtkins_: Europe :p
# [17:38] <odinho> FTW!
# [17:38] <jgraham> necolas: I answered that once already today
# [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
# [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
# [17:40] <jgraham> If you are trying to understand that, I see the problem
# [17:40] <jgraham> You are working from a false premise
# [17:40] <necolas> jgraham: you don't think having 2 http requests is a problem for polyfilling?
# [17:40] <necolas> jgraham: and what premise would that be?
# [17:40] <jgraham> "developers have been cast aside"
# [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.
# [17:41] <necolas> that isnt the goal
# [17:41] <TabAtkins_> necolas: Oh. Then I don't understand what you mean by "2 http requests are a problem for polyfilling".
# [17:41] <necolas> jgraham: [the work of] developers
# [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.
# [17:42] <necolas> TabAtkins_: the browser is going to request the image in `src` before any JS can get to work
# [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.
# [17:42] <necolas> odinho: yeah we've discussed that but dont think it is optimal
# [17:42] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 244 seconds)
# [17:43] <TabAtkins_> necolas: ...that's why I just suggested using only @srcset and omitting @src.
# [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
# [17:43] <jgraham> necolas: The fact that people have brought up technical shortcomings does not mean that "the work has been cast aside"
# [17:44] <jgraham> Wht do you think this is if not engagement?
# [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.
# [17:44] <jgraham> Seriously, if there are technical problems with the srcset proposal, point them out
# [17:45] * nonge_ is now known as nonge
# [17:45] <jgraham> It's a way more useful use of everyone's time than complaining about lack of engagement
# [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.
# [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.
# [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.
# [17:46] <necolas> I just wish there had been better communication
# [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
# [17:46] <necolas> TabAtkins_: this has nothing to do with whos solution is getting used
# [17:47] <TabAtkins_> necolas: Do you think the discussion is completely over and this is a fait accompli? That's incorrect.
# [17:47] <dglazkov> good morning, Whatwg!
# [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.
# [17:47] * gwicke is now known as gwicke_away
# [17:47] <adactio> What necolas said.
# [17:47] <odinho> Philip`: Yes, sure. But it's not super easy if people feel hurt.
# [17:47] <necolas> because, initially, responsive images was not of interest to you guys, we set up a CG
# [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
# [17:47] <TabAtkins_> necolas: Again, I'm not sure how what has been happening is anything if not "hearing dev's interest".
# [17:48] * Quits: seventh (seventh@69.80.107.71) (Remote host closed the connection)
# [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
# [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.
# [17:48] <TabAtkins_> How is this anything other than "you win, your arguments were right, here's a solution for your problem".
# [17:49] <necolas> jgraham: that doesnt sound like an unpleasant experience :)
# [17:49] <necolas> TabAtkins_: "thanks, we'll take over from here", right?
# [17:49] * Joins: doublec_ (~doublec@cd.pn)
# [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.
# [17:49] * Quits: slartsa_ (~slartsa@vps-2498-1.tilaa.nl) (Read error: Operation timed out)
# [17:49] * Quits: doublec (~doublec@unaffiliated/doublec) (Read error: Operation timed out)
# [17:49] <jgraham> The problem with being upset in technical discussions is that it doesn't scale very well.
# [17:49] <TabAtkins_> (Also because voting is usually a bad way to make technical decisions.)
# [17:49] <jgraham> You would end up being upset a lot of the time
# [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.
# [17:50] <dglazkov> oh cool, browserfolk vs. webdevfolk
# [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.
# [17:50] <zcorpan> fight!
# [17:50] * dglazkov is both. Should I be arguing with myself?
# [17:50] <jgraham> Certianly *I* would if I was upset every time my initially-preferred solution didn't make the final spec
# [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).
# [17:50] <zcorpan> dglazkov: clearly you should hit yourself in your face
# [17:50] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [17:50] * Joins: Obvious (tachikoma@188.226.74.2)
# [17:50] <dglazkov> zcorpan: and enjoy it
# [17:50] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [17:51] <hober> dglazkov: count me in! /me hits himself in the face too :)
# [17:51] * jgraham still thnks we should have done MathML by making browsers understand something like LaTeX
# [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 :)
# [17:51] <jgraham> Oh, right, Tuesday night is S&M night
# [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.
# [17:51] <zcorpan> jgraham: that was on the table before we put mathml in to html, wasn't it?
# [17:52] <jgraham> zcorpan: Well I tried to convivce Hixie it was a good idea then
# [17:52] * Quits: Obvious_MkII (tachikoma@188.226.74.2) (Ping timeout: 255 seconds)
# [17:52] <jgraham> I guess it would have been a lot of work
# [17:52] <jgraham> But afaict it is still the most popular way of including MathML in HTML
# [17:52] <jgraham> But implemented in Javascript
# [17:52] <annevk> he tried to think of a scheme that implied a lot of the markup
# [17:52] * Joins: slartsa (~slartsa@vps-2498-1.tilaa.nl)
# [17:52] <annevk> but that didn't work out
# [17:53] * Joins: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
# [17:53] <zcorpan> annevk: iirc real LaTeX was also considered
# [17:53] <dglazkov> whoa, how did we just switch from srcset to mathml?
# [17:53] <dglazkov> is this the equivalent of Godwin's law in the standards discussions?
# [17:53] * Joins: scottjehl (u3055@gateway/web/irccloud.com/x-negzqnxitrusiewh)
# [17:53] <dglazkov> once LaTeX is mentioned...
# [17:53] <necolas> odinho: oh of course. there are many aspects of being a web developer
# [17:53] <miketaylr> probably all the punching in the face
# [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
# [17:54] <scottjehl> hello!
# [17:54] <necolas> annevk: i didn't say that
# [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. ^_^
# [17:55] <odinho> TabAtkins_: Hehe, okay. In my limited experience in Opera though, most people were webdevs :-)
# [17:55] <hober> TabAtkins_: that's why you, me, and some other people get to try to make sure that wg keeps it real. :)
# [17:55] <TabAtkins_> odinho: Opera might be different, I dunno.
# [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.
# [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?
# [17:56] <TabAtkins_> necolas: (But, hopefully, don't rehash criticisms that have already been answered, unless you have new information.)
# [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
# [17:56] <zcorpan> just saying "this is not what i want!" is also not very useful, though.
# [17:57] <necolas> that is not what i was saying
# [17:57] <TabAtkins_> necolas: Once again, that is *exactly* what happened in this case.
# [17:57] <necolas> i think it is fair to discuss the way that things get done
# [17:57] <zcorpan> necolas: sorry, i didn't mean you, i just saw some bugs filed along those lines
# [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.
# [17:57] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [17:57] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
# [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. ^_^
# [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.
# [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
# [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
# [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.
# [18:01] <TabAtkins_> necolas: I don't like to characterize it as sour grapes, but that's what it feels like to me.
# [18:01] <necolas> well you'd be wrong
# [18:01] <necolas> and i don't think you should dismiss this like that
# [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).
# [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.
# [18:02] <necolas> TabAtkins_: hah, but wilcox is always unhappy :)
# [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.
# [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.
# [18:03] <necolas> definitely
# [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. ^_^
# [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
# [18:04] <necolas> TabAtkins_: [facepalm] it's not about ego either
# [18:04] <jgraham> *usable
# [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".
# [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.
# [18:06] <necolas> TabAtkins_: have that kind of thing filter down to the CG itself would be a great start
# [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.
# [18:06] <TabAtkins_> necolas: Feel free to forward the email to the CG, then!
# [18:07] <TabAtkins_> bbiab
# [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
# [18:07] * Parts: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
# [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.
# [18:07] * Joins: niloy (~niloy@61.12.96.242)
# [18:07] <Wilto> So.
# [18:07] <divya> adactio: fwiw there are some concerns raised about picture element
# [18:07] <annevk> adactio: actually hober knew about <picture>
# [18:08] <divya> as there are w.r.t srcset.
# [18:08] <annevk> adactio: and used that in his evaluation
# [18:08] <zewt> (hard to take people seriously when they use words like "obstreperous")
# [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.
# [18:08] <odinho> scottjehl: If giving feedback, it has to be on the mailing list for it to be seen and replied to.
# [18:08] <divya> (lol zewt)
# [18:08] <annevk> adactio: and <picture> and variants has come up since 2007 or so
# [18:08] <annevk> adactio: it's not a recent invention
# [18:08] <zewt> odinho: heh my thought was "we're hiding discussions away on github now?"
# [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.
# [18:08] <annevk> adactio: popped up shortly after I proposed <video> I think
# [18:08] <adactio> zewt: Apologies. I'll try not to use words of more than three syllables from now on. *sheesh*
# [18:09] <zewt> (sarcasm is worse)
# [18:09] <Wilto> Meanwhile, the only missive from the WHATWG on `img set` seems to be this: http://junkyard.damowmow.com/507
# [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
# [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.
# [18:09] <Wilto> And moreover, to wonder whether any `process` exists here in the first place.
# [18:10] <Wilto> Or if merit is simply based on the fact that things were—or were not—“invented here.”
# [18:10] <annevk> Wilto: the way the WHATWG works is that people email and the editor takes those emails and produces a proposal
# [18:10] <annevk> Wilto: usually that proposal goes directly in the spec, sometimes he puts up something on damwmow.com or other
# [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.
# [18:10] <Wilto> This was a decision made in a vacuum. Let’s not pretend there was any process involved.
# [18:11] * Joins: Guest1064 (~anonymous@87.115.113.220)
# [18:11] <Wilto> The only repeated defense has been “this is easier for implementors.”
# [18:11] <annevk> Wilto: people emailed, Hixie replied with a proposal...
# [18:11] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
# [18:11] <Wilto> And Hixie proceeded despite the response.
# [18:11] <annevk> Wilto: I guess you haven't read the email then
# [18:11] <necolas> annevk: so what are the CG designed for, just so we know in the future?
# [18:12] * Quits: jochen__ (jochen@nat/google/x-snbxeiczyyqshrne) (Remote host closed the connection)
# [18:12] <Wilto> I don’t care how many times I’m told “we considered feedback.”
# [18:12] * Joins: jochen__ (jochen@nat/google/x-qodgpcnmgjesufuh)
# [18:12] <annevk> necolas: the WHATWG has a WHATCG for patent reasons
# [18:12] <Wilto> If none of that feedback is incorporated, we’re just being humored further.
# [18:13] <annevk> necolas: I think in general they're used as a discussion group
# [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?
# [18:13] <necolas> annevk: so, people discuss in a CG, then email hixie?
# [18:13] <odinho> Wilto: Have you read the feedback?
# [18:13] * Joins: Adam_ (4580040a@gateway/web/freenode/ip.69.128.4.10)
# [18:13] <Philip`> I like how the spec says "(Steps in synchronous sections are marked with .)" in my font
# [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
# [18:13] <Philip`> (Looks like there's meant to be some visible character there instead)
# [18:13] <Wilto> Let me be frank:
# [18:14] <zewt> (what does "developer support" mean? popularity is a fairly low factor in spec decisions, i think)
# [18:14] <annevk> necolas: making a CG when there's already a group for HTML seems like the mistake that was made here
# [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
# [18:14] <odinho> accepted, it's clear that the time *was* useful.
# [18:14] <Wilto> I do not care about Hixie’s opinion, any more than anyone should care about mine.
# [18:14] * Quits: Adam_ (4580040a@gateway/web/freenode/ip.69.128.4.10) (Client Quit)
# [18:14] <zewt> (bad ideas can become popular)
# [18:14] * Joins: adamdbradley (4580040a@gateway/web/freenode/ip.69.128.4.10)
# [18:14] <Wilto> This is all, frankly, a little sad.
# [18:14] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 256 seconds)
# [18:14] <Wilto> I’ve seen seen no defense of `img set` on technical merit.
# [18:15] <Wilto> Where are the published use cases?
# [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?
# [18:15] <odinho> Wilto: ...?
# [18:15] <necolas> if yes, then shut them all down
# [18:15] <annevk> necolas: we're not the W3C
# [18:15] <necolas> yeah, i was just talking aloud
# [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
# [18:15] * Quits: nessy (~Adium@124-169-129-81.dyn.iinet.net.au) (*.net *.split)
# [18:15] * Quits: pererik_ (~pe@unaffiliated/pererik) (*.net *.split)
# [18:15] * Quits: Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp) (*.net *.split)
# [18:15] * Quits: rektide (~rektide@deneb.eldergods.com) (*.net *.split)
# [18:15] <odinho> Wilto: Have you read the full threads on WHATWG, and are you honestly meaning that?
# [18:15] * Joins: rektide_ (~rektide@deneb.eldergods.com)
# [18:16] <necolas> but if people are being sent to CG's, and they have no worth, then that isn't great
# [18:16] <annevk> necolas: and most CGs are not about changing HTML
# [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?
# [18:16] <annevk> necolas: if you want to change HTML you should not set up a CG, for anything else they're probably great
# [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
# [18:16] <necolas> so HTML CG's are worthless, CSS CG's are ?, other CG's are ?
# [18:16] <odinho> Wilto: It's easy to polyfill. Tell us why it's not.
# [18:16] <annevk> necolas: I don't think there are CSS CGs either
# [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.
# [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.
# [18:17] <necolas> jgraham: does srcset have browser vendors on board?
# [18:17] <Wilto> odinho: That will result in two requests in browsers with JS on.
# [18:17] <necolas> i bet that more people working for browser vendors were aware of our CG than this proposal
# [18:17] <odinho> Wilto: No, it will not. Take a new look. No src attribute.
# [18:17] <jgraham> necolas: Browser vendors pay attention to the WHATWG at least
# [18:17] <adactio> So much for the priority of constituencies.
# [18:17] <scottjehl> odhino src is required via the HTML spec
# [18:17] <Wilto> odinho: So, in non-supporting browsers without JavaScript: no image.
# [18:17] <odinho> scottjehl: Easy to change.
# [18:17] <jgraham> adactio: What nonsense
# [18:18] <Wilto> odinho: With JavaScript, rather.
# [18:18] <scottjehl> not in existing browsers
# [18:18] <gsnedders> adactio: If impls won't support something, then a change doesn't help users.
# [18:18] <odinho> Wilto: Oh, you have to actually write the polyfill of course. :-) But that's easy.
# [18:18] <Wilto> If we’re being honest, the WHATWG is completely entrenched.
# [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
# [18:18] <Wilto> Arguing here won’t change anything.
# [18:18] <zewt> (is wilto just trolling?)
# [18:18] <zewt> (sure smells like it)
# [18:18] <jgraham> zewt: I hope not
# [18:18] <odinho> scottjehl: They don't throw any exceptions or anything if you omit the src.
# [18:19] * Joins: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
# [18:19] <odinho> scottjehl: It's perfectly doable.
# [18:19] <Wilto> odinho, zewt, jgraham: I’ve posted scottjehl’s gist covering why polyfills may not be possible.
# [18:19] * Joins: dydx (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net)
# [18:19] * Quits: dydx (~dydz@76-220-18-65.lightspeed.sntcca.sbcglobal.net) (Client Quit)
# [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.
# [18:19] <odinho> I've read it.
# [18:19] <Wilto> Can you prove otherwise, odinho?
# [18:19] <Wilto> I’d love to see some code.
# [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)
# [18:20] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
# [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
# [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)
# [18:20] <krijnh> Wilto: digital beers received, thanks! :)
# [18:20] <jgraham> That's just common sense.
# [18:20] <gsnedders> adactio: Spec'ing what developers want if browsers won't impl it doesn't help the developers.
# [18:20] <jgraham> But the priority of constituencies doesn't give authors magical powers
# [18:21] * Joins: pererik (~pe@c-89-233-213-67.cust.bredband2.com)
# [18:21] * Joins: nessy (~Adium@124-169-129-81.dyn.iinet.net.au)
# [18:21] * Joins: Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp)
# [18:21] <Philip`> scottjehl: (I don't know if anywhere reliably documents what current browsers do actually do in this case)
# [18:21] <jgraham> If browser vendors agree that a different spec will work better for end users they will adopt the better spec
# [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?
# [18:22] <Wilto> easier for implementors*
# [18:22] <zewt> developers often want things they can't have, like more synchronous APIs in the UI thread
# [18:22] <jgraham> Wilto: If it is provably better, please prove it
# [18:22] <Wilto> zewt: This isn’t about doing what’s best for some petulant developers.
# [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
# [18:22] <scottjehl> h so little precedence, we've yet to test how src-less images behave in existing browsers
# [18:22] <annevk> Wilto: afaik <picture> does not address the pixel density use case
# [18:22] <Wilto> With citations, documentation, etc.? I have, zewt.
# [18:23] <zewt> what?
# [18:23] <jgraham> I really haven't seen that many emails making technical objections to @srcset or arguments in favour of <picture>
# [18:23] <Wilto> Y’know, nevermind.
# [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.
# [18:23] <jgraham> Just lots of assertions taht developers prefer <picture>
# [18:23] <necolas> jgraham: but where is the proff srcset is better?
# [18:23] <necolas> s/proff/proof
# [18:23] <annevk> adactio: you don't think what Hixie wrote illustrates why srcset was chosen?
# [18:23] <Wilto> jgraham: http://www.w3.org/community/respimg/
# [18:23] <necolas> it's a strange point to make
# [18:23] <jgraham> necolas: Various arguments in its favour have been made
# [18:23] <Wilto> The “lots of assertions” are from developers.
# [18:24] * rektide_ is now known as rektide
# [18:24] <jgraham> It doesn't reuse an different feature in a mostly incompatible way
# [18:24] <jgraham> It is relatively concise to author
# [18:24] <jgraham> It is much easier for UAs to process
# [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.
# [18:24] <jgraham> (and therefore less likely to be buggy)
# [18:25] <Wilto> Else, we’re just in denial.
# [18:25] <Wilto> jgraham: Can you prove that “mostly incompatible” statement?
# [18:25] <jgraham> To be honest, most authors have never been asked, and no one seems to have actually tried both
# [18:25] <Wilto> I stress that the WHATWG wiki is publicly editable; I’d love to see a reasoned response to use cases.
# [18:25] <Wilto> jgraham: Those we asked preferred picture. I’m sure you’re not saying “we didn’t ask everyone.”
# [18:26] <zewt> i'm an author and i sure prefer concise syntax
# [18:26] * annevk too
# [18:26] <Wilto> zewt: That’s a factor, then, among the many voices we’ve heard from.
# [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
# [18:26] <Wilto> Two more for `img src`.
# [18:26] <divya> zewt: most authors prefer what is easiest to understand
# [18:26] * Quits: Taggnostr (~quassel@dyn57-365.yok.fi) (Read error: No route to host)
# [18:26] <divya> not what is most concise.
# [18:27] * Joins: Taggnostr (~quassel@dyn57-365.yok.fi)
# [18:27] <annevk> Wilto: so that wiki page; what it says for high resolution displays does not actually work
# [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/
# [18:27] <jgraham> The problem with this kind of "preference" thing is that it is rather hard to tell much from first impressions
# [18:27] <scottjehl> jgraham: why does it make sense for <video> but not <picture>?
# [18:27] <necolas> that goes both ways
# [18:27] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [18:28] <annevk> scottjehl: it's not exactly clear media="" makes sense for <video>
# [18:28] <jgraham> scottjehl: I don't think it does make sense for <video>; only Opera implement it and we suggested dropping it
# [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
# [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.”
# [18:28] <annevk> scottjehl: it's even implemented by all browsers; <video> has it mostly for type=""
# [18:28] <Wilto> zewt: So you’re stating that—because of the forum—those opinions have been disregarded by the WHATWG.
# [18:28] <annevk> scottjehl: and for <track>
# [18:28] * Quits: MacTed (~Thud@63.119.36.36) (Ping timeout: 244 seconds)
# [18:28] <jgraham> Wilto: I don't know how to solve problems in that algebra
# [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
# [18:29] <Wilto> jgraham: That much is obvious.
# [18:29] <Wilto> zewt: It was posted to the list twice.
# [18:29] <jgraham> Wilto: It would be more convincing if someone actually implemented both and tried them out
# [18:29] * Joins: jreading (~Adium@ip98-169-200-82.dc.dc.cox.net)
# [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)
# [18:29] * Joins: Guest1064 (~anonymous@87.115.113.220)
# [18:30] <necolas> jgraham: scottjehl already made a <picture> polyfill
# [18:30] <Wilto> zewt: Would you prefer I encouraged all those commenters to post their +1s on the mailing list?
# [18:30] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
# [18:30] <necolas> it would be easy to make one for srcset and then see how people get on with using them
# [18:30] * Joins: ap (~ap@2620:149:4:1b01:8c01:d49c:4306:e324)
# [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.
# [18:30] <jgraham> necolas: So where is the srcset one for comparison?
# [18:30] <jgraham> Ah you said that
# [18:31] <necolas> jgraham: no one has made it yet
# [18:31] <jgraham> apologies
# [18:31] <Wilto> jgraham: Good question.
# [18:31] <zewt> "+1s" aren't considered much of a factor at all
# [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/
# [18:31] <Wilto> zewt: So, developers cannot simply vote on their own preferences.
# [18:31] <Wilto> zewt: I would _love_ to quote you on that.
# [18:31] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
# [18:31] <jreading> <picture> is too much markup FWIW
# [18:31] <zewt> apis should be based on technical merit, not petitions
# [18:32] <Wilto> Absolutely, zewt. Developer sentiment is a factor only as much as implementor sentiment.
# [18:32] <Wilto> Technical merit is key.
# [18:32] * Joins: gavinc (~gavin@barad-dur.carothers.name)
# [18:32] <gsnedders> The only non-technical thing that matters is usability, and that's more than just first-look opinion.
# [18:32] * Joins: jarib (~jarib@unaffiliated/jarib)
# [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)
# [18:32] <miketaylr> (re: +1, http://wiki.whatwg.org/wiki/FAQ#.2B1)
# [18:32] <Wilto> jgraham: I posted it to the list easlier today, as well.
# [18:33] * Joins: krijn (u2319@gateway/web/irccloud.com/x-uwcbdcwelkyjekca)
# [18:33] * hober catches up again
# [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
# [18:33] <Wilto> Again: posted to the list multiple times.
# [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
# [18:33] <jgraham> scottjehl: Those technical challenges hardly seem insurmountable
# [18:34] * Joins: sedovsek (~robert@93-103-104-107.dynamic.t-2.net)
# [18:34] * Quits: sedovsek (~robert@93-103-104-107.dynamic.t-2.net) (Read error: Connection reset by peer)
# [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
# [18:34] * Quits: Lachy (Lachy@nat/opera/x-anyekuhbgiqyykzk) (Quit: Computer has gone to sleep.)
# [18:34] <hober> adactio: one was the srcset proposal, and one was a "why i don't think <picture> is a good idea" post
# [18:34] <hober> actually, iirc they started out as one email but the second part was getting really long and unweildy and needed editing
# [18:35] <hober> so i split it up
# [18:35] <hober> and didn't actually send any of it because of, err, i have no idea that was a long time ago
# [18:35] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [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
# [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
# [18:35] * Joins: mplehman (~mplehman@71-87-1-124.static.eucl.wi.charter.com)
# [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
# [18:36] <hober> pulled up and sent the srcset email
# [18:36] * Joins: MacTed (~Thud@63.119.36.36)
# [18:36] * Joins: niloy (~niloy@61.12.96.242)
# [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).
# [18:36] <hober> which iirc says that i'll tackle <picture> in another email
# [18:36] <TabAtkins_> There's no syntax that can get around that.
# [18:36] <hober> i just haven't sent that other email yet, because i haven't finished writing it
# [18:38] <adactio> hober: Okay. It's a shame that the excising of your email gave the impression that you were proposing in isolation.
# [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
# [18:38] * Joins: izhak (~izhak@188.168.201.226)
# [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
# [18:39] <jgraham> Since they are quite likely to just forget
# [18:39] <scottjehl> jgraham: sorry, can you clarify?
# [18:40] <jreading> necolas: perhaps there a way to stay DRY with <picture>, but it seems like so much cruft
# [18:40] <scottjehl> hmm. plenty of standard features require careful syntax to bulletproof: @font-face is a good example of success in that
# [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
# [18:41] <scottjehl> jgraham: have you looked at how picturefill works?
# [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?
# [18:42] <scottjehl> I think it addresses your concerns
# [18:42] * Joins: toddmparker_ (u3054@gateway/web/irccloud.com/x-xrohawmublfleceb)
# [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
# [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*
# [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*.
# [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).
# [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.
# [18:44] <hober> adactio: i think you perceive a causal relationship between me sending that email and hixie making his edits
# [18:44] <TabAtkins_> adactio: The CG took care of use-cases. Backwards compat was obvious.
# [18:44] <hober> adactio: that simply isn't there
# [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?
# [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…
# [18:45] <jreading> http://hellowurld.heroku.com/blog/2012/05/15/another-image-proposal-for-responsive-design/
# [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.
# [18:45] <adactio> hober: Okay. I will try to avoid apopheniac interpretations.
# [18:45] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 260 seconds)
# [18:45] * Joins: Guest1064 (~anonymous@87.115.113.220)
# [18:45] <TabAtkins_> jreading: I and others have explained multiple times why MQs are inadequate for solving the multiple-resolution use-case.
# [18:46] <jreading> lowsrc (now obsolete) would prefetch if it came first in the attrs list...
# [18:46] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [18:46] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
# [18:48] <scottjehl> tabatkins: my brief tests show they treat it very differently
# [18:48] * Joins: jsbell (jsbell@nat/google/x-qebgnrehpisxnvsk)
# [18:48] <TabAtkins_> Details?
# [18:49] <bjankord> Aynone have a recent recap, trying to figure out where the discussion is at?
# [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.
# [18:50] <scottjehl> (if no alt text, it spells out "IMAGE")
# [18:50] <hober> adactio: i agree that the impression of work-in-isolation is unfortunate
# [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.
# [18:51] <hober> [whee, only 13 minutes behind :)]
# [18:51] <TabAtkins_> So you'll get the "invalid image" fallback, which varies per browser.
# [18:51] * Joins: pablof (~pablof@144.189.101.1)
# [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.
# [18:52] <hober> adamdbradley: i agree that they are addressing different problems (resolution variation of bitmaps v. affordance for arbitrary design breakpoints)
# [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.
# [18:52] <TabAtkins_> On that point...
# [18:52] <TabAtkins_> Hixie: It might be nice to explicitly include the Responsive Images CG (as a unit) in the acks.
# [18:53] <hober> adactio: for all i know, i *will* be told that when hixie gets around to processing my email. :)
# [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
# [18:53] * Quits: drublic (~drublic@frbg-5d84f2b2.pool.mediaWays.net) (Remote host closed the connection)
# [18:53] <necolas> here we go again
# [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
# [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.
# [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/
# [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.
# [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
# [18:56] <scottjehl> same issue as imgset actually
# [18:56] <Wilto> bjankord: I don’t think we can say for certain that it won’t introduce issues in older browsers.
# [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.
# [18:57] <webben> both <picture> and srcset will result in a redundant request unless the <img> element is wrapped in <noscript>.
# [18:57] <bjankord> Wilto: Agreed
# [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.
# [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.
# [18:59] * Joins: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
# [18:59] <scottjehl> +1
# [18:59] <odinho> bjankord: Polyfills *are* hacks.
# [18:59] * Quits: adamdbradley (4580040a@gateway/web/freenode/ip.69.128.4.10) (Quit: Page closed)
# [18:59] <Wilto> bjankord: Absolutely.
# [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.
# [18:59] <odinho> That's the whole reason for them existing.
# [19:00] <bjankord> odinho: Agreed
# [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.
# [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
# [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?
# [19:00] <odinho> bjankord: So I don't think you can hold that against srcset(!)
# [19:00] <hober> necolas: we should all try to learn from this in order to do better in the future
# [19:01] <Wilto> I second scottjehl’s question.
# [19:01] <necolas> TabAtkins_: as I keep saying, it's not about people not feeling "thanked"
# [19:01] <odinho> scottjehl: Yes. But you have to talk in use cases that are not being met.
# [19:01] * Quits: richw (b0236a65@gateway/web/freenode/ip.176.35.106.101) (Ping timeout: 245 seconds)
# [19:01] <necolas> you're basically not listening, which is part of the problem
# [19:01] <odinho> scottjehl: Or ground it on technical merit.
# [19:01] <hober> necolas: who is "you" in that?
# [19:01] <necolas> tab
# [19:01] <hober> necolas: it seems clear to me that many people are listeningto many other people :)
# [19:01] * Joins: bradee1 (~Adium@sjfw1.adobe.com)
# [19:02] <odinho> hober: English is such a inprecise language :P
# [19:02] <odinho> an*
# [19:02] <odinho> im*
# [19:02] <odinho> lol
# [19:02] <odinho> I kinda blew that, didn't I! :D
# [19:02] <hober> :)
# [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
# [19:02] <Wilto> odinho: Can we quote you as saying that one should simply remove the `src` when creating a polyfill?
# [19:02] <bjankord> necolas: +1
# [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.
# [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. ^_^
# [19:03] <bjankord> odinho: I can test in IE6-IE9 if you need it
# [19:03] <necolas> TabAtkins_: yeah you're wrong. and I think i've already explained that at least 3 times.
# [19:03] <Wilto> odinho: Cool. We’re agreed that we can’t guarantee backwards compatibility with the removal of the src, right?
# [19:04] <Wilto> If that’s the official stance coming out of the WHATWG, I’m happy to pass that information around.
# [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.
# [19:04] <TabAtkins_> Wilto: Wait wait wait. Clarification.
# [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.
# [19:04] <bjankord> Shit, can't read this fast
# [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.
# [19:05] <hober> Wilto: what's "an official stance coming out of the WHATWG"? that's not how things work around here...
# [19:05] <TabAtkins_> Wilto: At least until the polyfill comes along and fixes it.
# [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.
# [19:05] <TabAtkins_> Wilto: Alternately, you can do something like use a data: url for a 0x0 image.
# [19:06] <TabAtkins_> Wilto: But that seems like more work than necessary.
# [19:06] * Quits: pablof (~pablof@144.189.101.1) (Read error: Connection reset by peer)
# [19:06] <bjankord> TabAtkins_: How does the polyfill handle users without JS
# [19:06] * Joins: pablof (~pablof@144.189.101.1)
# [19:06] <TabAtkins_> bjankord: polyfills *don't* handle users without JS. That's the point.
# [19:06] <bjankord> This is something scottjehl's picturefill is capable of
# [19:06] * Joins: tomasf (~tom@c-dedbe555.024-204-6c6b7012.cust.bredbandsbolaget.se)
# [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.
# [19:06] <TabAtkins_> There are unavoidable tradeoffs.
# [19:07] <webben> or use noscript
# [19:07] <Wilto> TabAtkins_: That’s hardly a _rule_. Better polyfills certainly do.
# [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.
# [19:07] <mdelcx> is the prevailing opinion still that the <picture> tag is optimal?
# [19:07] <scottjehl> picture/picturefill avoids that
# [19:07] <scottjehl> and it's a huge concern
# [19:07] <Wilto> mdelcx: From the developer community, yes.
# [19:07] <odinho> How do you turn off js in chrome?
# [19:07] * Joins: grigs (~jason@67.131.102.78)
# [19:07] <bjankord> adactio: +1 +1 +1
# [19:07] <mdelcx> imset is a non-starter for me... poor spec
# [19:07] <Wilto> Agreed with adactio.
# [19:07] <webben> scottjehl: Avoids which?
# [19:07] <mdelcx> IMO, of course
# [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.
# [19:08] <bjankord> odinho: Google it
# [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.
# [19:08] * Joins: sarspazam (~sarspazam@78-105-183-7.zone3.bethere.co.uk)
# [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.
# [19:08] <TabAtkins_> scottjehl: No, <picture> doesn't really avoid it.
# [19:08] <scottjehl> I have a test page
# [19:08] <bjankord> TabAtkins_: Can you elaborate?
# [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">.
# [19:09] <scottjehl> but without any http overhead
# [19:09] <scottjehl> http://scottjehl.github.com/picturefill/
# [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."
# [19:10] <TabAtkins_> adactio: Let me repeat the last three sentences of that.
# [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
# [19:10] <TabAtkins_> Am I wrong? If so, can you explain it to me better? I've been trying all mornign to understand.
# [19:10] <bjankord> Has any discussion been made here on meta media variables. https://gist.github.com/2702067
# [19:10] <scottjehl> btw that markup is purposely verbose to illustrate different queries. more than a real scenario in my experience
# [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.
# [19:10] <bjankord> It seems one of Hixie's issues with <picture> is how verbose it can get
# [19:11] <scottjehl> of course that's a goal. that's every browser that exists today.
# [19:11] <TabAtkins_> necolas: So what, precisely, of Hixie's email wasnt' sufficient?
# [19:11] <Wilto> TabAtkins_: So help me, you can’t possibly be struggling to understand our line here.
# [19:11] <bjankord> Wilto: +1 seriously
# [19:11] <Wilto> TabAtkins_: Obviously this isn’t about ego. I can’t tell if this is misdirection or just condescention.
# [19:12] <webben> scottjehl: None of those browser versions will be significant in 5 years time.
# [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.
# [19:12] <Wilto> For our part: it’s about technical merit, and has been.
# [19:12] <scottjehl> webben: this is a feature we need yesterday
# [19:12] <Wilto> TabAtkins_: My feedback was ignored.
# [19:12] <Wilto> TabAtkins_: Or shut down with “please prove it.”
# [19:12] <Wilto> Which I have.
# [19:12] <TabAtkins_> Wilto: omigod please get stories straight. Your line cannot be squared with necolas'.
# [19:12] <webben> scottjehl: And srcset can't be fully imitated (because media queries don't tell you what the UA needs)
# [19:12] <Wilto> Meanwhile, a solution made it into the spec.
# [19:12] <hober> who ignored whose feedback?
# [19:12] <Wilto> This is a waste of everyone’s time.
# [19:12] <webben> scottjehl: But you _can_ imitate it (poorly) if you want to, using <picture> or @srcset.
# [19:12] <hober> the passive voice is not helping with clarity :)
# [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.
# [19:12] <TabAtkins_> Agreed, unfortuantely. ;_;
# [19:13] <Wilto> You all, as representatives of the WHATWG, are obviously digging in your heels.
# [19:13] <TabAtkins_> tkadlec: Again, was it technical, or was it communication? If it's communication, *nobody will care* in a year.
# [19:13] <scottjehl> Sigh.
# [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
# [19:13] <scottjehl> 's not how I imagined this process worked.
# [19:13] <Wilto> So I suppose all that’s left is to publicize your reasonings, to the best we can sort them out.
# [19:13] * Joins: tantek (~tantek@50-1-62-23.dsl.dynamic.sonic.net)
# [19:13] <TabAtkins_> AGHIO3IPO.
# [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
# [19:13] <webben> scottjehl: "after the fact": after what fact?
# [19:13] <necolas> TabAtkins_: there are 2 different things here, which can be squared.
# [19:14] <webben> scottjehl: The WHATWG spec follows a commit-then-review process.
# [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
# [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".
# [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)
# [19:14] <webben> scottjehl: Just because @srcset is there today does not mean it's there tomorrow.
# [19:14] <zewt> (You're right, I'm not too happy with how Wilto talks to all of us)
# [19:14] <TabAtkins_> Either I have *no idea* what definitions you are using for those words, or someone else is sending mixed messages.
# [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...
# [19:15] <Wilto> zewt: I assumed condescension was the established tone here, based on how I’ve been received.
# [19:15] <TabAtkins_> Philip`: Ah, kk. Well, same effect in the end here.
# [19:15] <necolas> TabAtkins_: being personal is different to adequate communication
# [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.
# [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.
# [19:15] <hober> what gsnedders said.
# [19:15] <gsnedders> scottjehl: That fact there's now something in the spec changes little.
# [19:15] <zewt> you're the only one that's been condescending and, well, frankly rather obnoxious; it's pretty uncommon here
# [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.
# [19:16] <Philip`> TabAtkins_: (...but I think some browsers do still resolve the empty string, at least for an explicit src="")
# [19:16] <beverloo> Being a proponent of <picture> myself, I can see that being frustrating.
# [19:16] <necolas> 2. The other issue is related to the details of the technical proposals. Different issues.
# [19:16] <TabAtkins_> beverloo: But omigod the solution was *based* on the month+ of feedback on the issue.
# [19:16] <TabAtkins_> al;skjdf;als
# [19:16] <beverloo> TabAtkins, I get it, I get it
# [19:16] <bjankord> beverloo: exactly
# [19:16] <beverloo> just emphasizing
# [19:16] <TabAtkins_> beverloo: I don't. ;_
# [19:16] <beverloo> flip tables.
# [19:16] <Wilto> beverloo: It’s not even that no one reached out to us.
# [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.
# [19:17] <Wilto> I reached out to the WHATWG, representing the CG.
# [19:17] <bjankord> So much time and effort was put into the CG
# [19:17] <Wilto> And was asked to furnish proof of `picture`s merit, which was summarily dismissed.
# [19:17] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
# [19:17] <Wilto> Over the course of four days.
# [19:18] <bjankord> How can it not be clear our frustration TabAtkins?
# [19:18] <TabAtkins_> Wilto: It. Was. Not. Dismissed. That proposal was found wanting for reasons which were stated in the email.
# [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.
# [19:19] <jreading> Tab: is there a summary of the "MQs dont' work for multi-res negotiation"?
# [19:19] <bjankord> multi-res negotiation, you mean min-device-pixel-ration?
# [19:19] <TabAtkins_> Having your suggestion rejected is *not* the same as having your feedback dismissed.
# [19:19] <TabAtkins_> jreading: yes. I can illustrate it best with a real-world example.
# [19:19] <TabAtkins_> Assume for a moment that there was a bandwidth MQ.
# [19:19] <annevk> bjankord: yes, you can query the ratio, but you do not set it for the resource
# [19:19] <bjankord> There are device-pixel-ratio media queries to handle various resolution displays
# [19:20] * gwicke_away is now known as gwicke
# [19:20] <webben> Wilto: Not sure why you think four days is an unreasonable time for evaluating a technical proposal.
# [19:20] <annevk> bjankord: and you need to set it, because otherwise your image will be displayed four times as large
# [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.
# [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
# [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.
# [19:20] <Wilto> webben: Because it makes it clear that all this discussion was going on _while_ it was specced.
# [19:20] <Wilto> Not before.
# [19:21] <annevk> this discussion has been going on forever
# [19:21] <annevk> since 2007
# [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.
# [19:21] <necolas> and it's no less depressing
# [19:21] <TabAtkins_> This is, obviously, a bad situation.
# [19:21] * Joins: jtwalters (~jtwalters@c-50-132-87-187.hsd1.wa.comcast.net)
# [19:21] * Joins: erichynds (~ehynds@64.206.121.41)
# [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.
# [19:22] <bjankord> So because bandwidth media queries are a bad situation for serving images, the picture element was disregarded?
# [19:22] <Wilto> bjankord: I did get that impression several times.
# [19:22] <bjankord> You've got to be shitting me
# [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.
# [19:22] <TabAtkins_> bjankord: Well, because of that, any solution that relied solely on MQ was disregarded. Because it's a bad solution..
# [19:22] <jreading> Tab: I get that, but I would argue that bandwidth MQ's a re bad spec as well
# [19:22] <odinho> bjankord: Because media queries is not the way to solve it.
# [19:22] <jreading> esp. considering latency is more of an issue than bandwdith
# [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.
# [19:23] <webben> Wilto: Why is it a problem if people produce alternate proposals while evaluating a proposal?
# [19:23] <Wilto> bjankord: Which I posted to the WHATWG wiki, and linked in the mailing list twice.
# [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.
# [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
# [19:23] <miketaylr> what about zooming in on a page, from your desktop? the low-res/mobile image MQ will be triggered.
# [19:23] <jreading> so because of bandwidth MQ, MQ are bad… makes no sense
# [19:23] <odinho> Wilto: Then it's another proposal. Right now we're taking about the flexible image resolutions.
# [19:23] <Wilto> miketaylr: Not when using ems.
# [19:23] <scottjehl> or doesn't yet work anyway...
# [19:23] <miketaylr> Wilto: ORLY
# [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.
# [19:24] <Wilto> It’s worth noting the the specced solution seems to be fully pixel dependent. Is that correct?
# [19:24] <TabAtkins_> Because that means, by definition, that it's not solving an important use-case.
# [19:24] <Wilto> As no detailed use cases have been published, we don’t know.
# [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/
# [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
# [19:24] <hober> miketaylr: :)
# [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.
# [19:25] <beverloo> there's other issues with that, though
# [19:25] <gsnedders> Wilto: What use-cases does it fail to fulfil on the discussion on the mailing list?
# [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?
# [19:25] <Wilto> miketaylr, hober: <3 ems.
# [19:25] <beverloo> I'm not sure whether I agree with a bandwidth MQ at all, actually
# [19:25] <beverloo> it'd be based on estimates
# [19:25] <Wilto> gsnedders: The one I just mentioned.
# [19:25] <beverloo> "wifi" can be significantly slower than "3g"
# [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.
# [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"
# [19:26] <Wilto> I’m not sure we’re all on the original topic anymore.
# [19:26] <TabAtkins_> Yes, the Network Info API is *really* flawed.
# [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)?
# [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.
# [19:26] <Wilto> beverloo: It seems so.
# [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.
# [19:27] <beverloo> odinho, yes, I'm aware of that (I'm on the Chrome on Android team)
# [19:27] <Wilto> beverloo: Android Chrome! You do yeoman’s work, beverloo.
# [19:27] * jernoble|afk is now known as jernoble
# [19:28] <bjankord> TabAtkins_: If the Network Information API is flawed, why have Chrome and Firefox added support for it?
# [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.
# [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
# [19:28] <TabAtkins_> bjankord: Because it's in a spec.
# [19:28] <odinho> beverloo: You obviously knew something about it, just wanted to back you up by extra data point :-)
# [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.
# [19:28] <TabAtkins_> beverloo: heuristics are fine. the *real* problem is statefulness, which MQ can't provide.
# [19:28] <Wilto> TabAtkins_: I’d prefer to see more information on the specced solution posted publicly.
# [19:28] <beverloo> TabAtkins, changing a mobile device's orientation will influence the width
# [19:28] <Wilto> You don’t have to convince me; the developer community will need citations.
# [19:28] <bjankord> ShaneHudson: +1
# [19:28] <beverloo> potentially causing the same problem
# [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.
# [19:29] * Joins: jamesr_ (jamesr@nat/google/x-rlvvpxuvwmcoskmv)
# [19:29] <Wilto> TabAtkins_: Sure. Sum up for me, real quick.
# [19:29] <Wilto> The community will want an easy-to-digest reasoning.
# [19:29] <annevk> beverloo: so does resizing the browser window on desktop
# [19:29] <TabAtkins_> I explained *literally* a screen or so ago, to jreading.
# [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.
# [19:29] <beverloo> annevk, TabAtkins, so neither solution is really stateful
# [19:29] <odinho> beverloo: MediaQueries can't do that.
# [19:30] <TabAtkins_> beverloo: Yeah, I think that Hixie's proposal is somewhat flawed because of that.
# [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.
# [19:30] <Wilto> TabAtkins_: It seemed like you were discussing bandwidth MQ.
# [19:30] <beverloo> odinho, absolutely, the heuristics would be much more accurate than what a user can do
# [19:30] <annevk> beverloo: one solution describes the resource, the other queries the device and selects a resource based on that
# [19:30] <annevk> beverloo: you need the former for e.g. pixel density stuff
# [19:30] <TabAtkins_> Wilto: I was explainign why you can't do bandwidth MQ, yes. And that's why MQ-based solutions are bad.
# [19:31] <bjankord> Tab: What solution do you suggest?
# [19:31] <Wilto> So, neither of these solutions will use hard-coded bandwidth detection, is that correct?
# [19:31] <odinho> TabAtkins_: I think that too. A bounding box. Did I write that on mailing list, or only here?
# [19:31] <beverloo> TabAtkins, issue there is that websites may present different versions based on the orientation (again due to MQs)
# [19:31] <Wilto> TabAtkins_: ^
# [19:31] <TabAtkins_> bjankord: For what? The general problem?
# [19:31] <Wilto> Nothing inline, in the markup, I mean.
# [19:31] <TabAtkins_> odinho: I think it was you suggesting that, here in the chatroom.
# [19:31] * jonlee|afk is now known as jonlee
# [19:31] <jreading> bandwidth MQ are bad
# [19:31] <beverloo> TabAtkins, for which you may want a different picture too.
# [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?
# [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
# [19:31] <TabAtkins_> beverloo: Eh, true. Welp, whatever.
# [19:32] * Quits: pablof (~pablof@144.189.101.1) (Remote host closed the connection)
# [19:32] <Wilto> TabAtkins_: If neither is using an attribute that detects bandwidth, I’m not sure why we’re still talking about it.
# [19:32] <Wilto> I agree that it’s a flawed idea.
# [19:32] <bjankord> Agreed
# [19:32] <Wilto> On both markup patterns.
# [19:32] <Wilto> Let’s move on.
# [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)
# [19:32] <Wilto> Apart from _theoretical_ media queries, that is.
# [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.
# [19:32] * Joins: pablof (~pablof@144.189.101.1)
# [19:32] <annevk> beverloo: polling for the DPI is not enough
# [19:32] <annevk> beverloo: you need to set it
# [19:33] <Wilto> TabAtkins_: And the specced pattern does not, then?
# [19:33] <annevk> beverloo: because otherwise the image will be displayed four times the size
# [19:33] <Wilto> It incorporates bandwidth in a meaningful way?
# [19:33] <TabAtkins_> Wilto: Wait, have you read the specced proposal?
# [19:33] <beverloo> annevk, got you
# [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.
# [19:33] <beverloo> annevk, thanks :)
# [19:33] <zewt> TabAtkins: well, you also need to tell it the image's size (even if it's only a hint)
# [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.
# [19:33] <annevk> beverloo: I'm somewhat surprised everyone thinks MQ magically solve that...
# [19:33] <zewt> file size, I mean
# [19:34] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
# [19:34] <TabAtkins_> zewt: Filesize *should* correspond to the Nx multiplier you give.
# [19:34] <webben> zewt: Yeah. I'm inclined to suggest srcset should include HxW (always) and would benefit form size.
# [19:34] <webben> TabAtkins_: Doesn't that depend on e.g. jpeg quality?
# [19:34] <beverloo> annevk, let's make a new image format containing the target DPI!
# [19:34] <zewt> TabAtkins: you can also have multiple images at the same resolution with eg. different jpeg compression ratios
# [19:34] * beverloo runs
# [19:34] <TabAtkins_> zewt: Unless you're being perverse and providing different-sized images for different resolutions.
# [19:35] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
# [19:35] <TabAtkins_> Yeah, compression ratio is somewhat harder to deal with, particularly since it's so format-specific.
# [19:35] * hober mumbles something about jpeg2000
# [19:35] <TabAtkins_> I think by the time you're dealing with that, you should just go res-independent.
# [19:35] <bjankord> We could sit here all day discussing pros and cons of each solution, yet still get no where...
# [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*
# [19:35] <annevk> beverloo: you mean one that browsers are not forced to ignore?
# [19:36] <zewt> TabAtkins: also, file size doesn't change linearly with resolution
# [19:36] <zewt> not always, anyway
# [19:36] <beverloo> annevk, odinho, yup.
# [19:36] <grigs> Wow, lot's of conversation. Took forever to catch up. A couple of quick notes.
# [19:37] * Joins: nicksergeant (~Nick@74.112.37.250)
# [19:37] <bjankord> grigs: yes, there is a lot to digest here
# [19:37] <tantek> TabAtkins - re: "just go res-independent", let me know when you know of cameras that output SVG photographs :p
# [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.
# [19:37] * Joins: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net)
# [19:37] <annevk> beverloo: good luck with that :)
# [19:38] <beverloo> annevk, :D
# [19:38] <TabAtkins_> zewt: Yeah, it's not a perfect fit. But I suspect it's probably a good enough approximation.
# [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.
# [19:38] <annevk> grigs: pointer for that? I asked before but never got it
# [19:39] <ShaneHudson> It should be in a community group anyway, it is the kind of thing the community should have input on
# [19:39] <grigs> @annevk I'll dig it up.
# [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
# [19:40] * Joins: sicking (~chatzilla@nat/mozilla/x-lvqdtqihpcubzkhh)
# [19:40] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Quit: Leaving)
# [19:40] <annevk> ShaneHudson: WHATWG is a community developing HTML
# [19:41] <annevk> ShaneHudson: no need for subgroups in the past eight years
# [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
# [19:41] <grigs> annevk: original objection to the conversation on the list http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034775.html
# [19:41] * Joins: Adam_ (42b54b7f@gateway/web/freenode/ip.66.181.75.127)
# [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.
# [19:41] <TabAtkins_> (Or, as people have said, you're printing, or saving, etc.)
# [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 ;-) )
# [19:42] <annevk> grigs: interesting, I don't know who that is
# [19:42] * Quits: necolas (~necolas@80.231.76.54) (Remote host closed the connection)
# [19:42] <TabAtkins_> zewt: Within a particular resolution level, jpeg quality might be useful, but I think it's a much smaller concern.
# [19:42] <grigs> annevk: still looking for the specific suggestion that we take it to a community group.
# [19:42] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 264 seconds)
# [19:42] * Joins: necolas (~necolas@80.231.76.54)
# [19:42] <TabAtkins_> Huh. I have also never heard of this Ronjek guy.
# [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
# [19:43] * Joins: cheron (~cheron@unaffiliated/cheron)
# [19:43] <annevk> grigs: the list has 1500 people so if one person tells you something that doesn't mean it's definitive
# [19:43] <zewt> at least for that (isolated, off-the-top-of-my-head) case, it's almost always the better choice
# [19:43] * Parts: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [19:43] <annevk> grigs: thanks
# [19:43] <tkadlec> grigs: I believe here? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html
# [19:43] <annevk> i have to go now
# [19:43] <grigs> annevk: I get that. To me, that’s the frustrating part.
# [19:43] <divya> annevk: you are just being defensive here. ultimately who do we consider as the 'voice'?
# [19:44] <divya> if we mention to hixie
# [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
# [19:44] <divya> thats not enough
# [19:44] <divya> if we mention here
# [19:44] <divya> thats not enough
# [19:44] <divya> if we mention on mailing list its not enough
# [19:44] * Quits: myakura (~myakura@FL1-211-135-237-201.tky.mesh.ad.jp) (Remote host closed the connection)
# [19:44] <divya> when is it enough?
# [19:44] * Joins: scottkellum (~scottkell@rrcs-50-74-240-194.nyc.biz.rr.com)
# [19:44] <annevk> divya: not sure what you're saying
# [19:44] <annevk> but I have to go watch a movie
# [19:44] <grigs> tkadlec: thanks, that's the link
# [19:44] <grigs> annevk: enjoy!
# [19:44] <webben> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html seems relevant.
# [19:44] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [19:45] * Joins: chazcross (ad0a2166@gateway/web/freenode/ip.173.10.33.102)
# [19:45] <grigs> webben: yep.
# [19:45] * Joins: jacobrask (~jacob@jacobrask.net)
# [19:45] * Joins: stalled (~stalled@unaffiliated/stalled)
# [19:46] <webben> divya: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F
# [19:46] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
# [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).
# [19:46] <zewt> TabAtkins: i'd just include the file size by itself
# [19:47] * Quits: necolas (~necolas@80.231.76.54) (Ping timeout: 252 seconds)
# [19:47] <TabAtkins_> Ah, yeah, that's valid.
# [19:47] <TabAtkins_> Hixie mentions that in a response on the latest thread.
# [19:47] <zewt> that would make the assumption that all available options are in the same or comparable compression types, which is probably reasonable
# [19:47] <divya> webben: all of it was done.
# [19:48] <divya> hober: it would have been nice when you proposed the solution why you decided it over picture
# [19:48] <divya> hober: it seems like the whole work was summarily dismissed even though now it looks like it wasnt
# [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.
# [19:49] <webben> divya: The WHATWG as an organization speaks only for administrative reasons basically.
# [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
# [19:50] * Quits: Adam_ (42b54b7f@gateway/web/freenode/ip.66.181.75.127) (Quit: Page closed)
# [19:50] <divya> jgraham: i actually am not attached to any one solution
# [19:50] <divya> i suspect none of the people are
# [19:51] <divya> jgraham: only concern is the unreadable syntax that srcset proposes
# [19:51] <divya> and the other concerns that scottjehl raises
# [19:51] <grigs> divya: +1
# [19:51] <divya> jgraham: we know people will go wrong
# [19:51] <divya> jgraham: i think having an easy to understand solution would make it less difficult to go wrong
# [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.
# [19:52] * Joins: chippper (627ca660@gateway/web/freenode/ip.98.124.166.96)
# [19:52] <grigs> not trying to be difficult here, but will readily acknowledge I may be dense. ;-)
# [19:53] <divya> just because the GCD is stupid
# [19:53] <jgraham> divya: hmm i don't think I said you were. Just sharing some "thinking" from the bus ride home
# [19:53] <grigs> divya: GCD?
# [19:53] <divya> Greatest common denominator :)))
# [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
# [19:53] * Joins: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202)
# [19:54] <divya> doesnt mean we should just do whatever is the most easy for implementors.
# [19:54] <divya> jgraham: ya ya i am just ranting
# [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.
# [19:54] <jgraham> paul_irish: There is: don't use new elements before they are implemented; for things with no implementation use data- attributes
# [19:54] <divya> jgraham: i am yet to come across a polyfill problem
# [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
# [19:55] <divya> jgraham: is there one?
# [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
# [19:56] <paul_irish> <x-picture> is the equivalent. it could work effectively the same from the polyfill side.
# [19:57] <jgraham> Yeah, but inventing elements is non-conforming and highly controversial
# [19:57] <divya> jgraham: like we havent been doing that for eons :P
# [19:57] <jgraham> divya: How many things *that no browser implements*?
# [19:57] <scottjehl> jgraham: the polyfill would of course be updated to match implementation
# [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
# [19:57] <divya> jgraham: severalll
# [19:57] <jgraham> scottjehl: But existing sites would break
# [19:58] <divya> HOW ABOUT HGROUP
# [19:58] * jgraham -> food
# [19:58] <divya> kk bai
# [19:59] * Joins: adactio (~adactio@cust217-dsl91-135-3.idnet.net)
# [20:00] * Quits: mplehman (~mplehman@71-87-1-124.static.eucl.wi.charter.com) (Remote host closed the connection)
# [20:00] <jreading> there.must.be.a.better.way
# [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
# [20:02] <jreading> variablize the MQ's in <picture> (like my blog post) and be more DRY
# [20:03] * Quits: pyrsmk (~pyrsmk@202.182.141.88.rev.sfr.net) (Ping timeout: 244 seconds)
# [20:04] * Joins: danielfilho (~daniel@187.31.77.7)
# [20:04] <paul_irish> jgraham: speaking of changing implementations, that spec changed. :p
# [20:04] <paul_irish> oops. jreading, rather.
# [20:04] <odinho> I've written a polyfill for srcset now.
# [20:05] <zewt> hey, i've been using gmail for years and I finally figured out how to extend a damned quote block
# [20:05] <odinho> To see it could be done. But, yes, it does have some problems at edge cases.
# [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
# [20:06] * Joins: kevinSuttle (4a88c1a4@gateway/web/freenode/ip.74.136.193.164)
# [20:06] * Quits: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
# [20:06] <scottjehl> odhino: link?
# [20:06] <odinho> scottjehl: Yeah, I need someone to test it in IE :P
# [20:07] <scottjehl> ...and loads of mobile devices
# [20:08] <scottjehl> so what's next for picture element supporters? is there anywhere worthwhile to direct our existing and ongoing efforts?
# [20:08] * Quits: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202) (Quit: Page closed)
# [20:08] <divya> scottjehl: i am not sure if we should be so affiliated to pic element
# [20:08] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
# [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
# [20:09] * Quits: TabAtkins_ (~jackalmag@50-0-151-4.dsl.dynamic.sonic.net) (Ping timeout: 244 seconds)
# [20:09] <scottjehl> divya, what do you mean?
# [20:09] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
# [20:10] * Joins: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net)
# [20:10] <grigs> scottjehl: i'm still trying to definitely figure out if srcset addresses one of the core use cases.
# [20:10] <divya> scottjehl: i am saying we shouldnt be attached to a syntax
# [20:10] <divya> its okay as long as we find a solution that works for implementors and devs alike
# [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.
# [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?
# [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)
# [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
# [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 :-)
# [20:13] <grigs> tantek: exactly
# [20:13] * Joins: eberon_ (~eberon@angilas.ur.northwestern.edu)
# [20:13] * tantek agrees with Philip - why jumping straight to pro/anti any specific syntax?
# [20:13] * tantek has yet to see any consensus on which use-cases matter and why.
# [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.
# [20:14] * Joins: greenplastic (~anonymous@71-87-1-124.static.eucl.wi.charter.com)
# [20:14] <grigs> tantek: amen!
# [20:14] <tantek> grigs - I'm looking at the folks proposing <picture> as well
# [20:14] <grigs> tantek: OH I KNOW
# [20:14] <grigs> :-)
# [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.
# [20:15] <tantek> until you show your work, I'm not buying the proof (proposal)
# [20:15] <grigs> same true for srcset as well then, eh?
# [20:16] <tantek> grigs - of course
# [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.
# [20:17] <tantek> odinho - that's bass-ackwards
# [20:17] <tantek> "align much more with srcset's use cases"
# [20:17] <grigs> i do think there's a lot of that going on though.
# [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.
# [20:17] <jgraham> tantek: Not if you are charitable
# [20:17] * Quits: espadrine (~thaddee_t@nat/mozilla/x-dgdzmbmmirpyrvqw) (Quit: espadrine)
# [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 )
# [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.
# [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.
# [20:18] <tantek> group/community specific wikis are a bit of a silo-iziation/tribalization and not useful for broadening consensus (actually harmful)
# [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>"
# [20:19] <grigs> jgraham: that's the way I read it.
# [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.
# [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.
# [20:20] <tantek> odinho - except it's not editable
# [20:20] <tantek> hence: "put them on a *generally* accessible/usable wiki (e.g. w3.org/wiki/ or wiki.whatwg.org )"
# [20:20] <tantek> give them their own sections so you can link to them
# [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?
# [20:20] * Joins: brucel (~brucel@cpc5-smal11-2-0-cust151.perr.cable.virginmedia.com)
# [20:21] <tantek> example: http://wiki.whatwg.org/wiki/Time_element
# [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.
# [20:21] <tantek> ShaneHudson - yes, wiki please
# [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.
# [20:21] <tantek> that way we can iterate on them in one place
# [20:21] <scottjehl> grigs +1
# [20:21] <tantek> rather than go round-round in the support forums known as "mailing lists"
# [20:21] <tkadlec> grigs: +1
# [20:22] * Joins: akselkreis (~Adium@rrcs-50-75-52-51.nys.biz.rr.com)
# [20:22] <jgraham> tantek: Characterising the whatwg list as a "support forum" is just inaccurate
# [20:22] <tantek> grigs - what part of "document use-cases on the wiki" was not communicated?:
# [20:22] <ShaneHudson> http://wiki.whatwg.org/wiki/Adaptive_images Has everyone seen that page?
# [20:22] <jgraham> Although I agree that using the wiki in this case might be useful
# [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.
# [20:23] <Wilto> tantek: Just tuning back in, but you saw this, yeah? http://wiki.whatwg.org/wiki/Adaptive_images
# [20:23] <Wilto> I posted it to the list a couple of times.
# [20:23] * Joins: rdebeasi (ada04aae@gateway/web/freenode/ip.173.160.74.174)
# [20:23] <jgraham> Wilto: That still has proposed solutions listed under "use cases"
# [20:23] <ShaneHudson> grigs: I agree. For new members at least, it is pretty caotic!
# [20:23] <tantek> Wilto - problem with that wiki page is that it is already assuming <picture> as syntax
# [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.
# [20:23] <tantek> so you're not going to get people to read past that
# [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/
# [20:24] <grigs> odinho: how the hell were we supposed to know that? :-)
# [20:24] * Joins: J_Voracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com)
# [20:24] <ShaneHudson> Okay, lets make a new page.
# [20:24] * Joins: TabAtkins_ (jackalmage@50-0-151-4.dsl.dynamic.sonic.net)
# [20:24] * Quits: J_Voracek (~J_Voracek@cpe-76-184-40-47.tx.res.rr.com) (Client Quit)
# [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.
# [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.
# [20:24] <Wilto> That’s helpful, tantek. We can put up a page more along those lines, if that’ll help.
# [20:24] <tantek> all email lists eventually devolve into support forums
# [20:24] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
# [20:25] <TabAtkins_> grigs: That was misinterpreted, unfortunately. Modifying <img> to have *children* is a non-starter. Adding attrs is always okay.
# [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.
# [20:25] <jgraham> grigs: That was a misunderstanding about what "modify" meant
# [20:25] <tantek> actual design happens in smaller / quicker fora like IRC, with anything of any substance being documented on the web (wiki pages)
# [20:25] <tantek> the whatwg list *appears* to work only because Hixie treats it as his inbox.
# [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
# [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.
# [20:26] <tantek> no, I'm just concluding from the vast majority of email that gets to sent to the whatwg list
# [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
# [20:26] <tantek> sure reads like a support forum
# [20:26] <jgraham> You must be reading a very different list to me
# [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
# [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.
# [20:27] <odinho> grigs: It was not like that last time.
# [20:27] <ShaneHudson> How do we register for this wiki? Says I have to be an admin to register...
# [20:27] <Philip`> ShaneHudson: Many things would be much easier if we could ignore reality :-)
# [20:27] <grigs> odinho: Actually, no, we don’t seem to agree on use cases (which was tantek's earlier point).
# [20:27] <tantek> ShaneHudson - any W3C account can sign into w3.org/wiki
# [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.
# [20:28] <ShaneHudson> tantek: Ah, so not wiki.whatwg? Ok
# [20:28] <jgraham> ShaneHudson: The whatwg wiki?
# [20:28] <jgraham> Uh Hixie is an admin, maybe annevk, AryehGregor perhaps
# [20:28] <grigs> odinho: happy you agree, not clear everyone else does (again tantek's point)
# [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.
# [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.
# [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.
# [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. :-)
# [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.
# [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…
# [20:30] <tantek> jreading - a good solution to *what use-cases*?
# [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.
# [20:30] <ShaneHudson> Right I am going to grab dinner. Does anyone disagree with the wiki page being http://www.w3.org/wiki/Images ?
# [20:30] * Joins: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net)
# [20:30] <tantek> ShaneHudson - go ahead and start it. we can rename/move later if needed.
# [20:31] * Parts: scottkellum (~scottkell@rrcs-50-74-240-194.nyc.biz.rr.com)
# [20:31] <jreading> is their a github of use cases that I can submit pull requests?
# [20:31] <tantek> jreading - wiki editing is easier / more usable/accessible that git for documentation/text
# [20:31] <zewt> let's make discussing a feature as complicated as possible
# [20:31] <ShaneHudson> jgraham: Use the wiki I just linked to.. I will be creating the page after dinner
# [20:32] <tantek> just created it as a stub ;)
# [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
# [20:32] <jgraham> That doesn't follow the general layout of the W3C wiki
# [20:33] <jgraham> But I don't really care
# [20:33] <Wilto> jreading: I started a repo here a while back: https://github.com/Wilto/respimg
# [20:33] <jgraham> (I think the WhatWG wiki would be better since it doesn't require W3C Member access)
# [20:33] <Wilto> jreading: The WHATWG wiki page is more thorough, though.
# [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.
# [20:34] * gwicke is now known as gwicke_away
# [20:34] <grigs> TabAtkins_: not my point. seriously.
# [20:34] <tantek> TabAtkins indeed.
# [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.
# [20:34] * Joins: PendragonDev (~IceChat77@ip-64-134-189-67.public.wayport.net)
# [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.
# [20:35] <tantek> good design must be based on referenceable real world use cases
# [20:35] <odinho> TabAtkins_: And sunken cost-less!
# [20:35] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Remote host closed the connection)
# [20:35] <TabAtkins_> odinho: Yeah.
# [20:36] * Joins: necolas (~necolas@5ade1e67.bb.sky.com)
# [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
# [20:37] <tantek> s/below/above
# [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.
# [20:38] <tantek> grigs - time is usually most wasted on email lists / support forums.
# [20:38] * Joins: rpflo (~rpflo@216.51.73.6)
# [20:39] * Quits: chazcross (ad0a2166@gateway/web/freenode/ip.173.10.33.102) (Quit: Page closed)
# [20:39] <ShaneHudson> tantek: Thank you :) I have not written anything quite like this before so anyone feel free to help and suggest improvements
# [20:39] <ShaneHudson> Will get started on it in about 30 mins, not cooked dinner yet
# [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.
# [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).
# [20:41] <tantek> point being, not all the use-cases were satisfied, that's OK.
# [20:41] <grigs> anyways, for next time, it would be nice to have something a little clearer for outsiders. which was my original point. :-)
# [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
# [20:42] <TabAtkins_> grigs: Ah, sure. Yeah, standards is hard.
# [20:42] <grigs> any disagreement with that?
# [20:42] * Joins: davatron5000 (~dave@cpe-66-25-175-141.austin.res.rr.com)
# [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.
# [20:42] <TabAtkins_> Everything else is details.
# [20:43] * Joins: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
# [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.
# [20:43] * Parts: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
# [20:43] * Joins: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com)
# [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.
# [20:46] * Joins: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42)
# [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.
# [20:47] * Joins: drublic (~drublic@frbg-5f73366a.pool.mediaWays.net)
# [20:47] <grigs> tantek: would replacing "outsiders" with "people new to the whatwg standards process" be sufficient? i think we're just talking semantics.
# [20:47] <tantek> outsiders just means anyone not editing the spec ;)
# [20:47] * Joins: yodasw16 (~dgillhesp@ql1fwhide.rockfin.com)
# [20:48] <adactio> grigs: What do you mean exactly by "semantics?" ;-)
# [20:48] <tantek> adactio LOL
# [20:48] <grigs> adactio: LOL
# [20:48] <grigs> https://twitter.com/#!/adactio/status/197343204683694080
# [20:49] <grigs> I’ve got that tweet favorited.
# [20:49] <zewt> so many quotostrophes
# [20:49] * Quits: maikmerten (~maikmerte@port-92-201-49-70.dynamic.qsc.de) (Remote host closed the connection)
# [20:49] * Parts: rpflo (~rpflo@216.51.73.6)
# [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.
# [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
# [20:53] * Joins: necolas_ (~necolas@80.231.76.54)
# [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.
# [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
# [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)
# [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)
# [20:54] <grigs> zewt: blame the tool makers, not the CG users.
# [20:54] <tantek> grigs - from my understanding the recommendation to document persuasive use-cases is quite prevalent
# [20:54] <tantek> \
# [20:55] * Joins: nick_evans (~nicholas@static-98-113-167-42.nycmny.fios.verizon.net)
# [20:55] <tantek> e.g. http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
# [20:55] <tantek> steps 1 and 2
# [20:55] <tantek> 1. Research the use cases and requirements by discussing the issue with authors and implementors.
# [20:55] <tantek> 2. Come up with a clear description of the problem that needs to be solved
# [20:55] * Quits: TabAtkins_ (jackalmage@50-0-151-4.dsl.dynamic.sonic.net) (Ping timeout: 248 seconds)
# [20:56] <scottjehl> tantek did the CG not follow that process in your opinion?
# [20:56] * Joins: jrschuhs (~jrschuhs@129-7-150-176.dhcp.uh.edu)
# [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.
# [20:57] * Quits: adactio (~adactio@cust217-dsl91-135-3.idnet.net) (Quit: adactio)
# [20:57] <tantek> scottjehl - no - based on my request to see a simple wiki page of use-cases and there not being one.
# [20:57] <tantek> the blog post was an excellent start
# [20:57] <tantek> but blog posts are snapshots
# [20:57] <tantek> they're not "living"
# [20:57] * jrschuhs is now known as rainerschuhsler
# [20:57] <tantek> grigs - "bad advice during the process" - yes that's what happens on mailing lists / support forums.
# [20:58] <grigs> tantek: and the alternative is?
# [20:58] <grigs> tantek: i thought you were suggesting support forums. i think i missed your earlier point.
# [20:58] <tantek> 1. document your research on an open wiki page, 2. post URLs on IRC etc. to gather feedback
# [20:59] <tantek> posting actual "content" on email lists is pretty much a waste of time
# [20:59] <jgraham> To be clear tantek's views on how to do things are personal.
# [20:59] <Wilto> tantek: This sounds a lot like what I did with http://wiki.whatwg.org/wiki/Adaptive_images?
# [20:59] <tantek> jgraham - no, the data fits my generazliations.
# [20:59] <tantek> generalizations even.
# [20:59] <jgraham> So you claim
# [20:59] <tantek> the bad advice that the respimg folks got on the whatwg list is just the latest example
# [20:59] <tantek> no, not claim - have URLs
# [20:59] <tantek> people already posted them above
# [21:00] <jgraham> Anyway the point that you should collect use cases first and present use cases before solutions is sound
# [21:00] <scottjehl> jgraham we certainly did that
# [21:00] <jgraham> scottjehl: That isn't clear
# [21:00] <tantek> scottjehl - I have to agree with jgraham on that - that part wasn't clear.
# [21:01] <jgraham> At least the wiki page I have seen that claims to have use cases mostly has solutions
# [21:01] <tantek> posting use-cases on a wiki page helps make it *more* clear
# [21:01] <othermaciej> tantek: what bad advice do you think the respimg guys got on the whatwg mailing list?
# [21:01] * Quits: necolas_ (~necolas@80.231.76.54) (Ping timeout: 265 seconds)
# [21:01] * Joins: esc_ (~esc_ape@178.115.248.12.wireless.dyn.drei.com)
# [21:01] <othermaciej> (interested in hearing because it would be good to ensure future contributors get good advice)
# [21:01] <tantek> jgraham - agreed. intermingling a particular syntax among use-cases is not helpful.
# [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.
# [21:01] <Wilto> It just got ignored, I assume because it is “done wrong.”
# [21:01] <tantek> Wilto - what post? to a mailing list?
# [21:01] <Wilto> Yes.
# [21:01] <tantek> Wilto - most email is ignored
# [21:01] <grigs> wilto: yeah, tantek did. he said it includes picture element.
# [21:01] <tantek> it's an inherent problem with the medium
# [21:01] <tantek> especially lists
# [21:02] <tantek> "someone else will handle it"
# [21:02] <Wilto> Eesh.
# [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.
# [21:02] <grigs> Wilto: i missed his comment when it went past the first time, but it is in the irc logs.
# [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.
# [21:02] <grigs> Wilto: nevermind. i misunderstood.
# [21:03] <Wilto> But, yeah—nothing on the mailing list.
# [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.
# [21:03] <grigs> Yeah. :-(
# [21:04] <Wilto> Dead-on as always, scottjehl.
# [21:05] <zewt> mail to the whatwg list always gets a reply ... but hixie is overloaded, so sometimes it takes a *long* time
# [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
# [21:05] <jgraham> The place where implementors (except Microsoft) typically work on HTML is WHATWG
# [21:05] * Joins: anon (aa8c6801@gateway/web/freenode/ip.170.140.104.1)
# [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
# [21:06] * Joins: twisted` (~twisted@p5DDB9484.dip.t-dialin.net)
# [21:06] * Joins: Guest1064 (~anonymous@87.115.113.220)
# [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.
# [21:07] <zewt> the mail you're replying to was wrong; whatwg is definitely the place for that discussion, IMO
# [21:07] <jgraham> FWIW the CG might have been a good place to gather *requirements*
# [21:07] * Joins: weinig (~weinig@2620:149:4:1b01:dae:2278:8d0c:bd0c)
# [21:07] <scottjehl> this is all very hard to hear now, naturally
# [21:07] <smaug____> Web Audio API is horrible. Hard to even start reviewing because everything is so under-defined
# [21:08] <odinho> scottjehl: http://odin.s0.no/web/srcset/polyfill.htm
# [21:08] <jgraham> grigs: So we will do better next time :)
# [21:08] <odinho> scottjehl: So, come with all the bugs. :P
# [21:09] <zewt> (don't know who "ronjec viktor" is, don't recall seeing his name before)
# [21:09] * Joins: CCD (~fragile@host86-132-138-217.range86-132.btcentralplus.com)
# [21:09] <tantek> jgraham - yes, CGs are plenty fine places to gather and even prioritize requirements and use-cases
# [21:09] <Wilto> I’m not comfortable saying “oh well, this is a forgone conclusion because the process is broken; better luck next time.”
# [21:09] <tantek> but I think bikeshedding a solution is too tempting for any group to avoid
# [21:10] <jgraham> Wilto: There is no "conclusion" yet
# [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
# [21:10] <Wilto> Fair.
# [21:10] <jgraham> Not much has happened really
# [21:10] * tantek agrees with jgraham
# [21:11] <jgraham> Hixie has been convinced that a set of requirements exist that are worth solving
# [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
# [21:11] <tantek> there's still quite the opportunity to define prioritized requirements and use-cases
# [21:11] <Wilto> Oh no—by no means to I consider this a done deal.
# [21:11] <jgraham> Whether or not these are the same requirements that you have is still unclear
# [21:11] <Wilto> do I.
# [21:11] <jgraham> There is no implementation and so no lock-in
# [21:11] <tantek> zewt - I mostly see discussions either repeated, or based in theory in email
# [21:12] <grigs> Slightly different topic: I have a question about a use case that I’ll document on the stub page later today.
# [21:12] * Parts: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
# [21:13] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
# [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
# [21:13] <zewt> tantek: a wiki doesn't stop email; it just duplicates it
# [21:14] <grigs> The browser for Meego image changes depending on the viewport width.
# [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?
# [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.
# [21:15] * Quits: pablof (~pablof@144.189.101.1) (Ping timeout: 240 seconds)
# [21:15] * Joins: frenkie (~frenkie@dhcp-077-251-134-060.chello.nl)
# [21:15] <jgraham> scottjehl: I think you are overestimating the clarity of the requirements
# [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.
# [21:16] * Joins: cafesofie (~user@ool-18e4c9a0.dyn.optonline.net)
# [21:16] <scottjehl> I don't think anyone involved in the CG was unclear about them
# [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.
# [21:17] * Joins: Guest1064 (~anonymous@87.115.113.220)
# [21:17] * Quits: chippper (627ca660@gateway/web/freenode/ip.98.124.166.96) (Quit: Page closed)
# [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.
# [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.
# [21:18] * Joins: manu1_ (~chatzilla@pool-71-171-16-71.nwrknj.east.verizon.net)
# [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.
# [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.
# [21:19] <tantek> email duplicates email
# [21:19] * gwicke_away is now known as gwicke
# [21:20] <scottjehl> anyway, both use cases are kind of the same
# [21:20] <grigs> scottjehl: ha ha. your comment makes it clear my fear that i'm not explaining myself clearly is well-founded. :-)
# [21:20] * Joins: mswartz (~textual@64.119.159.250)
# [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!
# [21:20] * Quits: manu1 (~chatzilla@pool-96-240-175-117.ronkva.east.verizon.net) (Ping timeout: 260 seconds)
# [21:20] * manu1_ is now known as manu1
# [21:21] * grigs going to lunch. back later.
# [21:21] <zewt> tantek: that's already trivial; a link to list archives
# [21:21] <scottjehl> tantek rehashing things we've already agreed upon in the wrong channel is all. These are the same use case
# [21:21] * Quits: timh (~tim@host86-186-70-81.range86-186.btcentralplus.com) (Quit: ta-ra chuck)
# [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.
# [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)
# [21:22] <Wilto> Sure thing, odinho. My mistake.
# [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
# [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)
# [21:23] * Quits: CCD (~fragile@host86-132-138-217.range86-132.btcentralplus.com) (Quit: Linkinus - http://linkinus.com)
# [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.
# [21:23] * Quits: PendragonDev (~IceChat77@ip-64-134-189-67.public.wayport.net) (Quit: Man who run behind car get exhausted)
# [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.
# [21:24] <zewt> i find mailing list conversations constantly; stuff on wikis is more hidden
# [21:24] * Joins: joshlockhart (~joshlockh@twdp-174-109-189-157.nc.res.rr.com)
# [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
# [21:24] <zewt> gross
# [21:24] <odinho> Wilto: Thanks. :-)
# [21:24] * jernoble is now known as jernoble|afk
# [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.
# [21:24] * Joins: sanjayb (~sanj@122.179.176.179)
# [21:24] <tantek> google (bing etc.) find thing things on wikis MUCH more easily than mailing lists
# [21:24] <zewt> wikis are pretty much useless for any kind of discussion
# [21:24] <tantek> so is email
# [21:25] <tantek> irc is a bit better
# [21:25] <zewt> uh, no it isn't?
# [21:25] * miketaylr is now known as miketaylrawaylol
# [21:25] <zewt> i've had countless useful discussions on email, so the claim just doesn't make any sense
# [21:25] * Quits: Guest1064 (~anonymous@87.115.113.220) (Remote host closed the connection)
# [21:26] <scottjehl> zewt sorry, my claim?
# [21:26] <tantek> scottjehl - there is no "whatwg" to have "asked" you to "clarify portions" - that's an illusion perpetrated by some individuals
# [21:26] <tantek> there is the editor of the spec, Hixie
# [21:26] <zewt> (your what?)
# [21:27] <scottjehl> zewt disregard sorry
# [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
# [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.
# [21:27] * jonlee is now known as jonlee|afk
# [21:27] * jonlee|afk is now known as jonlee
# [21:28] <jgraham> You know this whole doublespeak thing of saying "support forum" instead of "mailing list" gets old fast
# [21:28] <tantek> etherpad is a nice realtime improvement upon wikis also - works better for some discussions
# [21:28] <zewt> http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent
# [21:28] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [21:28] <tantek> jgraham - I don't think you understand what "doublespeak" means.
# [21:28] <scottjehl> yeah, picture planning originated in etherpad
# [21:28] <tantek> it's more like, acts like a duck, probably is a duck
# [21:28] <tantek> email lists that act like support forums may as well be considered support forums
# [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.
# [21:29] * Quits: anon (aa8c6801@gateway/web/freenode/ip.170.140.104.1) (Quit: Page closed)
# [21:29] <zewt> (i didn't say any of that, heh)
# [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 :]
# [21:29] <tantek> hmm krijnhoetmer.nl appears to be slow to respond for me
# [21:29] <bjankord> CG was a great place to read info, far better than IRC logs or email lists
# [21:29] <scottjehl> +1
# [21:30] <bjankord> CG was also open to everyone
# [21:30] <bjankord> The best ideas rise to the top this way
# [21:30] <zewt> odinho: you seem to be responding to things i didn't say :)
# [21:31] * Joins: mkanat (mkanat@nat/google/x-znqjevxmhnykdspx)
# [21:31] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [21:32] <odinho> 21:19 < zewt> http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent
# [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.
# [21:32] <odinho> zewt: You said that irc was sort of permanent.
# [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)
# [21:32] <scottjehl> Loads of developers actually thought they were taking the right steps to help plan this feature.
# [21:33] <zewt> odinho: ... none of what you said has anything to do with that :)
# [21:33] * Joins: jmather (~jmather@mail.bojigroup.com)
# [21:33] <zewt> i never said anything about reading IRC logs
# [21:33] * Joins: pablof (~pablof@144.189.101.1)
# [21:33] <zewt> only responding to "less permanent"
# [21:34] <bjankord> entering lurk mode
# [21:35] <scottjehl> http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/
# [21:35] * Quits: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [21:35] <odinho> zewt: I talked about it, -- and your comment seemed to be pointed at me.
# [21:35] * Quits: foolip (~philip@node-7lfba0hyoe7wdhmug.a0.ipv6.opera.com) (Read error: Connection reset by peer)
# [21:35] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
# [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.
# [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
# [21:36] <MarcDrummond> Obviously, process is important, but what we really care about is the implementation for responsive images.
# [21:37] * Joins: foolip_ (~philip@node-7lfbcq9y5f9l3btb6.a0.ipv6.opera.com)
# [21:37] <zewt> MarcDrummond: that belongs on the list, most of the time
# [21:38] <MarcDrummond> And so the wheel continues to spin.
# [21:38] <zewt> ...
# [21:38] <jgraham> MarcDrummond: If you have points that require real-time interaction feel free to discuss them here
# [21:38] <jgraham> If you have points that you want documented, use the wiki or the mailing list
# [21:39] * Joins: tobyo (~tobyo@cpe-24-165-22-166.san.res.rr.com)
# [21:39] * jernoble|afk is now known as jernoble
# [21:39] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [21:39] <jmather> scottjehl: thanks for the link
# [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.
# [21:41] <tantek> thanks scottjehl for the ALA link - I added it to: http://www.w3.org/wiki/Images#see_also
# [21:41] <tantek> (which you should feel free to edit directly as well)
# [21:41] * Quits: erichynds (~ehynds@64.206.121.41)
# [21:42] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
# [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.
# [21:42] * miketaylrawaylol is now known as miketaylr
# [21:42] * Joins: jarib (~jarib@unaffiliated/jarib)
# [21:42] <odinho> MarcDrummond: It has nothing to do with how the picture is presented. None whatsoever.
# [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
# [21:43] <odinho> MarcDrummond: You can write 100000000w for a picture that is 234px wide.
# [21:43] <scottjehl> sure thing
# [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).
# [21:43] <tantek> A solution that fails to solve the "important" use-cases is useless.
# [21:43] * Quits: sicking (~chatzilla@nat/mozilla/x-lvqdtqihpcubzkhh) (Ping timeout: 244 seconds)
# [21:43] <tantek> s/solution/implementation etc.
# [21:44] * Joins: rharr (~rharr@rrcs-98-100-9-178.central.biz.rr.com)
# [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)
# [21:44] <jmather> scottjehl: this is totally OT, but i've been following your trip on twitter -- absolutely fantastic. It must be incredible.
# [21:45] <jgraham> Right, the Aw Bh syntax is *somewhat* like a max-width:Apx max-height:Bpx media query
# [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.
# [21:45] <jgraham> Uh, +viewport somewhere
# [21:46] <zewt> tantek: that's uncommon, and present in all media
# [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?
# [21:46] <jgraham> It basically means "don't display this image unless the viewport is at least A x B"
# [21:46] <tantek> zewt - nope. such miscommunication is quickly corrected in places like IRC. but not apparently email.
# [21:46] <scottjehl> jmather ah! Kind of you to say, thanks :)
# [21:46] <tantek> this is a failing of email, and especially heavy lists.
# [21:46] <tantek> too much crap goes by that no one bothers to correct, so it gets propagated.
# [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
# [21:46] <jgraham> MarcDrummond: tantek has an aversion to mailing lists which he spreads with evangelical fervour
# [21:47] <jmather> scottjehl: not kind really… I'm just jealous. Hah.
# [21:47] <tantek> jgraham - you can stop the ad hominem anytime you like.
# [21:47] <jgraham> tantek: Which part isn't true?
# [21:47] <tantek> I'm simply communicating based on actual experiences (with citations)
# [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
# [21:47] <tantek> you're on the otherhand simply being defensive about emailing lists
# [21:47] <odinho> othermaciej: Nice summary.
# [21:48] <jgraham> tantek: "Citations" being more or less anecdotes
# [21:48] <tantek> othermaciej - right, whatwg list works as inbox for Hixie, beyond that, it's effectively a support forum.
# [21:48] <jgraham> I'm saying that overall the WHATWG list has been super-effective
# [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
# [21:49] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
# [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.
# [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.
# [21:49] * Joins: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [21:49] <jgraham> But I am not really interested in discussing the merits of these things
# [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
# [21:49] <tantek> then why do you keep bringing it up?
# [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
# [21:50] <tantek> othermaciej - it's a support forum for standards development for folks who don't realize they need a support forum.
# [21:50] <jgraham> The fact is that in order to engage with WHATWG/Hixie the mailing list is the primary veichle
# [21:50] <bjankord> Agreed
# [21:50] <tantek> nah, the whatwg list is a nice convenient public inbox for Hixie, nothing more really.
# [21:50] <jgraham> But you keep trying to discourage its use
# [21:50] <scottjehl> dropping off.
# [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
# [21:51] <jgraham> and are trying to coin some phrase to keep people away from it (the support forum thing)
# [21:51] <tantek> othermaciej, sure, because Hixie prefers it as his inbox, so it makes sense to send emails to whatwg accordingly.
# [21:51] * Joins: GAmini (407dba52@gateway/web/freenode/ip.64.125.186.82)
# [21:52] <tantek> jgraham, I'm not trying to discourage you from contributing to a support forum, please go on doing so.
# [21:52] <jgraham> See there we go again
# [21:52] <jgraham> It is tiresome
# [21:52] <jgraham> Plese stop
# [21:52] <jgraham> We are not children
# [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
# [21:52] <tantek> primarily Hixie's inbox?
# [21:53] <othermaciej> "support forum"
# [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."
# [21:54] <othermaciej> in my experience, many active participants on the list see it that way as well
# [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.
# [21:54] * Quits: raphc (~rc@92.103.77.27) (Ping timeout: 272 seconds)
# [21:55] * Joins: saba (~foo@unaffiliated/saba)
# [21:55] <tantek> btw - I would say the same about public-html as well FWIW.
# [21:55] <othermaciej> you may well have a point that discussion lists have intrinsic dysfunctions by nature
# [21:55] <tantek> sure, there are intrinsic dysfunctions, that's perhaps a broader statement.
# [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
# [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.
# [21:55] <othermaciej> doing so is likely to generate more heat than light
# [21:55] <jgraham> I am unaware of any communication medium that doesn't have some dysfunction
# [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.
# [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.
# [21:57] <tantek> you're right that it will/does cause some to react defensively and simply dig-in to support a tradition.
# [21:57] <jgraham> Anyway like I say, this is dull
# [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/
# [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
# [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.
# [21:58] * Joins: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net)
# [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
# [21:58] <ShaneHudson> I was surprised to see he was able to ublish to ALA so quickly,I would expect to wait for ages!
# [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.
# [21:58] <tantek> MarcDrummond, why limit yourself to two possible solutions?
# [21:58] <tantek> when the use-cases aren't even broadly understood, prioritized, and agreed upon?
# [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'
# [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)
# [22:00] <tantek> the "community" doesn't really have much power in that way
# [22:01] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
# [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.
# [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
# [22:02] <ShaneHudson> So is Hixie in charge of the entire spec? Still trying to get my head around the pecking order
# [22:02] <necolas> tantek: agreed. it shouldn't be about one early proposal vs another.
# [22:02] <tantek> ShaneHudson, yes, Hixie is the editor of HTML.
# [22:02] <othermaciej> Hixie derives his influence in large part from being responsive to other influential people
# [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. :)
# [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?
# [22:03] * annevk can probably read a little backlog
# [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.
# [22:03] <ShaneHudson> tantek: Thanks.. I didn't realise before there was one person in charge
# [22:03] <tantek> annevk - I was citing whatwg FAQ earlier.
# [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
# [22:03] * Joins: garand (4086afc1@gateway/web/freenode/ip.64.134.175.193)
# [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
# [22:04] <tantek> jmather - you're right, this discussion is likely beyond the point of diminishing returns.
# [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
# [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).
# [22:04] <tantek> annevk - I've continuously reiterated the request for well documented use-cases.
# [22:04] <ShaneHudson> tantek: I am working on the use-cases now :)
# [22:04] <tantek> which from my understanding is what WHATWG tends to prefer ;)
# [22:04] <annevk> tantek: there's http://wiki.whatwg.org/wiki/Adaptive_images
# [22:04] * Quits: rainerschuhsler (~jrschuhs@129-7-150-176.dhcp.uh.edu) (Quit: Linkinus - http://linkinus.com)
# [22:05] <MarcDrummond> tantek: But I'm quessing your question was rhetorical, since you know all that.
# [22:05] <tantek> annevk - that page is problematic because it presumes <picture> too much
# [22:05] <annevk> tantek: and they have been provided via email too, I think Hixie mentioned them upfront
# [22:05] * Quits: garand (4086afc1@gateway/web/freenode/ip.64.134.175.193) (Client Quit)
# [22:05] <annevk> tantek: easy enough to read around that
# [22:05] <jgraham> annevk: Beter to edit around it
# [22:05] <jgraham> i.e. rewrite the page
# [22:05] <othermaciej> annevk: do you understand how the "DOM Scripting and Bandwidth" item on that paye is a use case?
# [22:05] <tantek> annevk - better is: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/
# [22:05] <jgraham> But some people wanted accounts
# [22:05] <tantek> but that's not on a wiki page
# [22:05] <jgraham> Do you have admin access?
# [22:05] <tantek> so it can't be edited/ prioritized etc.
# [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
# [22:06] <annevk> othermaciej: I don't agree with all the use cases :)
# [22:06] <ShaneHudson> http://www.w3.org/wiki/Images
# [22:06] <annevk> jgraham: I do
# [22:06] <jgraham> Someone also started a page on the W3C wiki, but you need a W3C ccount to edit that
# [22:06] <annevk> haha
# [22:06] <annevk> four places already
# [22:06] <tantek> annevk - exactly, we need this on a wiki so we can all contribute to the use-cases
# [22:06] <annevk> way to go internet :)
# [22:06] <ShaneHudson> (I am writing it at the moment, but that is the page it will be)
# [22:06] * Joins: jarek (~jarek@bcr1.neoplus.adsl.tpnet.pl)
# [22:06] * Quits: jarek (~jarek@bcr1.neoplus.adsl.tpnet.pl) (Changing host)
# [22:06] * Joins: jarek (~jarek@unaffiliated/jarek)
# [22:06] <tantek> thanks ShaneHudson
# [22:07] * Quits: eric_carlson (~eric@17.212.152.104) (Quit: eric_carlson)
# [22:07] <jgraham> tantek: Which of the muliple wikis it is on did you have in mind
# [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
# [22:07] <jgraham> (all with non-overlapping sets of authorised users)
# [22:07] <jmather> othermaciej: I think someone is working on that...
# [22:07] <tantek> othermaciej - my conclusion exactly
# [22:07] <annevk> tantek: anyway I was talking about your meta point, the mailing list being a "support forum"
# [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
# [22:07] <jmather> but i could have misunderstood what's going on here. :D
# [22:07] * Joins: eric_carlson (ericc@nat/google/x-pyurtiwfinnqjfms)
# [22:07] <Philip`> Someone should set up a Tumblr with a list of all the wikis
# [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
# [22:07] * Joins: malydok (~marek@moma.t16.ds.pwr.wroc.pl)
# [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
# [22:08] <jgraham> That seems to exclude most developers
# [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.
# [22:09] <jgraham> Also, http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ is indeed very nice
# [22:09] <jmather> jgraham: which is kind of what is causing the current uproar, which might not want to be perpetuated...
# [22:09] <tantek> annevk - here's some more reading on it: http://microformats.org/wiki/wiki-better-than-email
# [22:09] <tantek> jgraham - yes, even just moving that blog post to a wiki for iteration would be a huge help
# [22:09] <ShaneHudson> jgraham: I will add those points in that article to the wiki. Please stop moaning, instead helping would be appreciated
# [22:10] <tantek> I think we just need to give ShaneHudson some time to update w3.org/wiki/Images :)
# [22:10] * Quits: danielfilho (~daniel@187.31.77.7) (Quit: danielfilho)
# [22:10] <jmather> I don't think Anselm would be upset if someone copy/pasted it.
# [22:10] * jonlee is now known as jonlee|afk
# [22:10] * anatolbroder just wants to tell thank you to othermaciej and other nice guys who brought the srcset attribute
# [22:11] <othermaciej> very little of the credit goes to me!
# [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)
# [22:12] * Quits: frenkie (~frenkie@dhcp-077-251-134-060.chello.nl) (Quit: frenkie)
# [22:14] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
# [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/
# [22:15] * Quits: brucel (~brucel@cpc5-smal11-2-0-cust151.perr.cable.virginmedia.com) (Ping timeout: 272 seconds)
# [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."
# [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
# [22:16] * Joins: nickd_ (180c6b1d@gateway/web/freenode/ip.24.12.107.29)
# [22:17] * nickd_ is now known as _nickd
# [22:17] * Joins: adactio (~adactio@cust217-dsl91-135-3.idnet.net)
# [22:17] <annevk> tantek: mkay, I think we use wikis pretty often actually; they just haven't been used in this instance
# [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?
# [22:17] * Joins: vasko333 (~vasko_din@46.40.94.64)
# [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.
# [22:17] * Joins: import-logic (~ambience@cpe-066-057-225-104.nc.res.rr.com)
# [22:17] <jgraham> tantek: How does one get an account?
# [22:17] <tantek> annevk - agreed. that was part of my point.
# [22:17] <annevk> tantek: see e.g. timed tracks, the recent canvas additions
# [22:17] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [22:17] <ShaneHudson> jmather: it is easier to access the w3c wiki than it is the whatwg, which is why we decided on it
# [22:18] <ShaneHudson> General question (perhaps tantek could answer).. I presume everyone is fine with me writing the wiki in British English?
# [22:18] * Quits: cheron (~cheron@unaffiliated/cheron) (Quit: Leaving.)
# [22:18] <tantek> jgraham, right at the top of the home page: http://www.w3.org/wiki/Main_Page
# [22:18] <tantek> Request a Public W3C Account to get started.
# [22:18] * Joins: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202)
# [22:18] <tantek> where Public W3C Account links to:
# [22:18] <tantek> http://www.w3.org/Help/Account/Request/Public
# [22:18] <MarcDrummond> Wish somebody would answer jmather's very reasonable question.
# [22:19] * JohnAlbin is now known as JohnAlbin_zzzzzz
# [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
# [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 :)
# [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
# [22:19] <tantek> (i.e. not sure that adding it to an FAQ would help any)
# [22:19] * Quits: vasko333 (~vasko_din@46.40.94.64) (Remote host closed the connection)
# [22:19] <jgraham> tantek: It sounds a lot like it is for people who are becoming invited experts
# [22:19] <import-logic> jmather: lol'd
# [22:19] <jgraham> Anyway if it works for people I don't care
# [22:20] * Joins: aki_ (~aki_@CPE-72-128-75-73.wi.res.rr.com)
# [22:20] * doublec_ is now known as doublec
# [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 ..."
# [22:20] * Joins: espadrine (~thaddee_t@nat/mozilla/x-mxhbowpmlthsaghx)
# [22:21] * Quits: doublec (~doublec@cd.pn) (Changing host)
# [22:21] * Joins: doublec (~doublec@unaffiliated/doublec)
# [22:21] <tantek> if you'd like to suggest different prose, I'm sure we could ask W3C to improve the content.
# [22:21] <annevk> afaik they can be created by anyone
# [22:21] <annevk> if people want an account on the WHATWG wiki btw I can create them
# [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."
# [22:21] <tantek> jmather, exactly, perhaps consider the sign-up form to be a light-weight captcha ;)
# [22:21] <annevk> we disabled account creation because of the amount of spam :(
# [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.)
# [22:21] <jgraham> Neither of which is the case here
# [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
# [22:22] * Quits: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net) (Ping timeout: 272 seconds)
# [22:22] <annevk> jreading: MQs don't handle the pixel density case
# [22:22] <jgraham> jmather: If all the people who are interested in contributing have accounts there, that's fine
# [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
# [22:22] <jmather> annevk: I thought they did?
# [22:22] <annevk> jreading: they can query it, but you need to set the pixel density
# [22:22] * Joins: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be)
# [22:23] <jgraham> http://www.w3.org/wiki/index.php?title=Special:UserLogin&returnto=Main_Page then "Account Request Form"
# [22:23] * jonlee|afk is now known as jonlee
# [22:23] <tantek> a-ha! thanks
# [22:23] * Quits: _nickd (180c6b1d@gateway/web/freenode/ip.24.12.107.29) (Quit: Page closed)
# [22:24] <tantek> that page, http://www.w3.org/Help/Account/ , is quite confusing :/
# [22:24] <jmather> jreading: hrm… i haven't seen anything about statefulness… link?
# [22:24] <jmather> annevk: which pixel density case? link?
# [22:25] <annevk> jmather: you cannot do <img src=lala srcset="tralla 2x"> in a way that works properly using the <picture> proposal
# [22:25] <MarcDrummond> annevk: Why not?
# [22:25] <jmather> annevk: device-pixel-ratio: 2 in the media query should do it, no?
# [22:26] <annevk> jmather: how does that downscale "trallla"?
# [22:26] <annevk> "lala" is 10x10; "tralla" is obviously 20x20
# [22:26] <jmather> the width/height defined to the pixel element forms the size from what I understand (if I get your question right)
# [22:26] <annevk> if you just display tralla it would be way bigger
# [22:27] <ShaneHudson> Is resolution and DPI technically synomynous?
# [22:27] <annevk> jmather: so each source element would always have a width/height attribute?
# [22:27] <annevk> ShaneHudson: sure
# [22:27] <annevk> jmather: because all the <picture> examples got this wrong
# [22:27] <jreading> width/height attrs
# [22:27] * Joins: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com)
# [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.
# [22:27] <ShaneHudson> annevk: thanks
# [22:27] <annevk> jmather: so nobody seems to be knowing what is going on
# [22:27] <jmather> annevk: from my understanding, sizing would work the same with srcset and picture
# [22:27] <annevk> jmather: and including them all over seems bloat
# [22:27] * Quits: aadams (80f901ca@gateway/web/freenode/ip.128.249.1.202) (Quit: Page closed)
# [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
# [22:28] <scottjehl> img: max-width: 100%; is commonly used in responsive layouts. It'd address that
# [22:28] <annevk> jmather: again, how does <picture> downscale it if you don't set height/width?
# [22:28] <annevk> scottjehl: that doesn't work for icons
# [22:28] <jreading> and why not work to improve MQs instead of creating a whole new spec outside of that...
# [22:28] <scottjehl> icons?
# [22:28] <MarcDrummond> annevk: why prioritize avoiding code bloat over clarity for authors and extensibility?
# [22:29] <annevk> jreading: MQ is about reading device info, it's not about sizing images
# [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
# [22:29] <annevk> MarcDrummond: dunno, you think including height/width attributes all over is better?
# [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
# [22:29] <annevk> jmather: we don't know the ratio
# [22:29] <jmather> annevk: no other width/height would be included than with srcset
# [22:29] <jmather> annevk: but we do
# [22:29] <annevk> jmather: how?
# [22:29] * Joins: rakm (~rakm@sonic.mochaleaf.com)
# [22:29] <scottjehl> icons are the use case the makes picture impractical?
# [22:30] <jmather> device-pixel-ratio knows the density
# [22:30] <scottjehl> the/that
# [22:30] <jmather> and then downloading the picture gets the dimensions
# [22:30] <annevk> scottjehl: no
# [22:30] <annevk> jmather: what if the ratio of the device is greater than 2?
# [22:30] * Quits: graememcc (~chatzilla@host86-140-179-108.range86-140.btcentralplus.com) (Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120310193349])
# [22:30] <annevk> jmather: you need to know the ratio of the image, not the device
# [22:30] <jmather> on a 2x image, 1/2 the width/height would be the natural display size
# [22:30] <annevk> but the MQ applies to the device, not the image...
# [22:30] <jmather> annevkhwo often do you include images with no width/height?
# [22:31] <jmather> I've never done it, at least recently
# [22:31] <annevk> jmather: I do it all the time, but I'm told I'm not a normal author
# [22:31] <jmather> always at least width
# [22:31] <annevk> but you are shifting the argument now
# [22:31] <jmather> but then my main job is maintaining a CMS, so I have a different angle than a lot of people :)
# [22:31] <annevk> and again
# [22:31] <scottjehl> very common in responsive design to omit width and height attrs
# [22:31] <annevk> all the <picture> examples thus far got this wrong
# [22:31] <jmather> Not trying to shift the argument, just answering your questions
# [22:32] <scottjehl> annevk - I'm unclear what "this" is that you're referring to
# [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?
# [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
# [22:32] <jmather> scottjehl: but even then you would still have width: 100% or whatnot in the css applied to it somewhere, right?
# [22:32] * Joins: dreadnaut (~Miranda@188-221-64-204.zone12.bethere.co.uk)
# [22:32] <scottjehl> jmather yes max-width: 100% is the usual fluid images CSS
# [22:32] <jmather> right
# [22:33] <jmather> annevk's argument is what happens when there is /no/ width/height guideline
# [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
# [22:33] <annevk> MarcDrummond: <img src=x srcset="y 2x"> x is 10x10; y is 20x20
# [22:33] <annevk> MarcDrummond: tell me how to do that with <picture>
# [22:33] <jreading> <picture> <source media="device-pixel-densiity:2" src="2xbig.jpg" width="50%">
# [22:33] * Joins: atadams (80f901c2@gateway/web/freenode/ip.128.249.1.194)
# [22:33] <jreading> how's that?
# [22:33] <annevk> that's not the same
# [22:34] <jreading> .picture {width:100%}
# [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
# [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
# [22:34] <ShaneHudson> tantek: Thanks, I don't think I am ready to write the actual spec quite yet :p
# [22:34] * Quits: weinig (~weinig@2620:149:4:1b01:dae:2278:8d0c:bd0c) (Quit: weinig)
# [22:34] <annevk> scottjehl: it would be displayed four times the size if you just use max-width
# [22:34] <ShaneHudson> Hard enough writing a wiki haha
# [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>
# [22:34] <annevk> MarcDrummond: yeah that fails
# [22:35] <MarcDrummond> annevk: Why?
# [22:35] <annevk> MarcDrummond: if y is selected it would be displayed four times as big as x
# [22:35] <jmather> annevk: why?
# [22:35] <jgraham> FWIW I think this is reenforcing my belief that media queries are only a superficially good match for this use case
# [22:35] <MarcDrummond> annevk: I don't see why that would be the case.
# [22:35] <annevk> the reason is this
# [22:35] <annevk> MQ asks the device if it's pixel ratio is at least 2; device says yes
# [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
# [22:36] <annevk> browser thus selects y
# [22:36] <tantek> ShaneHudson - just figured I'd give you a heads-up and provide citations accordingly ;)
# [22:36] <annevk> browser starts laying out y
# [22:36] * Joins: acarback (~Adium@static-71-179-165-244.bltmmd.fios.verizon.net)
# [22:36] <annevk> its 20x20
# [22:36] <annevk> there's no information about DPI associated with the image thus the browser uses 1 CSS pixel for each image pixel
# [22:36] * Parts: acarback (~Adium@static-71-179-165-244.bltmmd.fios.verizon.net)
# [22:36] <MarcDrummond> annevk: That association goes in the CSS.
# [22:36] <annevk> and you get something that's four times as big as x
# [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>
# [22:37] <annevk> MarcDrummond: are you saying your example was incomplete?
# [22:37] <jreading> pave the freakin' cowpaths
# [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.
# [22:37] <annevk> jreading: that's not the same as my example
# [22:37] <annevk> jmather: it's a problem in all the <picture> examples
# [22:37] <scottjehl> jmather +1
# [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
# [22:37] <jmather> logically, I totally see your point
# [22:38] * Joins: richw (560acfe2@gateway/web/freenode/ip.86.10.207.226)
# [22:38] <jmather> but scott says he hasn't seen this particular issue actually occur in the wild
# [22:38] <jgraham> Isn't that going to break if the pixel ratio is not exactly 2
# [22:38] <jmather> and he's done quite a bit of leg-work regarding picture
# [22:38] <annevk> well he's wrong
# [22:38] <jmather> annevk: umm, not sure how actual results from testing an implementation directly are … wrong.
# [22:38] <MarcDrummond> annevk: Why do you say he's wrong. Have you tested this? He has.
# [22:39] * Joins: nathanstaines (~nathansta@cpc36-camd13-2-0-cust393.20-2.cable.virginmedia.com)
# [22:39] * Joins: jared (324e4d86@gateway/web/freenode/ip.50.78.77.134)
# [22:39] * jared is now known as Guest62853
# [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
# [22:39] <annevk> I can tell he's wrong because I know how media queries and images work
# [22:39] * Joins: ajpiano (~ajpiano@li98-57.members.linode.com)
# [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?
# [22:40] * Joins: darcyclarke (~darcyclar@dsl-66-185-205-103.vianet.ca)
# [22:40] <scottjehl> no the testing we did was more... deliver a higher density image to a retina iphone
# [22:40] <TabAtkins> If you're using explicit sizes on the <img>, it'll "work", because the browser is downscaling.
# [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.
# [22:41] <TabAtkins> And in a retina environment, the downscaling will work well.
# [22:41] <jmather> I don't think we have any 3x displays to test on yet annevk
# [22:41] * Quits: gwicke (~gabriel@212.255.28.33) (Read error: Connection reset by peer)
# [22:41] <annevk> jmather: not sure how that's an argument
# [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.
# [22:41] * Joins: gwicke (~gabriel@212.255.28.33)
# [22:41] <annevk> scottjehl: I'd be interested in a pointer to the test
# [22:42] <jmather> annevk: basically just that there's time to solve it
# [22:42] <annevk> jmather: it doesn't work now either
# [22:42] <annevk> jmather: unless you specify width/height all the time which is rather insane
# [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?
# [22:42] <annevk> if you ask me anyway
# [22:42] <jmather> so, specify width/height? :)
# [22:43] <jmather> I dunno.
# [22:43] <jreading> scottjehl: that's what I'm trying to figure out wtf they are saying...
# [22:43] <jmather> What does srcset do with a 2x image on a 3x display?
# [22:43] <TabAtkins> Whatever the UA decides is appropriate.
# [22:45] <scottjehl> did my example make sense?
# [22:45] <TabAtkins> Yeah, that example works.
# [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
# [22:45] <scottjehl> that's what I imagine to be the 95% use case
# [22:45] <TabAtkins> If you set a size, the "original" size doesn't matter.
# [22:45] <jmather> TabAtkins: but what is spec'd to happen?
# [22:45] <annevk> it doesn't seem at all clean to me to not have that semantic embedded
# [22:45] <TabAtkins> jmather: Literally what I just said.
# [22:45] <scottjehl> right. this fact can be used to our advantage. How is this a failing of picture?
# [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.
# [22:46] <annevk> scottjehl: it requires a bunch of extra attributes
# [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.
# [22:46] <scottjehl> what attributes?
# [22:46] <annevk> width/height
# [22:46] <annevk> if CSS is disabled the image will be way large
# [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
# [22:47] <annevk> *otherwise
# [22:47] <scottjehl> tabatkins that's a very different subject, no?
# [22:47] <scottjehl> annevk no width or height attrs are used here
# [22:47] <TabAtkins> scottjehl: Not really, no.
# [22:47] * Quits: atadams (80f901c2@gateway/web/freenode/ip.128.249.1.194) (Quit: Page closed)
# [22:47] <annevk> scottjehl: exactly, but you need to
# [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.
# [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.
# [22:47] <annevk> scottjehl: because otherwise with CSS disabled it'll turn ugly
# [22:47] <jmather> TabAtkins: your first paragraph after tl;dr is … i believe highly inccorect
# [22:48] <jmather> that's the central starting point for any responsive image implantation, i think
# [22:48] <jmather> that or ipad3… either way
# [22:48] <scottjehl> annevk... disabling css on a retina ipad is the reason picture isn't practical?
# [22:48] * Joins: tgecho (~tgecho@66-55-201-102.gwi.net)
# [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.
# [22:49] <jmather> annevk: can you even disable css on an iPad in safari?
# [22:50] * jmather has never even thought to try
# [22:50] <annevk> that was just to illustrate a point
# [22:50] <annevk> that you want the semantic that the image is twice its actual size in the markup
# [22:50] <MarcDrummond> What point? What use case are you highlighting where this wouldn't work?
# [22:50] <annevk> so that if you do anything with that image it's known what is going on
# [22:50] <scottjehl> partially kidding there, but seriously, this doesn't seem like a real problem we're facing
# [22:51] * Quits: darcyclarke (~darcyclar@dsl-66-185-205-103.vianet.ca) (Quit: Leaving...)
# [22:51] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Read error: Connection reset by peer)
# [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
# [22:51] * Joins: fabuloso_ (~fabuloso@unr0cae.fiu.edu)
# [22:51] * Joins: Methapod (~anthony@203.b.005.mel.iprimus.net.au)
# [22:51] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
# [22:51] * Quits: fabuloso_ (~fabuloso@unr0cae.fiu.edu) (Client Quit)
# [22:51] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
# [22:52] * Joins: fabuloso_ (~fabuloso@unr0cae.fiu.edu)
# [22:52] <jmather> annevk: which is why the styling/sizing applies to picture and then whatever source is selected is used to fill it
# [22:52] <TabAtkins> jmather: Interesting. private message me to discuss?
# [22:52] <annevk> jmather: that doesn't work if you want to vary both width and pixel density
# [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
# [22:53] <annevk> scottjehl: e.g. you hit that problem as soon as you draw the image on a <canvas>
# [22:53] <scottjehl> I could easily update the picture demo to include a high-density source
# [22:53] <annevk> scottjehl: because instead of only taking up 500px it would take up 1000px
# [22:53] <jmather> the iPad/iphone retina displays are what threw so much fuel on the fire of getting something working
# [22:53] <TabAtkins> jmather: I meant relative to your assertion that my tl;dr paragraph is wrong.
# [22:54] * Quits: cafesofie (~user@ool-18e4c9a0.dyn.optonline.net) (Ping timeout: 240 seconds)
# [22:54] <annevk> scottjehl: whereas with srcset we know the image is only 500px because of the 2x indicator
# [22:54] <scottjehl> that also seems fairly avoidable to me
# [22:54] <jmather> TabAtkins: not your tl;dr, first para after.
# [22:54] * Joins: sicking (~chatzilla@nat/mozilla/x-oixmvwucyeqaizct)
# [22:54] <TabAtkins> jmather: Oh, that's even more interesting if you think it's wrong.
# [22:54] <annevk> jmather: yeah and only Apple managed to make a proposal that works
# [22:54] <annevk> thus far anyway
# [22:55] * Joins: teleject (~christoph@208.66.176.1)
# [22:55] <scottjehl> that's unfair, I think
# [22:55] <krijnh> Quiet day on the internets today, what's happening?
# [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.
# [22:55] * Quits: teleject (~christoph@208.66.176.1) (Client Quit)
# [22:55] <jmather> annevk: the only time that comes in to play is when no dimensions of any kind are set on picture
# [22:56] <TabAtkins> jmather: Oh, okay. Well, the proposals that the CG put forward weren't taking resolution into account, afaict.
# [22:56] <jgraham> krijnh: Heh. Going for gold in your own logs?
# [22:56] <annevk> jmather: actually no, that would always occur
# [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
# [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
# [22:56] <annevk> jmather: unless there's a semantic that tells the pixel density
# [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.
# [22:57] <jmather> annevk: it doesn't need pixel density info
# [22:58] <jmather> it needs to know how many css pixels the image has to fill
# [22:58] <scottjehl> what works seems highly subjective here.
# [22:58] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
# [22:58] <scottjehl> sorry, gotta drop off again. thanks
# [22:58] <jreading> Tab: seems like bandwidth MQ is the only sticking point for why MQs fail with respimgs, no?
# [22:58] <jmather> TabAtkins: depends on what context you mean
# [22:58] * Joins: weinig (~weinig@2620:149:4:1b01:111f:22c2:794b:7ee2)
# [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
# [22:59] <jmather> but i don't think it's really required
# [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?
# [22:59] <MarcDrummond> annevk: It really seems you are beating an imaginary issue into the ground.
# [23:00] <jmather> at least from a content guy's perspective… I have a box, 100x100 in css pixels
# [23:00] <jmather> I want it filled with an image
# [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
# [23:00] * Joins: rharr_ (~rharr@rrcs-98-100-9-178.central.biz.rr.com)
# [23:01] <jmather> ShaneHudson: that's something that really interested me about picture as well
# [23:01] <jmather> not so much in that i think we need it
# [23:01] * Quits: greenplastic (~anonymous@71-87-1-124.static.eucl.wi.charter.com) (Quit: greenplastic)
# [23:01] <jmather> but that it would give room for new file formats to grow
# [23:01] <jmather> like, say, a stereographic image format, perhaps?
# [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.
# [23:02] * Quits: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be) (Ping timeout: 244 seconds)
# [23:02] <annevk> MarcDrummond: hey man, I'm just telling you what's wrong with <picture>
# [23:02] <annevk> MarcDrummond: at the end of the day, I don't really care what happens here
# [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.
# [23:02] <annevk> feel free to ignore me
# [23:02] * Joins: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net)
# [23:03] * ojan_away is now known as ojan
# [23:03] <annevk> MarcDrummond: even if they add width, it would still blow up on <canvas>
# [23:03] <MarcDrummond> annevk: I do care. As do a lot of other developers/authors. Feel free to pay attention to our concerns!
# [23:03] <annevk> MarcDrummond: as I mentioned before
# [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.
# [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..."
# [23:03] * Quits: rharr (~rharr@rrcs-98-100-9-178.central.biz.rr.com) (Ping timeout: 260 seconds)
# [23:04] <jmather> TabAtkins: picture covers for that well
# [23:04] <annevk> jmather: you're coming accross as someone who doesn't want to hear about problems with <picture>
# [23:04] * Quits: Guest62853 (324e4d86@gateway/web/freenode/ip.50.78.77.134) (Quit: Page closed)
# [23:04] <TabAtkins> jmather: Based on the last thing I've seen of <picture>, it doesn't, unless you hack in @srcset functionality.
# [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.
# [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
# [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.
# [23:05] * Quits: rharr_ (~rharr@rrcs-98-100-9-178.central.biz.rr.com) (Ping timeout: 272 seconds)
# [23:05] <MarcDrummond> TabAtkins: So, image displays ONLY for retina displays with sufficient bandwidth, otherwise no image at all? That also seems unlikely.
# [23:05] * Joins: SimpleQuark (~SimpleQua@64.124.62.236)
# [23:05] <jmather> TabAtkins: <picture><sourcr src="image@2.jpg" media="min-device-pixel-ratio: 2"><source src="image.jpg"></picture> I think
# [23:06] <jmather> well, aside from bandwidth, granted
# [23:06] <jmather> but if a bandwidth mq were added, easy enough
# [23:06] <annevk> a bandwidth MQ? haha
# [23:06] * Quits: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net) (Quit: dgathright)
# [23:07] <gsnedders> Have we not been over why MQ don't work for bandwidth often enough yet?
# [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?
# [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.
# [23:07] * Joins: cpearce (~cpearce@60.234.54.74)
# [23:07] <annevk> jmather: expose it how?
# [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.
# [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.?
# [23:08] <annevk> jmather: btw, your media queries thus far miss the required parenthesis and would therefore fail
# [23:08] <gsnedders> FWIW, I don't like the srcset syntax at first glance, but that's a syntatual issue
# [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
# [23:08] <annevk> jmather: ease of authoring is important ;)
# [23:08] * Parts: akselkreis (~Adium@rrcs-50-75-52-51.nys.biz.rr.com)
# [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?
# [23:09] <davatron5000> jmather: +1
# [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
# [23:09] * Quits: rdebeasi (ada04aae@gateway/web/freenode/ip.173.160.74.174) (Quit: Page closed)
# [23:09] <annevk> I didn't come up with srcset
# [23:09] * Joins: danielfilho (~daniel@187.31.77.7)
# [23:09] <annevk> I don't really care for it either
# [23:09] <jmather> kevinSuttle: I have no idea
# [23:09] <annevk> but given the alternative...
# [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.
# [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.
# [23:10] <jmather> but TabAtkins wanted the browser to account for bandwidth in it's downloading provision
# [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.
# [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.
# [23:11] * Quits: anatolbroder (~bro@frnk-4d01d4a8.pool.mediaWays.net) (Read error: Operation timed out)
# [23:11] <zewt> shouldn't you understand it before deciding you don't like it :)
# [23:11] <jmather> zewt: gut instincts are there for a reason :)
# [23:11] <jmather> not to say they can't be wrong
# [23:12] <jreading> so i think the srcset folks agree with me that bandwidth MQ is a bad idea
# [23:12] <jreading> also, seems that's the ONLY sticking point
# [23:12] <jreading> so lose it
# [23:12] <gsnedders> jmather: Someone saying an issue with picture (or bandwidth MQs, etc.) doesn't mean they like srcset is my point
# [23:12] <jmather> gsnedders: true enough
# [23:13] * Quits: joshlockhart (~joshlockh@twdp-174-109-189-157.nc.res.rr.com) (Quit: joshlockhart)
# [23:13] <zewt> (you can do bandwidth without trying to actually strictly define it, eg. as i suggested with the file-size hint)
# [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?
# [23:13] <annevk> zewt: but not in MQs
# [23:13] <annevk> MQs are about device capabilities
# [23:13] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
# [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>).
# [23:13] <jmather> kevinSuttle: I think it's mainly because video/audio is considered "done" with the tags
# [23:13] <annevk> whereas we are concerned here with capabilities from the image
# [23:13] <zewt> annevk: i'm talking about srcset, don't know much of anything about MQ
# [23:13] <annevk> such as its size and aspect ratio
# [23:14] <gsnedders> jmather: Nah, they aren't done. They can always have more done to them, as can img.
# [23:14] <jmather> TabAtkins: at which point with html , verbose and readable usually wins
# [23:14] <zewt> and file size, which is a relative representation of content quality (relative to the other options, at least)
# [23:14] <jreading> and if the concern is the flipping on/off of bandwidth MQ, make them behave differently or lose it
# [23:14] <TabAtkins> jmather: That's an arguably point. ^_^
# [23:14] <jmather> Unfortunately I have to take off now :)
# [23:14] <annevk> using device queries (=MQs) for resource selection is the wrong solution (for <video> too imo)
# [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?
# [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
# [23:15] <jmather> kevinSuttle: because html video sucks. :D
# [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
# [23:15] <annevk> jmather: I haven't seen much people make mistakes with srcset yet, plenty with <picture> though...
# [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.
# [23:15] <jreading> so bandwidth MQ is out and <picture> is back in, right?
# [23:16] <zewt> (nothing screams troll like calling someone a "dictator"; do you even know how standards work?)
# [23:16] <jmather> alright, c-ya guys. Gotta run.
# [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?
# [23:16] <annevk> me too
# [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.
# [23:16] <TabAtkins> MarcDrummond: HTML is a benevolent dictatorship, but that seems to be a successful model for tech.
# [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…
# [23:17] * Quits: fabuloso_ (~fabuloso@unr0cae.fiu.edu) (Quit: fabuloso_)
# [23:17] <MarcDrummond> zewt: Thank you for your condescension.
# [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…
# [23:17] <zewt> TabAtkins: it's not, since implementors effectively have (as a unit, not individually) veto power
# [23:17] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [23:17] * Joins: raphc (~rc@ppp-sei21-46-193-160.67.wb.wifirst.net)
# [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.
# [23:17] * Joins: duecaja (~jamesduec@cpe-24-93-190-62.neo.res.rr.com)
# [23:18] <gsnedders> zewt: Well, as a unit of two or more
# [23:18] <gsnedders> Not necessarily as a unit of all of them.
# [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)
# [23:19] <gsnedders> zewt: Yeah, I was just trying to clarify more than correct *you*. I think you know well enough how things work.
# [23:19] * Quits: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42) (Quit: Page closed)
# [23:19] * Quits: jmather (~jmather@mail.bojigroup.com) (Quit: jmather)
# [23:19] <bjankord> What happens when Hixie makes bad choices?
# [23:19] * Joins: MarcDrummond (9c8e302a@gateway/web/freenode/ip.156.142.48.42)
# [23:20] <zewt> everyone tells him :)
# [23:20] <bjankord> Does he listen?
# [23:20] <bjankord> Does he care?
# [23:20] <TabAtkins> If he doesn't, browsers do what they want anyway.
# [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.
# [23:20] <TabAtkins> So yes, it's ultimately the slave of the browsers.
# [23:20] * Hixie pops his head in and then ducks the incoming tomatoes
# [23:21] <tantek> but at least they're high-resolution tomatoes.
# [23:21] <bjankord> +1
# [23:21] <Hixie> 'sup people
# [23:21] <Hixie> please direct your ire at me :-)
# [23:21] <adactio> Oh hai.
# [23:21] <Hixie> happy to answer any questions
# [23:22] * zewt BEAM
# [23:22] <davatron5000> Hixie: You have lots of explaining' to do [/rickyricardo]
# [23:22] <bjankord> Hixie: Is there any chance the picture element would be reconsidered
# [23:22] * Quits: dcheng (~dcheng@74.125.59.65) (Quit: leaving)
# [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.
# [23:22] <bjankord> I've heard if it is revised there is a chance that it will be reconsidered
# [23:23] * Quits: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
# [23:23] <Hixie> bjankord: if there is new information, absolutely
# [23:23] <Hixie> bjankord: however generally speaking it's better to talk about use cases, not solutions
# [23:23] <Hixie> bjankord: and to point out what is wrong with the existing solutions
# [23:24] <Hixie> bjankord: so e.g. "srcset="" doesn't address use case X" or "srcset="" is overly complicated for use case X"
# [23:24] <necolas> Hixie: by "existing solutions" do you mean @srcset?
# [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."
# [23:24] <Hixie> necolas: now, yes
# [23:24] <zewt> zzz
# [23:24] <TabAtkins> adactio: Welcome to a multitude of opinions.
# [23:24] <jgraham> In other news TabAtkins and zewt are the same person
# [23:24] <zewt> :|
# [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
# [23:25] <TabAtkins> adactio: That's why references to the "cabal" are so misleading. ^_^
# [23:25] <annevk> there's disagreement in the cabal?
# [23:25] <annevk> quick krijn, disable public logging!
# [23:25] <jgraham> annevk: Not in #secret-treehouse
# [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)
# [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.
# [23:25] <jgraham> Just for show
# [23:25] <annevk> jgraham: ssssh
# [23:26] <bjankord> Hixie: Would examples of use cases of picture element be helpful, or you specifically looking for use cases of srcset?
# [23:26] <tantek> adactio, I thought the accepted term was BDFL per http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life
# [23:26] * Joins: dcheng (~dcheng@74.125.59.65)
# [23:26] <zewt> (I don't feel like dignifying that with a reply, beyond this one)
# [23:26] * Quits: KDN (~kdn@90.149.135.254) (Quit: KDN)
# [23:26] <Hixie> bjankord: use cases don't mention solutions
# [23:26] <necolas> Hixie: we can consider it progress that it is now agreed that there is a problem to solve
# [23:26] <Hixie> bjankord: srcset and <picture> are solutions
# [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.
# [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"
# [23:27] <Hixie> MarcDrummond: one of the lessons we learnt from <video> is that hte <source> pattern is a bad one, unfortunately
# [23:27] * Joins: jarek (~jarek@aeap36.neoplus.adsl.tpnet.pl)
# [23:27] * Quits: jarek (~jarek@aeap36.neoplus.adsl.tpnet.pl) (Changing host)
# [23:27] * Joins: jarek (~jarek@unaffiliated/jarek)
# [23:27] * Joins: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com)
# [23:27] * Parts: tgecho (~tgecho@66-55-201-102.gwi.net)
# [23:27] * Joins: tgecho (~tgecho@66-55-201-102.gwi.net)
# [23:28] <davatron5000> The problem with the <source> pattern is multiple codecs across various browsers. not @media, imo.
# [23:28] * Quits: mswartz (~textual@64.119.159.250) (Quit: Computer has gone to sleep.)
# [23:28] <MarcDrummond> Hixie: Just curious, in what ways is that markup pattern considered bad? I hadn't heard that.
# [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.
# [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
# [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
# [23:28] * Joins: mattgifford (~mattgiffo@108.161.20.199)
# [23:28] <Hixie> MarcDrummond: also we really haven't had much luck with media="" on <Source> so far for <video>
# [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
# [23:28] <Hixie> bjankord: you're still talking about solutions not problems :-)
# [23:28] <zewt> *blink*
# [23:29] <MarcDrummond> Hixie: Thanks. Helpful to understand those problems.
# [23:29] <Hixie> ShaneHudson: i think i listed the use cases that led to srcset="" in my big e-mail, are there others?
# [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
# [23:29] <Hixie> necolas: numerous lessons, e.g. the ones i just mentioned.
# [23:30] <necolas> sure, but those are lessons about the actual details
# [23:30] * Quits: eric_carlson (ericc@nat/google/x-pyurtiwfinnqjfms) (Quit: eric_carlson)
# [23:30] <bjankord> Hixie: Thanks for the feedback, good to know what direction to go from here.
# [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.
# [23:30] <TabAtkins> Do you mean "the lesson is: don't use <source> children"?
# [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
# [23:30] <ShaneHudson> Hixie: Well we realised that all the solutions have been focusing on different use-cases
# [23:30] * Quits: nicksergeant (~Nick@74.112.37.250) (Ping timeout: 250 seconds)
# [23:30] <ShaneHudson> tantek: good idea
# [23:31] <annevk> TabAtkins: it's not equivalent to max-width
# [23:31] <annevk> TabAtkins: because it would be used for a viewport of 700px
# [23:31] <annevk> (re mailing list)
# [23:31] <TabAtkins> annevk: Oh. So it's equivalent to min-width?
# [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".
# [23:31] * TabAtkins thinks the microsyntax for MQ is a bad idea.
# [23:31] <Hixie> ShaneHudson: in the threads i replied to i'm not sure that was the case, but it's certainly possible.
# [23:31] * Quits: bjankord (~bjankord@rrcs-98-100-97-130.central.biz.rr.com)
# [23:31] <annevk> TabAtkins: it's not a MQ microsyntax though
# [23:32] <Hixie> microsyntax for MQ?
# [23:32] <annevk> TabAtkins: e.g. 2x is not something MQ can do
# [23:32] <Hixie> srcset="" isn't mq
# [23:32] <TabAtkins> Hixie: The "100w 100h" part.
# [23:32] <TabAtkins> annevk: Yes, I'm only talking about the w/h part.
# [23:32] <Hixie> that's just describing the environment for the image, it's not a mq-equivalent
# [23:32] <jgraham> that is a really limited subset of mq
# [23:32] <Hixie> it doesn't evaluate to true or false
# [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
# [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.
# [23:33] <jgraham> necolas: Video had *lots* of discussion and changes to the design
# [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.
# [23:33] <necolas> im just interested if that is considered one of the lessons learnt, rather than trying to make judgements
# [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.
# [23:33] <Hixie> TabAtkins: i don't understand the relevance of mq here
# [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
# [23:33] <annevk> adactio: based on the use cases to date
# [23:33] * Joins: zachleat_ (~zachleat@ext-B14-1658.omhq.uprr.com)
# [23:34] <jgraham> zewt: Well it's not actually describing the image
# [23:34] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Remote host closed the connection)
# [23:34] <zewt> jgraham: describing attributes about the image
# [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
# [23:34] <necolas> jgraham: in those discussions, were concerns about verbosity, orphan <source>, rendering logic discussed? or did it not occur at the time?
# [23:34] * Quits: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com) (Read error: Connection reset by peer)
# [23:34] * zachleat_ is now known as zachleat
# [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.
# [23:34] <jgraham> It's describing some things about the browser environment that will be used to pick the right image
# [23:34] <TabAtkins> Hixie: Correct?
# [23:34] * Joins: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
# [23:34] * Joins: hartless (6c496899@gateway/web/freenode/ip.108.73.104.153)
# [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>)
# [23:35] <Hixie> necolas: so it's not that we made a bad decision
# [23:35] <Hixie> necolas: it did teach us that the decision is not as obviously good as one would have thought
# [23:35] <Hixie> TabAtkins: not really
# [23:35] <Hixie> TabAtkins: the browser can pick whichever image it wants
# [23:35] <Hixie> TabAtkins: there's a recommended algorithm that picks the image based on some priorities
# [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
# [23:36] <Hixie> TabAtkins: but even that algorithm doesn't knock things out necessarily
# [23:36] <jgraham> Hixie: BTW "return a random image" in the spec is wrong
# [23:36] <necolas> you live and learn
# [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
# [23:36] <jgraham> "return an image according to an algorithm of the UA's choosing" would be right
# [23:36] * Quits: duecaja (~jamesduec@cpe-24-93-190-62.neo.res.rr.com) (Quit: duecaja)
# [23:36] <Hixie> necolas: yes, all the lessons we learn with everything we do impact how we make future decisions
# [23:37] <hober> jgraham: agreed
# [23:37] <Hixie> jgraham: did i really say "random" in the spec text?
# [23:37] * Quits: GAmini (407dba52@gateway/web/freenode/ip.64.125.186.82) (Quit: Page closed)
# [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."
# [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?
# [23:37] <Hixie> jgraham: oh man. let me fix that.
# [23:38] <TabAtkins> Hixie: Yeah, the "if nothing matches, choose X" is fine. But aside from that, it acts like a strict filter, right?
# [23:38] <jgraham> Heh
# [23:38] <Hixie> necolas: of course. that happens with everything we do.
# [23:38] <jgraham> TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates
# [23:38] <Hixie> necolas: at the end of the day though it's better to have something mediocre than nothing at all.
# [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
# [23:39] <Hixie> TabAtkins: well, modulo the way the UA can do whatever it wants, sure
# [23:39] <necolas> Hixie: in which case, what was compelling enough to add it to the draft before further discussion could take place?
# [23:39] <zewt> TabAtkins: step 16 means "the browser can come up with its own decision/heuristics", from what I understand
# [23:39] <zewt> (the "random" line they're talking about)
# [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.
# [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")
# [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.
# [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
# [23:41] <Hixie> MarcDrummond: the format is intentionally extensible
# [23:41] * Quits: tkadlec (~tkadlec@71-87-1-124.static.eucl.wi.charter.com) (Quit: tkadlec)
# [23:41] <Hixie> MarcDrummond: but in general unless there's something specific you have in mind, it's good to not be open-ended.
# [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
# [23:41] <annevk> wow http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html is an instant classic
# [23:41] <zewt> TabAtkins: (oh. it says as much in the note right below it. :)
# [23:42] <Hixie> jgraham: fixed
# [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
# [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.
# [23:43] <jgraham> Hixie: Thanks
# [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.
# [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
# [23:44] <Hixie> TabAtkins: certainly they're in a similar space, sure
# [23:44] * Joins: duecaja (~duecaja@cpe-24-93-190-62.neo.res.rr.com)
# [23:44] <annevk> zewt: yeah
# [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.
# [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.
# [23:45] <annevk> zewt: doesn't seem like anyone got through in time :(
# [23:45] <Hixie> MarcDrummond: (assuming the only thing you need for print images is an even higher res)
# [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)
# [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.
# [23:46] <zewt> i wasn't following those threads; too much traffic vs. not enough personal interest in the subject
# [23:46] <annevk> zewt: yep, guess I'll be doing more careful reading of threads I'm not too interested in going forward
# [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
# [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!
# [23:46] <annevk> at least to make sure nobody is pointing people away from where they should be...
# [23:46] * Quits: zachleat (~zachleat@ext-B14-1658.omhq.uprr.com) (Quit: Colloquy for iPad - http://colloquy.mobi)
# [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
# [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.
# [23:47] <Hixie> MarcDrummond: are you aware of anyone trying to do that?
# [23:47] <ShaneHudson> Hixie: Could I have an account on the whatwg wiki please?
# [23:47] <zewt> MarcDrummond: that'd be an easy addition: add a greyscale flag
# [23:47] <Hixie> ShaneHudson: e-mail?
# [23:47] <ShaneHudson> Hixie: shane@shanehudson.net
# [23:48] <TabAtkins> zewt: I don't think that's scalable, honestly. Translating a significant set of MQ into the srcset microsyntax is silly.
# [23:48] <necolas> Hixie: that's true.
# [23:48] <jgraham> TabAtkins: Is there any evidence it is a significant set?
# [23:48] <Hixie> ShaneHudson: account details in the mail
# [23:48] <TabAtkins> jgraham: I dunno.
# [23:48] <ShaneHudson> Hixie: Thank you :)
# [23:49] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
# [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.
# [23:49] <Hixie> hence it not being one of the use cases i considered
# [23:49] <TabAtkins> 'A
# [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.
# [23:49] <TabAtkins> Actually, looking over MQ, the only one I might consider useful is the grayscale one.
# [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?
# [23:49] <TabAtkins> So, shrug.
# [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"
# [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.
# [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?
# [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
# [23:50] <divya> necolas++
# [23:51] <annevk> Hixie: maybe we should rename "Contribute" to "Join" on http://www.whatwg.org/
# [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.)
# [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.
# [23:51] <Hixie> zewt: it could just be "mono"
# [23:51] <annevk> although it does state pretty clearly already everyone can make proposals
# [23:51] <necolas> TabAtkins: again, you seem to think it is *our* job to correct your failings
# [23:51] <divya> exactly
# [23:52] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
# [23:52] <annevk> but "Join" is nicer and more what we mean than "Contribute" I think; it's a community after all
# [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...
# [23:52] <necolas> Fortunately, hixie has done a better job of explaining the situation
# [23:52] * Joins: joeellis (b8bf3910@gateway/web/freenode/ip.184.191.57.16)
# [23:53] <jgraham> Pretty sure the only kind of community you have to join is a gated one
# [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)
# [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.
# [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.
# [23:53] <annevk> jgraham: so leave Contribute? :)
# [23:53] <TabAtkins> Shrug.
# [23:53] <Hixie> annevk: done
# [23:54] <jgraham> annevk: I think so :)
# [23:54] <necolas> TabAtkins: to be fair, you were the one who started suggesting that the problem lay with *us* and "egos" etc.
# [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
# [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!
# [23:54] <Hixie> jgraham: we tried contribute for a while, let's try join for a while and see if it helps :-)
# [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.
# [23:55] <zewt> when i decided to look at specs, i just subscribed to webapps and whatwg and started reading, heh
# [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".
# [23:55] <Hixie> ShaneHudson: ah, yeah, if you approached the w3c then i could see why you'd get that impression
# [23:55] <zewt> (couldn't say how I stumbled across the lists in the first place)
# [23:55] <Hixie> ShaneHudson: unfortunately we cannot control the w3c's messaging
# [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
# [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.
# [23:55] <Hixie> necolas: if you have any ideas i'm all ears
# [23:56] <Hixie> necolas: but i don't think just talking more would have achieved that
# [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/
# [23:56] <zewt> if there's anything whatwg doesn't lack, it's talking more :)
# [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
# [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)
# [23:56] <divya> Hixie: completely agreed.
# [23:56] <necolas> TabAtkins: and fwiw, no hard feelings. i know you have the right intentions
# [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.
# [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
# [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.
# [23:58] * Joins: bradbice (~bradbice@209.117.183.2)
# [23:58] <TabAtkins> divya: Heh, every single CSS property in existence is a brand new microsyntax to learn. ^_^
# [23:58] <Hixie> ShaneHudson: good idea. any idea how one of us can go about writing an article for ALA?
# [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.
# [23:59] <annevk> isn't sharing the syntax with image-set therefore good?
# [23:59] <adactio> Hixie: write the article. Send it to ALA. I can put you in touch if you want.
# [23:59] <divya> TabAtkins: at the minimum they have adaptability, or some level of consistency with other syntaxes
# [23:59] <TabAtkins> annevk: It's the "NNNw NNNh" part that's new.
# Session Close: Wed May 16 00:00:00 2012

The end :)