| 00:03 | <jamesr> | the flow control situation is interesting for offscreen stuff |
| 00:39 | <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) |
| 00:39 | <jamesr_> | everything in a page is vsync'd together |
| 00:39 | <zewt> | not if the page spans monitors |
| 00:40 | <jamesr_> | doesn't matter |
| 00:40 | <jamesr_> | everything within a page is rendered at the same time |
| 00:40 | <zewt> | it's not rendering, it's backbuffer flipping |
| 00:40 | <jamesr_> | that's not a concern of the web platform. the backbuffer is prepared for everything in the page at the same time |
| 00:40 | <zewt> | rendering happens when it happens (with webgl) |
| 00:40 | <zewt> | not with webgl it isn't |
| 00:41 | <jamesr_> | sure it is |
| 00:41 | <zewt> | it isn't? heh |
| 00:41 | <jamesr_> | draw ops in webgl to the webgl backbuffer happen whenever |
| 00:41 | <jamesr_> | those are resolved/flipped/copied into the rest of the system as an independent step (not observable from the web directly) |
| 00:41 | <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) |
| 00:42 | <jamesr_> | no |
| 00:42 | <zewt> | the point is that you want to begin rendering right after vsync, and that depends on the monitor |
| 00:42 | <jamesr_> | it has to go to at least one intermediate buffer |
| 00:42 | <jamesr_> | and nothing at all depends on which monitor an element lands on |
| 00:43 | <zewt> | these are all implementation details; what matters is when you want to begin rendering, which is as close after vsync as possible |
| 00:44 | <jamesr_> | yes. in the multimonitor case, just pick some monitor and go |
| 00:44 | <jamesr_> | i've heard of some non-web systems picking the monitor with the largest area of intersection with the window |
| 00:44 | <zewt> | not some monitor; you want to pick the monitor the element is on, whenever possible |
| 00:44 | <jamesr_> | no |
| 00:44 | <zewt> | can you say something more informative than "no"? heh |
| 00:44 | <jamesr_> | it doesn't make any difference what monitor the element is on |
| 00:44 | <zewt> | why would you ever not do that? |
| 00:44 | <jamesr_> | because individual elements are not flipped independently |
| 00:45 | <jamesr_> | the whole buffer is prepared at once |
| 00:45 | <jamesr_> | and then made available to every monitor |
| 00:45 | <jamesr_> | and then made available to every monitor |
| 00:45 | <zewt> | how would you know that? heh |
| 00:45 | <zewt> | it's an implementation detail, and a good implementation would sync as close to each monitor as possible |
| 00:46 | <jamesr_> | i know that because i'm an implementor? |
| 00:46 | <zewt> | of every implementation ever? |
| 00:46 | <jamesr_> | an implementation as you describe would be infeasible |
| 00:46 | <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 |
| 00:47 | <zewt> | (clearly someone at webkit agrees, if their requestAnimationFrame takes an element) |
| 00:47 | <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 |
| 00:48 | <jamesr_> | you can't cite a nebulous "someone at webkit" against me when that someone is me |
| 00:48 | <zewt> | okay i don't feel like a condescending conversation right now |
| 00:48 | <zewt> | later |
| 00:48 | <jamesr_> | it really gets my goat when people say "implementations do X or could easily do X" when that's clearly not true |
| 00:49 | <zewt> | uh huh |
| 05:50 | <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." |
| 05:50 | <AryehGregor> | "equal to"? |
| 05:50 | <AryehGregor> | Oh, I guess everything runs single-threaded, so it's not a deadlock. |
| 06:14 | <matjas> | in which cases must `>` be escaped in HTML? I can only think of unquoted attribute values |
| 06:15 | <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. |
| 06:17 | <AryehGregor> | Maybe in <textarea> if preceded by "</textarea", and likewise for <title>? |
| 06:17 | <AryehGregor> | That's not relevant if you're really asking "which characters do I have to escape?" and are already escaping <. |
| 06:21 | <AryehGregor> | There are other cases where ">" isn't allowed, but it can't be escaped in those cases. |
| 06:21 | <AryehGregor> | Like attribute names, or certain configurations within <script>/<style>/comments. |
| 06:24 | <matjas> | AryehGregor: thanks for confirming. that’s indeed the use case here, escaping HTML (and `<` is being escaped) |
| 07:29 | <Hixie> | phew |
| 07:30 | <Hixie> | finally caught up with the tsunami |
| 07:38 | Ms2ger | didn't hear about a tsunami in the Bay Area |
| 07:38 | <Hixie> | the responsive tsunami |
| 07:38 | <Hixie> | been replying to that thread for like a week now |
| 07:38 | <Ms2ger> | Oh, have fun with that :) |
| 07:38 | <Hixie> | every night i'm almost done |
| 07:38 | <Hixie> | i come back the next morning |
| 07:38 | <Hixie> | and it's run away again |
| 07:38 | <Hixie> | but i finally caught up! |
| 07:39 | <Ms2ger> | I would suggest fixing some bugs instead ;) |
| 07:40 | <Hixie> | bugs are on hold til i deal with mail |
| 07:40 | <Hixie> | which is a far bigger pile right now |
| 07:40 | <Hixie> | though i see from the chart that you've done a good amount of work on the bugs yourself! |
| 07:40 | <Hixie> | nice! |
| 07:41 | <Ms2ger> | Saddening how much junk accumulated, really :) |
| 07:41 | <Hixie> | heh |
| 07:49 | <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. |
| 07:50 | <matjas> | are the spec short URLs documented anywhere? if not I’ll take a stab at writing it up |
| 07:50 | <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 |
| 07:51 | <ShaneHudson> | For which one? |
| 07:52 | <matjas> | ShaneHudson: the multi-page and one-page versions of the HTML living standard |
| 07:52 | <ShaneHudson> | Ah, I have only seen the multi page so far |
| 07:53 | <matjas> | Hixie: heads up, http://www.whatwg.org/specs/ is missing a </strong> |
| 07:59 | <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! |
| 08:07 | <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. :-) |
| 08:09 | <ShaneHudson> | Yes, I asked everyone about 5pm GMT two days ago I believe |
| 08:09 | <ShaneHudson> | about 20 people said that they did not like srcset, and nobody said otherwise |
| 08:09 | <odinho> | ShaneHudson: What you do is reply to Hixie's email that came in just half an hour ago. |
| 08:09 | <ShaneHudson> | I am still reading it, it is extremeley long |
| 08:10 | <odinho> | ShaneHudson: Well, popularity contests is not the best way for specs to be made. Technical discussion and merit, however, is. |
| 08:11 | <ShaneHudson> | True of course, but have you not seen the discussions on the community group? |
| 08:11 | <ShaneHudson> | True of course, but have you not seen the discussions on the community group? |
| 08:11 | <[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 |
| 08:11 | <kennyluck> | ShaneHudson, you can join the W3C HTML WG and write a change proposal. |
| 08:11 | <kennyluck> | ShaneHudson, you can join the W3C HTML WG and write a change proposal. |
| 08:12 | <ShaneHudson> | I will reply to Hixie's email later today, so that I do not rush it |
| 08:12 | <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. |
| 08:12 | <Ms2ger> | [tm], have a look at the DOM4 Makefile ;) |
| 08:12 | <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 |
| 08:13 | <Ms2ger> | ShaneHudson, joining the HTML WG is generally a waste of time |
| 08:13 | <odinho> | ShaneHudson, kennyluck: No need joining HTML WG... Better to just take it up in WHATWG where it's discussed. |
| 08:14 | <Ms2ger> | If you've got technical arguments for your suggestions, you will find the WHATWG list is enough for you |
| 08:14 | <odinho> | Ms2ger: Heh, implictly saying what the other one is used for? |
| 08:15 | <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/ |
| 08:16 | <kennyluck> | I am not going to say if that's a waste of time or not. Other people will tell you. :p |
| 08:16 | <odinho> | ShaneHudson: I'm seconding Ms2ger by the way. |
| 08:16 | <jgraham> | Please don't fork the discussion into to a third group |
| 08:17 | <kennyluck> | That I agree. THough writing a change proposal is another thing. |
| 08:17 | <Ms2ger> | A bigger waste of time? :) |
| 08:17 | <kennyluck> | No idea. *shrug* |
| 08:18 | <odinho> | Hehe, I think we can discuss technical on the list first. |
| 08:18 | <jgraham> | Writing a change proposal isn't the best way to get the spec changed |
| 08:18 | <ShaneHudson> | kennyluck: Thank you for the link, I will bookmark it but for now will take the advice of Ms2ger and odinho |
| 08:18 | <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. |
| 08:18 | <jgraham> | The best way is to present convincing technical arguments that it is wrong |
| 08:19 | <jgraham> | kennyluck: I assume the goal is not "remove srcset" per-se but "enable a good design for adaptive image loading" |
| 08:19 | <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) |
| 08:19 | <odinho> | change proposal: http://w3cmemes.tumblr.com/post/22414849805 |
| 08:19 | <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. |
| 08:19 | <jgraham> | remysharp: What do you mean? |
| 08:20 | <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?". |
| 08:20 | <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?". |
| 08:20 | <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 |
| 08:20 | <odinho> | remysharp: That's more or less implied, -- but yes, it should say that. |
| 08:20 | <jgraham> | kennyluck: I hope the actual goal is not to be obstructionist, but to be constructive |
| 08:20 | <[tm]> | Ms2ger: thanks, looking now |
| 08:21 | <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. |
| 08:21 | <jgraham> | remysharp: Right, the browser would process the whole image tag at once and load the one correct resource |
| 08:21 | <ShaneHudson> | remysharp: haha! |
| 08:21 | <jgraham> | It's not implied, I assume |
| 08:21 | <odinho> | remysharp: Yes I know yes I know. :P I work in Opera. But it's still a draft under discussion :P |
| 08:21 | <ShaneHudson> | Yes I think we have all seen why the spec needs to be a tightly written as any contract |
| 08:21 | <jgraham> | Without reading the spec, I imagine it specifies which image resource should be displayed |
| 08:22 | <kennyluck> | jgraham, I am being constructive by giving ShaneHudson an answer he is looking for. |
| 08:22 | <jgraham> | Of course a browser could chose to load other resources if it wanted. But a browser *could* do anything |
| 08:23 | <jgraham> | kennyluck: I think it is more constructive to take the question a little less literally. |
| 08:23 | <odinho> | remysharp: It's specified. |
| 08:23 | <odinho> | remysharp: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data |
| 08:24 | <remysharp> | odinho: uses the word "updates" - should that be "load"? |
| 08:24 | <remysharp> | odinho: uses the word "updates" - should that be "load"? |
| 08:24 | <remysharp> | it seems to suggest it's resetting state (though I've not finished reading) |
| 08:24 | <odinho> | remysharp: load uses that algorithm. |
| 08:25 | <jgraham> | remysharp: first load seems like a special case of update |
| 08:25 | <jgraham> | ShaneHudson: FWIW I am *very* skeptical that anything involving media queries is the right solution |
| 08:26 | <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 |
| 08:26 | <jgraham> | Becauseit should only be possible to vary on 3 properties: viewport width, viewport height and display density |
| 08:26 | <othermaciej> | (the spec doesn't specify anything about prefetching) |
| 08:27 | <jgraham> | Reusing a general syntax but neutering it so that most things people expect to work don't work seems like a terrible idea |
| 08:27 | <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 |
| 08:27 | <jgraham> | Right, prefetching is an optimisation |
| 08:27 | <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 |
| 08:27 | <annevk> | remysharp: example of a browser vendor messing up that badly? |
| 08:27 | <remysharp> | video |
| 08:28 | <remysharp> | video referrers were missing from implementations |
| 08:28 | <remysharp> | it's not huge, but it was serious enough to nuke a few servers during hotlinking |
| 08:28 | <remysharp> | Specs are hard for "authors" to read - see appcache - and any ambiguity just makes everything harder for all involved |
| 08:29 | <annevk> | sure |
| 08:29 | <jgraham> | Right, that's why specs are hard to read |
| 08:29 | <jgraham> | (not just for authors, but they spend less time doing it) |
| 08:29 | <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 |
| 08:29 | <annevk> | I was just curious as doing more network requests than required is something all browsers try very hard to avoid |
| 08:30 | <jgraham> | Well, not entirely |
| 08:30 | <odinho> | ShaneHudson: You want to write very clearly what you want to do. Not getting stuck on *how* you want to do it. |
| 08:30 | <odinho> | ShaneHudson: That is the best and easiest way to reply and give feedback. |
| 08:31 | <jgraham> | I think many implementations of speculation can cause network requests that are later not used |
| 08:31 | <jgraham> | Or starting loading DOM-created elements before they are inserted |
| 08:31 | <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 |
| 08:31 | <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 |
| 08:33 | <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. |
| 08:34 | <odinho> | E.g. what the outcome is in different scenarios for the same page :-) |
| 08:34 | <annevk> | [tm]: I think you need to modify Overview.src.html quite a bit for that |
| 08:34 | <jgraham> | To be fair, that's only really if you disagree with the requirements presented so far |
| 08:34 | <annevk> | [tm]: e.g. it needs some kind of license switch I guess |
| 08:35 | <annevk> | [tm]: a style sheet switch |
| 08:36 | <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 |
| 08:36 | <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 |
| 08:37 | <odinho> | :-) |
| 08:40 | <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 |
| 08:41 | <odinho> | ShaneHudson: Nope, I was maybe thinking about replying to that. |
| 08:41 | <jgraham> | I don't see how bandwidth will ever be possible to solve in this way |
| 08:41 | <[tm]> | annevk: yeah, no worries |
| 08:41 | <[tm]> | working on it now |
| 08:41 | <jgraham> | And hopefully will become less of a problem over time |
| 08:41 | <annevk> | [tm]: you can probably base it on DOM or something |
| 08:41 | <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. |
| 08:42 | <annevk> | ShaneHudson: Hixie's email explains why bandwidth cannot be exposed as a meaningful metric |
| 08:42 | <annevk> | ShaneHudson: Hixie's email explains why bandwidth cannot be exposed as a meaningful metric |
| 08:42 | <[tm]> | need to get it done before plh goes on vacation, so we can his OK for FPWD transition |
| 08:42 | <[tm]> | annevk: I think I got it done for now |
| 08:42 | <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 |
| 08:42 | <annevk> | [tm]: he already gave his OK |
| 08:42 | <odinho> | annevk: It doesn't have to be exposed. As it will be an optimization, the browser can choose. |
| 08:42 | <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 |
| 08:42 | <odinho> | jgraham: Yeah, and we all know how bad that is :P |
| 08:42 | <jgraham> | This turns out to be *very* hard to get right |
| 08:43 | <odinho> | jgraham: But it's easier on phones. |
| 08:43 | <ShaneHudson> | Right I must be going, see you all later |
| 08:43 | <[tm]> | annevk: yeah, that was provisional on me actually getting it ready |
| 08:43 | <jgraham> | odinho: If you are on a data constrained plan, I suggest Opera mini :p |
| 08:43 | <annevk> | [tm]: oh lol, politics |
| 08:43 | <odinho> | jgraham: Because you can trust the OS knows if you're on GPRS, EDGE, 3G, Wifi. |
| 08:43 | <annevk> | [tm]: you'd think he would have heard of pubrules |
| 08:43 | <jgraham> | So? |
| 08:44 | <jgraham> | How to map that to "I want different assets" is decidedly non-obvious |
| 08:44 | <jgraham> | (on desktop you can also be on various different connection types, including some or all of those) |
| 08:44 | <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. |
| 08:45 | <odinho> | jgraham: Same with my main browser on my normal computer. NetworkManager also expose this information to programs running. |
| 08:45 | <annevk> | odinho: it seems you want the smallest image if you're on 3G as well because you're data-constrained |
| 08:45 | <annevk> | odinho: whereas someone with an iPad on 3G with no data constraints might not want that at all |
| 08:45 | <jgraham> | I have been on non-constrained 3G |
| 08:45 | <jgraham> | Right |
| 08:45 | <annevk> | odinho: so that doesn't seem like a meaningful metric |
| 08:45 | <odinho> | annevk: I'm not up to 1GB. |
| 08:45 | <annevk> | odinho: 1GB is constrained |
| 08:46 | <odinho> | Have any of you ever tried using GPRS? |
| 08:46 | <jgraham> | So a user would have to manually map connection type to desired assets |
| 08:46 | <jgraham> | It would be insane |
| 08:46 | <odinho> | It's very slow. |
| 08:46 | <annevk> | odinho: I know |
| 08:46 | <jgraham> | We can't have a feature that requires UI that no one would implement |
| 08:46 | <odinho> | My computer knows when I'm on GPRS. |
| 08:46 | <odinho> | I don't see why it couldn't just take the lightest assets when I am. |
| 08:47 | <annevk> | odinho: how many assets do you think the page is going to provide though? |
| 08:47 | <jgraham> | In that case I would probably turn on turbo/use mini |
| 08:48 | <jgraham> | And not rely on athors to get it right |
| 08:48 | <annevk> | yeah |
| 08:49 | <odinho> | annevk: Well, many sites are CMS driven, mine are, and I guess something like 280w, 576w, 1024w. |
| 08:50 | <odinho> | Yeah, Opera mini/turbo is a better fix, -- but it does rely on proxy servers. |
| 08:51 | <jgraham> | Sure |
| 08:51 | <jgraham> | Anyway, there was a solution to this problem in HTML |
| 08:51 | <jgraham> | lowsrc |
| 08:51 | <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. |
| 08:51 | <jgraham> | It didn't really go anywhere |
| 08:51 | <odinho> | So there needs to be no spec change. |
| 08:52 | <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. |
| 08:53 | <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 |
| 08:56 | <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. |
| 08:57 | <annevk> | that's already allowed |
| 08:57 | <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. " |
| 08:57 | <annevk> | rtfs? |
| 08:58 | <odinho> | annevk: I have. I'm not discussing with the spec, I'm discussing with jgraham, which is saying something else :-) |
| 08:59 | <jgraham> | I'm not saying something else |
| 08:59 | <jgraham> | I'm saying having a feature for it in the spec is silly |
| 09:00 | <odinho> | jgraham: It doesn't really need a feature in the spec, -- because the current information should be enough. |
| 09:00 | <zcorpan> | Hixie: " |
| 09:00 | <zcorpan> | This seems like something that's currently relatively easily handled using |
| 09:00 | <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 |
| 09:00 | <zcorpan> | This seems like something that's currently relatively easily handled using |
| 09:00 | <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 |
| 09:03 | <[tm]> | annevk: can I add you as a co-editor on the URL spec? |
| 09:07 | <annevk> | [tm]: if arv is going to edit I don't think it's needed for me to be listed there |
| 09:12 | <[tm]> | OK |
| 09:13 | <[tm]> | annevk: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 09:14 | <[tm]> | I made a new make target |
| 09:14 | <[tm]> | WD target |
| 09:14 | <[tm]> | so we just flip it back to the "publish" target after WD publication |
| 09:15 | <[tm]> | anyway, break time here |
| 09:15 | <annevk> | [tm]: what I do these days is generate a TR.html copy so the editor's draft is not affected |
| 09:15 | <[tm]> | thank God almighty |
| 09:15 | <annevk> | heh |
| 09:16 | <[tm]> | annevk: OK, I can switch it to that later today |
| 10:13 | <annevk> | hmm |
| 10:14 | <annevk> | people on the WHATWG list don't seem to understand how pixel density affects images in practice |
| 10:14 | <annevk> | oh well |
| 10:19 | <othermaciej> | people seem not to get the fact that the pixel density you provide affects how the image renders |
| 10:19 | <othermaciej> | I'm not sure why this is hard to grasp (apparently) |
| 10:20 | <othermaciej> | people doing native iOS development seem to understand how 2x images fit into the picture |
| 10:20 | <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 |
| 10:22 | <annevk> | or I give feedback on how constraining URLs is not a good idea |
| 10:22 | <annevk> | "I've seen no objections about that aspect in the Community Group thread, where a number of authors have given feedback." |
| 10:22 | <annevk> | well I just gave you some |
| 10:23 | <jgraham> | Yeah, the implication that the source of the feedback somehow trumps its actual merit is distressing |
| 10:34 | annevk | stops with http://xkcd.com/386/ and goes to do something else |
| 10:39 | <othermaciej> | heh |
| 10:48 | <annevk> | so should we add new Range()? |
| 10:52 | <[tm]> | annevk: fyi, I reverted http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html to being unmolested |
| 10:52 | <[tm]> | and made a TR.html for the TR version |
| 10:52 | <[tm]> | http://dvcs.w3.org/hg/url/raw-file/tip/TR.html |
| 10:52 | <annevk> | ta |
| 10:53 | <annevk> | [tm]: you should probably change the <title> and "Living Draft" in the <h2> does not work either for a TR publication |
| 10:55 | <[tm]> | hai |
| 11:02 | <annevk> | AryehGregor: how is the detach() experiment going? |
| 11:03 | <annevk> | Ms2ger: should we add baseLang? |
| 11:03 | <annevk> | we should have a better name ideally... |
| 11:04 | <Ms2ger> | What's baseLang? |
| 11:05 | <annevk> | language of the node/element |
| 11:06 | <annevk> | as determining it through script is non-trivial |
| 11:06 | <Ms2ger> | Hmm |
| 11:06 | <annevk> | can baseURI still be null btw? |
| 11:07 | <annevk> | DOMString? looks like a bug if everything starts with about:blank |
| 11:10 | <[tm]> | kinuko has landed a first draft of the Quota API spec: http://dvcs.w3.org/hg/quota/raw-file/default/Overview.html |
| 11:12 | <annevk> | respec :/ |
| 11:14 | <[tm]> | yeah |
| 11:16 | <annevk> | emailed some feedback to public-webapps |
| 11:16 | <annevk> | I assumed he's subscribed since I didn't find an email address |
| 11:38 | <annevk> | language barrier ftl https://www.w3.org/Bugs/Public/show_bug.cgi?id=17042 |
| 11:47 | <annevk> | zcorpan: hey yt? |
| 11:47 | <annevk> | zcorpan: you reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=16712 |
| 11:47 | <annevk> | zcorpan: I'm trying to figure out how you could ever hit that case 2 |
| 11:47 | <annevk> | zcorpan: because it seems case 1 covers it aleady |
| 11:48 | <zcorpan> | annevk: the element doesn't have a prefix |
| 11:53 | <annevk> | zcorpan: exactly, so its namespace prefix equals prefix |
| 11:53 | <annevk> | zcorpan: they're both null |
| 11:53 | <zcorpan> | annevk: /prefix/ is "bar" |
| 11:55 | <annevk> | zcorpan: right |
| 11:56 | <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? |
| 11:56 | <annevk> | zcorpan: hmm I guess so |
| 11:56 | <annevk> | aah namespaces |
| 11:56 | <zcorpan> | :) |
| 11:58 | <zcorpan> | "or whose namespace prefix is null and local name is "xmlns" if prefix is null:" |
| 11:58 | <zcorpan> | (possibly also check the namespace of the "xmlns" attribute) |
| 11:58 | <zcorpan> | (possibly also check the namespace of the "xmlns" attribute) |
| 11:58 | <annevk> | I think I'll add some words for clarity |
| 12:06 | <annevk> | man this is some long sentence :( |
| 12:14 | <[tm]> | annevk: kinuko is a woman, btw |
| 12:15 | <zcorpan> | annevk: looks good |
| 12:15 | <[tm]> | and she is subscribed to public-webppas |
| 12:17 | <annevk> | cool cool |
| 12:17 | <annevk> | cool cool |
| 12:18 | <annevk> | is it just the -o or -ko that indicates the name of a woman in Japan? |
| 12:22 | <annevk> | Ms2ger: garbage collection in DOM |
| 12:23 | <annevk> | Ms2ger: where should we put that |
| 12:23 | <annevk> | yeah leave the channel alright |
| 12:23 | <annevk> | chicken |
| 12:23 | <annevk> | chicken |
| 12:23 | <[tm]> | annevk: -ko |
| 12:24 | <charlvn> | there are japanese men who also have names ending in -o or -ko afaik |
| 12:24 | <[tm]> | yeah |
| 12:24 | <charlvn> | although i think -ko is more common with female names |
| 12:26 | <[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 |
| 12:26 | <annevk> | ah, the chicken returns :) |
| 12:27 | <[tm]> | I think the men's names are usually -hiko |
| 12:27 | <charlvn> | [tm]: sounds right |
| 12:28 | <Ms2ger> | Hah |
| 12:28 | <Ms2ger> | annevk, in the closet? |
| 12:29 | <annevk> | ideally, but smaug____ wants it |
| 12:29 | <annevk> | HTML has http://www.whatwg.org/specs/web-apps/current-work/#garbage-collection |
| 12:29 | <smaug____> | what do I want? |
| 12:29 | <annevk> | garbage collection notes in DOM |
| 12:30 | <smaug____> | not really gc, but definition of ownership |
| 12:30 | <smaug____> | or definition in which cases certain objects won't be deleted |
| 12:30 | <Ms2ger> | Everything owns everything :) |
| 12:31 | <smaug____> | whether gc is used internally, is implementation detail |
| 12:33 | <annevk> | not really sure we have to say much then |
| 12:33 | <annevk> | other than that sentence of HTML |
| 12:33 | <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 |
| 12:36 | <smaug____> | "Unless disconnect() is called, MutationObserver observes node as long as the node exists" |
| 12:36 | <smaug____> | something like that |
| 12:37 | <annevk> | that doesn't mean much |
| 12:39 | <smaug____> | it doesn't ? |
| 12:39 | <smaug____> | it means that the MutationObserver doesn't die even if you don't keep a reference to it |
| 13:14 | <[tm]> | btw, http://lists.w3.org/Archives/Public/public-whatwg-archive/ is not available |
| 13:14 | <[tm]> | *now available |
| 13:16 | <annevk> | yeah noticed that yesterday |
| 13:16 | <annevk> | very cool |
| 13:16 | <[tm]> | now we should figure out how to add an Archived-at header to whatwg⊙wo messages |
| 13:29 | <zewt> | used to be you could just search for message-ids, but gmail makes it a pain to get it, which is annoying |
| 13:41 | <zcorpan> | [tm]: archived-at would be nice |
| 13:45 | <dbaron> | anybody know of a description of the advantages of WebVTT over TTML (or some subset thereof)? |
| 13:48 | <annevk> | dbaron: http://lists.w3.org/Archives/Public/public-html/2010May/0160.html |
| 13:49 | <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? |
| 13:50 | <dbaron> | (may or may not actually be the case, but under discussion) |
| 13:50 | <annevk> | I guess that leaves the enormous amount of namespaces and complexity of having a lot of markup where something simpler does fine |
| 13:51 | <annevk> | and draconian error handling for a text format which would be a first as far as browser technology goes |
| 13:51 | <zewt> | annevk: i don't know anything about it, but that description makes it sound like they have no experience with web formats |
| 13:52 | <zewt> | brb reboot |
| 13:52 | <annevk> | TTML is badly designed |
| 13:53 | <annevk> | that's why we went with WebVTT |
| 13:53 | <zewt> | actually no reboot |
| 13:55 | <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 |
| 13:55 | <dbaron> | so what's going on is: |
| 13:55 | <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 |
| 13:55 | <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 |
| 13:55 | <zewt> | that sounds BS |
| 13:56 | <zewt> | (in the "not true" sense, not "it's stupid" sense) |
| 13:56 | <zewt> | (not that it wouldn't be the latter too :) |
| 13:57 | <annevk> | I heard about (b) too |
| 13:57 | <dbaron> | something from http://www.fcc.gov/encyclopedia/video-programming-accessibility-advisory-committee-vpaac |
| 13:57 | <annevk> | (a) does not matter much; W3C charters groups to work on silly stuff all the time |
| 13:57 | <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!" |
| 13:58 | <zewt> | http://lists.w3.org/Archives/Public/public-texttracks/2012Apr/0001.html |
| 13:58 | <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 |
| 13:59 | <dbaron> | apparently it would be VPAAC WG1 |
| 13:59 | <Ms2ger> | espadrine, Ha. Ha. Ha. |
| 14:00 | <dbaron> | apparently the bigger problem is that everybody implements a different subset of TTML |
| 14:01 | <annevk> | isn't the bigger problem that it's a terrible format? |
| 14:01 | <dbaron> | meant the bigger problem with the requirement |
| 14:01 | <annevk> | thanks zewt |
| 14:01 | <dbaron> | but yes, that too |
| 14:01 | <zewt> | there's nothing else leading to the "something something federal requirement" noise, right? |
| 14:02 | <annevk> | during the F2F glenn mentioned it and a couple of people were like "yup that's correct; tough luck WebVTT guys" |
| 14:03 | <odinho> | Hehe, yeah, fear struck. |
| 14:03 | <zewt> | "that" glenn? heh |
| 14:03 | <annevk> | other glenn! |
| 14:03 | <dbaron> | SMPTE-TT is a profile (with additions) of TTML, no? |
| 14:03 | <dbaron> | not a container for it as that message implies? |
| 14:04 | <zewt> | captioning isn't rocket science; if you need *profiles* of a captioning format, something seems badly amiss |
| 14:04 | <jgraham> | Well clearly something *is* badly amiss |
| 14:04 | <zewt> | something usually is |
| 14:06 | <annevk> | dbaron: looks like a super-subset, yes |
| 14:07 | <annevk> | as in, it supersets a subset of TTML |
| 14:07 | <jgraham> | Isn't that what we call a "different format"? |
| 14:08 | <annevk> | it uses namespaces so it's cool |
| 14:08 | <zewt> | heh |
| 14:08 | <[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 |
| 14:08 | <zcorpan> | does it have 18 new namespaces? |
| 14:08 | <[tm]> | and look for "apparatus" |
| 14:08 | <zewt> | annevk: someone on the webgl list said he wants to push for using the URL-namespacing-gimmick to identify webgl extensions |
| 14:08 | <zewt> | raaaaaaaaage |
| 14:09 | <zewt> | re: xml tried that. it sucked. stop it |
| 14:09 | <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 ? |
| 14:09 | <annevk> | zewt: "feature" in object does not work anymore? |
| 14:09 | <annevk> | zewt: but yeah, ... |
| 14:09 | <zewt> | oh everything works fine |
| 14:09 | <zewt> | he just wanted to change to urls because *crickets* |
| 14:10 | <odinho> | [tm]: They sure say a lot of apparatus all over the place! |
| 14:10 | dbaron | heads back indoors |
| 14:11 | <zewt> | fortunately he didn't go on to push it, but it's astonishing that nonsense keeps cropping up |
| 14:12 | <jgraham> | Those damn crickets |
| 14:12 | <annevk> | http://cdn.memegenerator.net/instances/400x/20446042.jpg |
| 14:14 | <[tm]> | odinho: the section "A. Apparatus Subject to Section 203 of the Act |
| 14:17 | <odinho> | [tm]: Page 65 seems interesting. But nothing about TTML. |
| 14:17 | <[tm]> | odinho: "If a |
| 14:17 | <[tm]> | video programming owner provides captions to a video programming distributor or provider using the |
| 14:17 | <[tm]> | Society of Motion Picture and Television Engineers Timed Text format (SMPTE ST 2052-1:2010: |
| 14:18 | <[tm]> | “Timed Text Format (SMPTE-TT)” 2010) (incorporated by reference, see § 79.100), then the VPO has |
| 14:18 | <[tm]> | fulfilled its obligation to deliver captions to the video programming distributor or provider in an |
| 14:18 | <[tm]> | acceptable format. |
| 14:18 | <[tm]> | and "The VPAAC proposed that the Commission require a single standard interchange format |
| 14:18 | <[tm]> | so that video programming does not need to be re-captioned to comply with different standards. |
| 14:19 | <[tm]> | 508 |
| 14:19 | <[tm]> | The |
| 14:19 | <[tm]> | VPAAC proposed SMPTE-TT as the standard interchange format |
| 14:19 | <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. |
| 14:19 | <odinho> | But that last thing is not written in-doc as requirement, I guess? They only propose that as single standard? |
| 14:20 | <[tm]> | odinho: they are careful to not say it is "mandatory" |
| 14:20 | <[tm]> | but instead "safe harbor" |
| 14:20 | <[tm]> | I don't know that that particular term of art means |
| 14:20 | <[tm]> | e.g., "unlike adopting SMPTE-TT as the mandatory interchange or delivery format, commenters explain that a |
| 14:21 | <[tm]> | safe harbor approach would balance goals of efficiency, certainty, and consumer access with needed |
| 14:22 | <odinho> | e will also provide in our rules that devices that implement SMPTE-TT |
| 14:22 | <odinho> | will be deemed in compliance with our rules, while simultaneously allowing devices to achieve the same |
| 14:22 | <odinho> | functionality without implementing that standard.5 |
| 14:23 | <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. |
| 14:23 | <odinho> | So it seems it can be done ;-) |
| 14:54 | <zcorpan> | Hixie: which characters are supposed to be paragraph separators in WebVTT for the purpose of bidi? |
| 14:54 | <zcorpan> | just Bidi_Class=Paragraph_Separator ? |
| 14:55 | <zcorpan> | tr9 isn't really explicit about which characters it wants to consider paragraph separators |
| 14:57 | <zcorpan> | e.g. U+2028 isn't class B, but i can't tell if it's an "appropriate Newline Function" or not |
| 15:00 | <odinho> | I surely don't understand why some people are so agressively against srcset. And noone can say why. |
| 15:00 | <odinho> | (... reading twitter) |
| 15:02 | <zcorpan> | oh, i think i found the definition of "newline function" now |
| 15:02 | <[tm]> | odinho: you can save yourself the confusion by not reading twitter :) |
| 15:03 | <zcorpan> | so newline function is platform-dependent, but none of the platforms listed as examples use any non-B-class character as newline function |
| 15:03 | <zcorpan> | so it's just B class |
| 15:14 | <TabAtkins_> | odinho: Because http://w3cmemes.tumblr.com/post/22831818920/the-css-wgs-primary-failure-mode , that's why. |
| 15:17 | <annevk> | "If you don't set your image's resolution appropriately, you'll get unexpected sizing effects." is not actually true |
| 15:17 | <annevk> | browsers ignore the DPI set in the image |
| 15:18 | <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. |
| 15:18 | <TabAtkins_> | At least, it won't be the same as a 96dpi image at 1x. |
| 15:18 | <odinho> | TabAtkins_: Yeah, thinking that. But saying it alound feels wrong... :] |
| 15:19 | <annevk> | TabAtkins: it's way easier to think about it in terms of pixel density rather than resolution |
| 15:19 | <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. |
| 15:19 | <annevk> | TabAtkins: e.g. everything from 90-130 is typically treated as 1x |
| 15:19 | <TabAtkins_> | annevk: Do image programs talk about pixel density? I thought they explicitly talked about "dpi" when saving an image. |
| 15:20 | <annevk> | TabAtkins: whereas 260-330ppi would be 2x |
| 15:20 | <annevk> | TabAtkins_: in an image program you would just make an image with twice the amount of pixels in each direction |
| 15:20 | <annevk> | TabAtkins_: you don't use the dpi setting because it is already ignored by browsers (and has to for compatibility) |
| 15:20 | <annevk> | I sort of thought everyone involved in the discussion knew this... |
| 15:20 | <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. |
| 15:20 | <annevk> | I sort of thought everyone involved in the discussion knew this... |
| 15:20 | <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. |
| 15:21 | <jgraham> | TabAtkins_: So someone should propose <srcset><img src="something.png"><source src="somethingelse.png" width=200 height=100 density=2></srcset> or something |
| 15:21 | <annevk> | you have a 10x10 image and a 20x20 image |
| 15:21 | <TabAtkins_> | annevk: Uh, yes, I know. |
| 15:21 | <TabAtkins_> | annevk: Uh, yes, I know. |
| 15:21 | <annevk> | the latter you set as 2x |
| 15:21 | <annevk> | you don't have to care about dpi |
| 15:22 | <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. |
| 15:22 | <annevk> | which is nice because it various all over |
| 15:22 | <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). |
| 15:22 | <TabAtkins_> | And when you talk about resolution, people will want to do that. |
| 15:23 | <jgraham> | When people talk about "size" they mean "in pixels", no? |
| 15:23 | <annevk> | if it's double resolution it's width and height will be larger |
| 15:23 | <TabAtkins_> | jgraham: Sometimes, sometimes not. When I start GIMP, I can create an image with a size in inches and a resolution in dpi. |
| 15:23 | <odinho> | TabAtkins_: <img src=10x10 srcset="20x20.jpg 2x"> is exactly equivalent to <img src=20x20.jpg width=10 height=10> |
| 15:24 | <TabAtkins_> | odinho: Yes, I know. |
| 15:24 | <annevk> | you cannot create an image of 10x10 with more detail and have it rendered as 10x10 |
| 15:24 | <TabAtkins_> | annevk: Yes, I know. |
| 15:24 | <annevk> | there's no such thing |
| 15:24 | <annevk> | well then I've no idea what you're talking about |
| 15:24 | <odinho> | :S |
| 15:25 | <jgraham> | annevk: TabAtkins_ seems to (sometimes) be using "size" to mean something that can be measured with a ruler |
| 15:25 | <TabAtkins_> | If you create a "5 inch wide" image at 192dpi, browsers will display it as 10 inches wide. |
| 15:25 | <jgraham> | It seems clearer to me to always use "size" to mean something in pixels |
| 15:26 | <jgraham> | Because, y'know, working out what real world dimensions you get isn't that easy or helpful |
| 15:27 | <annevk> | TabAtkins_: aren't all images stored as pixels in the end? |
| 15:27 | <TabAtkins_> | annevk: Yes? |
| 15:27 | <annevk> | so then I'm not sure why we have to talk about inches |
| 15:27 | <TabAtkins_> | The point is author expectations. |
| 15:27 | <annevk> | I think authors deal in pixels too |
| 15:27 | <TabAtkins_> | I'm not *sure* if authors think that way, but I suspect that some do. I dunno. |
| 15:27 | <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? |
| 15:27 | <annevk> | I certainly do when creating images |
| 15:27 | <odinho> | Ah, they're doomed anyway if they think about stuff like that. |
| 15:28 | <annevk> | necolas: <img> parsing is a lost cause |
| 15:28 | <annevk> | necolas: <img> parsing is a lost cause |
| 15:28 | <odinho> | Some print guys do, and they're always way off. Have to explain. |
| 15:28 | <TabAtkins_> | necolas: Changing the parsing of the <img> element is a lost cause. |
| 15:28 | <annevk> | necolas: adding attributes does not affect parsing |
| 15:28 | <TabAtkins_> | Dammit, annevk, why are you 2 seconds faster than me? |
| 15:28 | <necolas> | adding attributes doesn't help with polyfilling either |
| 15:28 | <odinho> | TabAtkins_: In europe? |
| 15:28 | <annevk> | TabAtkins_: Europe :p |
| 15:28 | <odinho> | FTW! |
| 15:28 | <jgraham> | necolas: I answered that once already today |
| 15:29 | <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 |
| 15:29 | <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 |
| 15:30 | <jgraham> | If you are trying to understand that, I see the problem |
| 15:30 | <jgraham> | You are working from a false premise |
| 15:30 | <necolas> | jgraham: you don't think having 2 http requests is a problem for polyfilling? |
| 15:30 | <necolas> | jgraham: and what premise would that be? |
| 15:30 | <jgraham> | "developers have been cast aside" |
| 15:31 | <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. |
| 15:31 | <necolas> | that isnt the goal |
| 15:31 | <TabAtkins_> | necolas: Oh. Then I don't understand what you mean by "2 http requests are a problem for polyfilling". |
| 15:31 | <necolas> | jgraham: [the work of] developers |
| 15:32 | <odinho> | necolas: <img srcset="cat.jpg, cat⊙2 2x"><noscript><img src=cat.jpg></noscript> <---- you can polyfill that without 2 HTTP requests. |
| 15:32 | <necolas> | TabAtkins_: the browser is going to request the image in `src` before any JS can get to work |
| 15:32 | <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. |
| 15:32 | <necolas> | odinho: yeah we've discussed that but dont think it is optimal |
| 15:33 | <TabAtkins_> | necolas: ...that's why I just suggested using only @srcset and omitting @src. |
| 15:33 | <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 |
| 15:34 | <jgraham> | necolas: The fact that people have brought up technical shortcomings does not mean that "the work has been cast aside" |
| 15:34 | <jgraham> | Wht do you think this is if not engagement? |
| 15:34 | <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. |
| 15:35 | <jgraham> | Seriously, if there are technical problems with the srcset proposal, point them out |
| 15:35 | <jgraham> | It's a way more useful use of everyone's time than complaining about lack of engagement |
| 15:35 | <necolas> | Aside from discussions of the technical merit, I'm saying you that the developer community doesn't feel like how you described, Tab. |
| 15:36 | <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. |
| 15:36 | <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. |
| 15:36 | <necolas> | I just wish there had been better communication |
| 15:36 | Philip` | thinks there ought to be a way of standardising the technically best solution without also alienating people who have proposed other solutions |
| 15:36 | <necolas> | TabAtkins_: this has nothing to do with whos solution is getting used |
| 15:37 | <TabAtkins_> | necolas: Do you think the discussion is completely over and this is a fait accompli? That's incorrect. |
| 15:37 | <dglazkov> | good morning, Whatwg! |
| 15:37 | <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. |
| 15:37 | <adactio> | What necolas said. |
| 15:37 | <odinho> | Philip`: Yes, sure. But it's not super easy if people feel hurt. |
| 15:38 | <necolas> | because, initially, responsive images was not of interest to you guys, we set up a CG |
| 15:38 | <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 |
| 15:38 | <TabAtkins_> | necolas: Again, I'm not sure how what has been happening is anything if not "hearing dev's interest". |
| 15:38 | <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 |
| 15:38 | <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. |
| 15:39 | <TabAtkins_> | How is this anything other than "you win, your arguments were right, here's a solution for your problem". |
| 15:39 | <necolas> | jgraham: that doesnt sound like an unpleasant experience :) |
| 15:39 | <necolas> | TabAtkins_: "thanks, we'll take over from here", right? |
| 15:39 | <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. |
| 15:39 | <jgraham> | The problem with being upset in technical discussions is that it doesn't scale very well. |
| 15:40 | <TabAtkins_> | (Also because voting is usually a bad way to make technical decisions.) |
| 15:40 | <jgraham> | You would end up being upset a lot of the time |
| 15:40 | <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. |
| 15:40 | <dglazkov> | oh cool, browserfolk vs. webdevfolk |
| 15:40 | <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. |
| 15:40 | <zcorpan> | fight! |
| 15:40 | dglazkov | is both. Should I be arguing with myself? |
| 15:40 | <jgraham> | Certianly *I* would if I was upset every time my initially-preferred solution didn't make the final spec |
| 15:40 | <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). |
| 15:40 | <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). |
| 15:40 | <zcorpan> | dglazkov: clearly you should hit yourself in your face |
| 15:41 | <dglazkov> | zcorpan: and enjoy it |
| 15:41 | <hober> | dglazkov: count me in! /me hits himself in the face too :) |
| 15:41 | jgraham | still thnks we should have done MathML by making browsers understand something like LaTeX |
| 15:41 | <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 :) |
| 15:41 | <jgraham> | Oh, right, Tuesday night is S&M night |
| 15:41 | <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. |
| 15:41 | <zcorpan> | jgraham: that was on the table before we put mathml in to html, wasn't it? |
| 15:42 | <jgraham> | zcorpan: Well I tried to convivce Hixie it was a good idea then |
| 15:42 | <jgraham> | I guess it would have been a lot of work |
| 15:42 | <jgraham> | But afaict it is still the most popular way of including MathML in HTML |
| 15:42 | <jgraham> | But implemented in Javascript |
| 15:42 | <annevk> | he tried to think of a scheme that implied a lot of the markup |
| 15:43 | <annevk> | but that didn't work out |
| 15:43 | <zcorpan> | annevk: iirc real LaTeX was also considered |
| 15:43 | <dglazkov> | whoa, how did we just switch from srcset to mathml? |
| 15:43 | <dglazkov> | is this the equivalent of Godwin's law in the standards discussions? |
| 15:44 | <dglazkov> | once LaTeX is mentioned... |
| 15:44 | <necolas> | odinho: oh of course. there are many aspects of being a web developer |
| 15:44 | <miketaylr> | probably all the punching in the face |
| 15:44 | <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 |
| 15:44 | <scottjehl> | hello! |
| 15:44 | <necolas> | annevk: i didn't say that |
| 15:44 | <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. ^_^ |
| 15:45 | <odinho> | TabAtkins_: Hehe, okay. In my limited experience in Opera though, most people were webdevs :-) |
| 15:45 | <hober> | TabAtkins_: that's why you, me, and some other people get to try to make sure that wg keeps it real. :) |
| 15:45 | <TabAtkins_> | odinho: Opera might be different, I dunno. |
| 15:46 | <TabAtkins_> | necolas: The bottom line is, if you don't like the solution, say so. Complaining about process is *very rarely* productive, however. |
| 15:46 | <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? |
| 15:46 | <TabAtkins_> | necolas: (But, hopefully, don't rehash criticisms that have already been answered, unless you have new information.) |
| 15:47 | <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 |
| 15:47 | <zcorpan> | just saying "this is not what i want!" is also not very useful, though. |
| 15:47 | <necolas> | that is not what i was saying |
| 15:47 | <TabAtkins_> | necolas: Once again, that is *exactly* what happened in this case. |
| 15:47 | <necolas> | i think it is fair to discuss the way that things get done |
| 15:47 | <zcorpan> | necolas: sorry, i didn't mean you, i just saw some bugs filed along those lines |
| 15:47 | <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. |
| 15:49 | <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. ^_^ |
| 15:49 | <TabAtkins_> | adactio: I believe the timing meant that at the time of writing, the CG was either not started yet, or just starting. |
| 15:49 | <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 |
| 15:50 | <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 |
| 15:50 | <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. |
| 15:51 | <TabAtkins_> | necolas: I don't like to characterize it as sour grapes, but that's what it feels like to me. |
| 15:51 | <necolas> | well you'd be wrong |
| 15:51 | <necolas> | and i don't think you should dismiss this like that |
| 15:52 | <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). |
| 15:52 | <necolas> | most of us have pretty much nothing invested in the ideas themselves - they all came in some form from earlier mailing list ideas. |
| 15:52 | <necolas> | TabAtkins_: hah, but wilcox is always unhappy :) |
| 15:52 | <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. |
| 15:52 | <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. |
| 15:53 | <necolas> | definitely |
| 15:53 | <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. ^_^ |
| 15:53 | <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 |
| 15:54 | <necolas> | TabAtkins_: [facepalm] it's not about ego either |
| 15:54 | <jgraham> | *usable |
| 15:54 | <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". |
| 15:55 | <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. |
| 15:56 | <necolas> | TabAtkins_: have that kind of thing filter down to the CG itself would be a great start |
| 15:56 | <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. |
| 15:56 | <TabAtkins_> | necolas: Feel free to forward the email to the CG, then! |
| 15:57 | <TabAtkins_> | bbiab |
| 15:57 | <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 |
| 15:57 | <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. |
| 15:57 | <Wilto> | So. |
| 15:58 | <divya> | adactio: fwiw there are some concerns raised about picture element |
| 15:58 | <annevk> | adactio: actually hober knew about <picture> |
| 15:58 | <divya> | as there are w.r.t srcset. |
| 15:58 | <annevk> | adactio: and used that in his evaluation |
| 15:58 | <zewt> | (hard to take people seriously when they use words like "obstreperous") |
| 15:58 | <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. |
| 15:58 | <odinho> | scottjehl: If giving feedback, it has to be on the mailing list for it to be seen and replied to. |
| 15:58 | <divya> | (lol zewt) |
| 15:58 | <annevk> | adactio: and <picture> and variants has come up since 2007 or so |
| 15:58 | <annevk> | adactio: it's not a recent invention |
| 15:58 | <zewt> | odinho: heh my thought was "we're hiding discussions away on github now?" |
| 15:58 | <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. |
| 15:59 | <annevk> | adactio: popped up shortly after I proposed <video> I think |
| 15:59 | <adactio> | zewt: Apologies. I'll try not to use words of more than three syllables from now on. *sheesh* |
| 15:59 | <zewt> | (sarcasm is worse) |
| 15:59 | <Wilto> | Meanwhile, the only missive from the WHATWG on `img set` seems to be this: http://junkyard.damowmow.com/507 |
| 15:59 | <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 |
| 15:59 | <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. |
| 15:59 | <Wilto> | And moreover, to wonder whether any `process` exists here in the first place. |
| 16:00 | <Wilto> | Or if merit is simply based on the fact that things were—or were not—“invented here.” |
| 16:00 | <annevk> | Wilto: the way the WHATWG works is that people email and the editor takes those emails and produces a proposal |
| 16:00 | <annevk> | Wilto: usually that proposal goes directly in the spec, sometimes he puts up something on damwmow.com or other |
| 16:00 | <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. |
| 16:01 | <Wilto> | This was a decision made in a vacuum. Let’s not pretend there was any process involved. |
| 16:01 | <Wilto> | The only repeated defense has been “this is easier for implementors.” |
| 16:01 | <annevk> | Wilto: people emailed, Hixie replied with a proposal... |
| 16:01 | <Wilto> | And Hixie proceeded despite the response. |
| 16:01 | <annevk> | Wilto: I guess you haven't read the email then |
| 16:02 | <necolas> | annevk: so what are the CG designed for, just so we know in the future? |
| 16:02 | <Wilto> | I don’t care how many times I’m told “we considered feedback.” |
| 16:02 | <annevk> | necolas: the WHATWG has a WHATCG for patent reasons |
| 16:02 | <Wilto> | If none of that feedback is incorporated, we’re just being humored further. |
| 16:03 | <annevk> | necolas: I think in general they're used as a discussion group |
| 16:03 | <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? |
| 16:03 | <necolas> | annevk: so, people discuss in a CG, then email hixie? |
| 16:03 | <odinho> | Wilto: Have you read the feedback? |
| 16:03 | <Philip`> | I like how the spec says "(Steps in synchronous sections are marked with .)" in my font |
| 16:03 | <annevk> | necolas: there's never been a CG for any part of HTML before really; I'm not sure why people made one now |
| 16:04 | <Philip`> | (Looks like there's meant to be some visible character there instead) |
| 16:04 | <Wilto> | Let me be frank: |
| 16:04 | <zewt> | (what does "developer support" mean? popularity is a fairly low factor in spec decisions, i think) |
| 16:04 | <annevk> | necolas: making a CG when there's already a group for HTML seems like the mistake that was made here |
| 16:04 | <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 |
| 16:04 | <odinho> | accepted, it's clear that the time *was* useful. |
| 16:04 | <Wilto> | I do not care about Hixie’s opinion, any more than anyone should care about mine. |
| 16:04 | <zewt> | (bad ideas can become popular) |
| 16:04 | <Wilto> | This is all, frankly, a little sad. |
| 16:05 | <Wilto> | I’ve seen seen no defense of `img set` on technical merit. |
| 16:05 | <Wilto> | Where are the published use cases? |
| 16:05 | <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? |
| 16:05 | <odinho> | Wilto: ...? |
| 16:05 | <necolas> | if yes, then shut them all down |
| 16:05 | <annevk> | necolas: we're not the W3C |
| 16:05 | <necolas> | yeah, i was just talking aloud |
| 16:05 | <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 |
| 16:06 | <odinho> | Wilto: Have you read the full threads on WHATWG, and are you honestly meaning that? |
| 16:06 | <necolas> | but if people are being sent to CG's, and they have no worth, then that isn't great |
| 16:06 | <annevk> | necolas: and most CGs are not about changing HTML |
| 16:06 | <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? |
| 16:06 | <annevk> | necolas: if you want to change HTML you should not set up a CG, for anything else they're probably great |
| 16:06 | <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 |
| 16:06 | <necolas> | so HTML CG's are worthless, CSS CG's are ?, other CG's are ? |
| 16:06 | <odinho> | Wilto: It's easy to polyfill. Tell us why it's not. |
| 16:07 | <annevk> | necolas: I don't think there are CSS CGs either |
| 16:07 | <odinho> | 17:33 < odinho> necolas: <img srcset="cat.jpg, cat⊙2 2x"><noscript><img src=cat.jpg></noscript> <---- you can polyfill that without 2 HTTP requests. |
| 16:07 | <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. |
| 16:07 | <necolas> | jgraham: does srcset have browser vendors on board? |
| 16:07 | <Wilto> | odinho: That will result in two requests in browsers with JS on. |
| 16:07 | <necolas> | i bet that more people working for browser vendors were aware of our CG than this proposal |
| 16:07 | <odinho> | Wilto: No, it will not. Take a new look. No src attribute. |
| 16:07 | <adactio> | So much for the priority of constituencies. |
| 16:07 | <jgraham> | necolas: Browser vendors pay attention to the WHATWG at least |
| 16:07 | <adactio> | So much for the priority of constituencies. |
| 16:07 | <jgraham> | necolas: Browser vendors pay attention to the WHATWG at least |
| 16:08 | <scottjehl> | odhino src is required via the HTML spec |
| 16:08 | <Wilto> | odinho: So, in non-supporting browsers without JavaScript: no image. |
| 16:08 | <odinho> | scottjehl: Easy to change. |
| 16:08 | <jgraham> | adactio: What nonsense |
| 16:08 | <Wilto> | odinho: With JavaScript, rather. |
| 16:08 | <scottjehl> | not in existing browsers |
| 16:08 | <gsnedders> | adactio: If impls won't support something, then a change doesn't help users. |
| 16:08 | <odinho> | Wilto: Oh, you have to actually write the polyfill of course. :-) But that's easy. |
| 16:08 | <odinho> | Wilto: Oh, you have to actually write the polyfill of course. :-) But that's easy. |
| 16:08 | <Wilto> | If we’re being honest, the WHATWG is completely entrenched. |
| 16:08 | <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 |
| 16:08 | <Wilto> | Arguing here won’t change anything. |
| 16:08 | <zewt> | (is wilto just trolling?) |
| 16:08 | <zewt> | (sure smells like it) |
| 16:09 | <jgraham> | zewt: I hope not |
| 16:09 | <odinho> | scottjehl: They don't throw any exceptions or anything if you omit the src. |
| 16:09 | <odinho> | scottjehl: It's perfectly doable. |
| 16:09 | <Wilto> | odinho, zewt, jgraham: I’ve posted scottjehl’s gist covering why polyfills may not be possible. |
| 16:09 | <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. |
| 16:09 | <odinho> | I've read it. |
| 16:10 | <Wilto> | Can you prove otherwise, odinho? |
| 16:10 | <Wilto> | I’d love to see some code. |
| 16:10 | <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) |
| 16:10 | <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 |
| 16:10 | <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) |
| 16:10 | <krijnh> | Wilto: digital beers received, thanks! :) |
| 16:10 | <jgraham> | That's just common sense. |
| 16:11 | <gsnedders> | adactio: Spec'ing what developers want if browsers won't impl it doesn't help the developers. |
| 16:11 | <jgraham> | But the priority of constituencies doesn't give authors magical powers |
| 16:11 | <Philip`> | scottjehl: (I don't know if anywhere reliably documents what current browsers do actually do in this case) |
| 16:11 | <jgraham> | If browser vendors agree that a different spec will work better for end users they will adopt the better spec |
| 16:12 | <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? |
| 16:12 | <Wilto> | easier for implementors* |
| 16:12 | <zewt> | developers often want things they can't have, like more synchronous APIs in the UI thread |
| 16:12 | <jgraham> | Wilto: If it is provably better, please prove it |
| 16:12 | <Wilto> | zewt: This isn’t about doing what’s best for some petulant developers. |
| 16:12 | <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 |
| 16:12 | <scottjehl> | h so little precedence, we've yet to test how src-less images behave in existing browsers |
| 16:12 | <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 |
| 16:12 | <scottjehl> | h so little precedence, we've yet to test how src-less images behave in existing browsers |
| 16:13 | <annevk> | Wilto: afaik <picture> does not address the pixel density use case |
| 16:13 | <Wilto> | With citations, documentation, etc.? I have, zewt. |
| 16:13 | <zewt> | what? |
| 16:13 | <jgraham> | I really haven't seen that many emails making technical objections to @srcset or arguments in favour of <picture> |
| 16:13 | <Wilto> | Y’know, nevermind. |
| 16:13 | <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. |
| 16:13 | <jgraham> | Just lots of assertions taht developers prefer <picture> |
| 16:13 | <necolas> | jgraham: but where is the proff srcset is better? |
| 16:13 | <necolas> | s/proff/proof |
| 16:13 | <annevk> | adactio: you don't think what Hixie wrote illustrates why srcset was chosen? |
| 16:13 | <Wilto> | jgraham: http://www.w3.org/community/respimg/ |
| 16:13 | <necolas> | it's a strange point to make |
| 16:13 | <jgraham> | necolas: Various arguments in its favour have been made |
| 16:14 | <Wilto> | The “lots of assertions” are from developers. |
| 16:14 | <jgraham> | It doesn't reuse an different feature in a mostly incompatible way |
| 16:14 | <jgraham> | It is relatively concise to author |
| 16:14 | <jgraham> | It is much easier for UAs to process |
| 16:15 | <Wilto> | Authors have stated that they don’t prefer the concise syntax, so let’s not pretend that’s still a factor here. |
| 16:15 | <jgraham> | (and therefore less likely to be buggy) |
| 16:15 | <Wilto> | Else, we’re just in denial. |
| 16:15 | <Wilto> | jgraham: Can you prove that “mostly incompatible” statement? |
| 16:15 | <jgraham> | To be honest, most authors have never been asked, and no one seems to have actually tried both |
| 16:15 | <Wilto> | I stress that the WHATWG wiki is publicly editable; I’d love to see a reasoned response to use cases. |
| 16:16 | <Wilto> | jgraham: Those we asked preferred picture. I’m sure you’re not saying “we didn’t ask everyone.” |
| 16:16 | <zewt> | i'm an author and i sure prefer concise syntax |
| 16:16 | <zewt> | i'm an author and i sure prefer concise syntax |
| 16:16 | annevk | too |
| 16:16 | <Wilto> | zewt: That’s a factor, then, among the many voices we’ve heard from. |
| 16:16 | <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 |
| 16:16 | <Wilto> | Two more for `img src`. |
| 16:16 | <divya> | zewt: most authors prefer what is easiest to understand |
| 16:16 | <divya> | not what is most concise. |
| 16:17 | <annevk> | Wilto: so that wiki page; what it says for high resolution displays does not actually work |
| 16:17 | <Wilto> | zewt, annevk: Perhaps you could join the other developers commenting on http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ |
| 16:17 | <jgraham> | The problem with this kind of "preference" thing is that it is rather hard to tell much from first impressions |
| 16:17 | <scottjehl> | jgraham: why does it make sense for <video> but not <picture>? |
| 16:17 | <necolas> | that goes both ways |
| 16:18 | <annevk> | scottjehl: it's not exactly clear media="" makes sense for <video> |
| 16:18 | <jgraham> | scottjehl: I don't think it does make sense for <video>; only Opera implement it and we suggested dropping it |
| 16:18 | <jgraham> | scottjehl: I don't think it does make sense for <video>; only Opera implement it and we suggested dropping it |
| 16:18 | <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 |
| 16:18 | <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.” |
| 16:18 | <annevk> | scottjehl: it's even implemented by all browsers; <video> has it mostly for type="" |
| 16:18 | <Wilto> | zewt: So you’re stating that—because of the forum—those opinions have been disregarded by the WHATWG. |
| 16:18 | <annevk> | scottjehl: and for <track> |
| 16:19 | <jgraham> | Wilto: I don't know how to solve problems in that algebra |
| 16:19 | <zewt> | uh, i'm saying that discussions should take place in a place where people will see them, not hidden away in blog comments |
| 16:19 | <Wilto> | jgraham: That much is obvious. |
| 16:19 | <Wilto> | zewt: It was posted to the list twice. |
| 16:19 | <jgraham> | Wilto: It would be more convincing if someone actually implemented both and tried them out |
| 16:19 | <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) |
| 16:20 | <necolas> | jgraham: scottjehl already made a <picture> polyfill |
| 16:20 | <Wilto> | zewt: Would you prefer I encouraged all those commenters to post their +1s on the mailing list? |
| 16:20 | <necolas> | it would be easy to make one for srcset and then see how people get on with using them |
| 16:20 | <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. |
| 16:20 | <jgraham> | necolas: So where is the srcset one for comparison? |
| 16:21 | <jgraham> | Ah you said that |
| 16:21 | <necolas> | jgraham: no one has made it yet |
| 16:21 | <jgraham> | apologies |
| 16:21 | <Wilto> | jgraham: Good question. |
| 16:21 | <zewt> | "+1s" aren't considered much of a factor at all |
| 16:21 | <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/ |
| 16:21 | <Wilto> | zewt: So, developers cannot simply vote on their own preferences. |
| 16:21 | <Wilto> | zewt: I would _love_ to quote you on that. |
| 16:21 | <jreading> | <picture> is too much markup FWIW |
| 16:22 | <zewt> | apis should be based on technical merit, not petitions |
| 16:22 | <Wilto> | Absolutely, zewt. Developer sentiment is a factor only as much as implementor sentiment. |
| 16:22 | <Wilto> | Technical merit is key. |
| 16:22 | <gsnedders> | The only non-technical thing that matters is usability, and that's more than just first-look opinion. |
| 16:22 | <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) |
| 16:22 | <miketaylr> | (re: +1, http://wiki.whatwg.org/wiki/FAQ#.2B1) |
| 16:22 | <Wilto> | jgraham: I posted it to the list easlier today, as well. |
| 16:23 | hober | catches up again |
| 16:23 | <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 |
| 16:23 | <Wilto> | Again: posted to the list multiple times. |
| 16:23 | <hober> | adactio: "A solution was proposed (srcset) without knowledge of the existing proposal (picture)" is untrue; i was aware of the CG's work |
| 16:24 | <jgraham> | scottjehl: Those technical challenges hardly seem insurmountable |
| 16:24 | <jgraham> | scottjehl: Those technical challenges hardly seem insurmountable |
| 16:24 | <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 |
| 16:24 | <hober> | adactio: one was the srcset proposal, and one was a "why i don't think <picture> is a good idea" post |
| 16:25 | <hober> | actually, iirc they started out as one email but the second part was getting really long and unweildy and needed editing |
| 16:25 | <hober> | so i split it up |
| 16:25 | <hober> | and didn't actually send any of it because of, err, i have no idea that was a long time ago |
| 16:25 | <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 |
| 16:25 | <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 |
| 16:26 | <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 |
| 16:26 | <hober> | pulled up and sent the srcset email |
| 16:26 | <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). |
| 16:26 | <hober> | which iirc says that i'll tackle <picture> in another email |
| 16:26 | <TabAtkins_> | There's no syntax that can get around that. |
| 16:26 | <hober> | i just haven't sent that other email yet, because i haven't finished writing it |
| 16:28 | <adactio> | hober: Okay. It's a shame that the excising of your email gave the impression that you were proposing in isolation. |
| 16:28 | <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 |
| 16:29 | <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 |
| 16:29 | <jgraham> | Since they are quite likely to just forget |
| 16:29 | <scottjehl> | jgraham: sorry, can you clarify? |
| 16:30 | <jreading> | necolas: perhaps there a way to stay DRY with <picture>, but it seems like so much cruft |
| 16:30 | <scottjehl> | hmm. plenty of standard features require careful syntax to bulletproof: @font-face is a good example of success in that |
| 16:30 | <scottjehl> | hmm. plenty of standard features require careful syntax to bulletproof: @font-face is a good example of success in that |
| 16:31 | <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 |
| 16:32 | <scottjehl> | jgraham: have you looked at how picturefill works? |
| 16:32 | <TabAtkins_> | scottjehl: Yup, that's an interesting hack around the problem. Requires duplication, but it works in all situations. What's not to like? |
| 16:32 | <scottjehl> | I think it addresses your concerns |
| 16:33 | <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 |
| 16:33 | <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* |
| 16:33 | <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* |
| 16:33 | <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*. |
| 16:33 | <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). |
| 16:34 | <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. |
| 16:34 | <hober> | adactio: i think you perceive a causal relationship between me sending that email and hixie making his edits |
| 16:34 | <TabAtkins_> | adactio: The CG took care of use-cases. Backwards compat was obvious. |
| 16:34 | <hober> | adactio: that simply isn't there |
| 16:34 | <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? |
| 16:35 | <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… |
| 16:35 | <jreading> | http://hellowurld.heroku.com/blog/2012/05/15/another-image-proposal-for-responsive-design/ |
| 16:35 | <TabAtkins_> | scottjehl: Requirements like "must provide a @src" are for authors, not implementors. Browsers treat a missing source like any other missing attribute. |
| 16:35 | <adactio> | hober: Okay. I will try to avoid apopheniac interpretations. |
| 16:36 | <TabAtkins_> | jreading: I and others have explained multiple times why MQs are inadequate for solving the multiple-resolution use-case. |
| 16:36 | <jreading> | lowsrc (now obsolete) would prefetch if it came first in the attrs list... |
| 16:38 | <scottjehl> | tabatkins: my brief tests show they treat it very differently |
| 16:38 | <TabAtkins_> | Details? |
| 16:39 | <bjankord> | Aynone have a recent recap, trying to figure out where the discussion is at? |
| 16:40 | <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. |
| 16:40 | <scottjehl> | (if no alt text, it spells out "IMAGE") |
| 16:40 | <hober> | adactio: i agree that the impression of work-in-isolation is unfortunate |
| 16:41 | <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. |
| 16:41 | <hober> | [whee, only 13 minutes behind :)] |
| 16:41 | <TabAtkins_> | So you'll get the "invalid image" fallback, which varies per browser. |
| 16:41 | <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. |
| 16:42 | <hober> | adamdbradley: i agree that they are addressing different problems (resolution variation of bitmaps v. affordance for arbitrary design breakpoints) |
| 16:42 | <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. |
| 16:42 | <TabAtkins_> | On that point... |
| 16:42 | <TabAtkins_> | Hixie: It might be nice to explicitly include the Responsive Images CG (as a unit) in the acks. |
| 16:43 | <hober> | adactio: for all i know, i *will* be told that when hixie gets around to processing my email. :) |
| 16:43 | <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 |
| 16:43 | <necolas> | here we go again |
| 16:44 | <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 |
| 16:44 | <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. |
| 16:45 | <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/ |
| 16:45 | <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. |
| 16:46 | <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 |
| 16:46 | <scottjehl> | same issue as imgset actually |
| 16:46 | <Wilto> | bjankord: I don’t think we can say for certain that it won’t introduce issues in older browsers. |
| 16:46 | <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. |
| 16:47 | <webben> | both <picture> and srcset will result in a redundant request unless the <img> element is wrapped in <noscript>. |
| 16:48 | <bjankord> | Wilto: Agreed |
| 16:49 | <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. |
| 16:49 | <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. |
| 16:49 | <scottjehl> | +1 |
| 16:49 | <odinho> | bjankord: Polyfills *are* hacks. |
| 16:49 | <Wilto> | bjankord: Absolutely. |
| 16:50 | <hober> | necolas: fwiw, i do think that it's clear that some kind of communication breakdown has happened, and that that's unfortunate. |
| 16:50 | <odinho> | That's the whole reason for them existing. |
| 16:50 | <bjankord> | odinho: Agreed |
| 16:50 | <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. |
| 16:50 | <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 |
| 16:50 | <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? |
| 16:50 | <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? |
| 16:50 | <odinho> | bjankord: So I don't think you can hold that against srcset(!) |
| 16:50 | <hober> | necolas: we should all try to learn from this in order to do better in the future |
| 16:51 | <Wilto> | I second scottjehl’s question. |
| 16:51 | <necolas> | TabAtkins_: as I keep saying, it's not about people not feeling "thanked" |
| 16:51 | <odinho> | scottjehl: Yes. But you have to talk in use cases that are not being met. |
| 16:51 | <necolas> | you're basically not listening, which is part of the problem |
| 16:51 | <odinho> | scottjehl: Or ground it on technical merit. |
| 16:51 | <hober> | necolas: who is "you" in that? |
| 16:51 | <necolas> | tab |
| 16:51 | <hober> | necolas: it seems clear to me that many people are listeningto many other people :) |
| 16:52 | <odinho> | hober: English is such a inprecise language :P |
| 16:52 | <odinho> | an* |
| 16:52 | <odinho> | im* |
| 16:52 | <odinho> | lol |
| 16:52 | <odinho> | I kinda blew that, didn't I! :D |
| 16:52 | <hober> | :) |
| 16:52 | <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 |
| 16:52 | <Wilto> | odinho: Can we quote you as saying that one should simply remove the `src` when creating a polyfill? |
| 16:52 | <bjankord> | necolas: +1 |
| 16:52 | <bjankord> | necolas: +1 |
| 16:53 | <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. |
| 16:53 | <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. ^_^ |
| 16:53 | <bjankord> | odinho: I can test in IE6-IE9 if you need it |
| 16:54 | <necolas> | TabAtkins_: yeah you're wrong. and I think i've already explained that at least 3 times. |
| 16:54 | <Wilto> | odinho: Cool. We’re agreed that we can’t guarantee backwards compatibility with the removal of the src, right? |
| 16:54 | <Wilto> | If that’s the official stance coming out of the WHATWG, I’m happy to pass that information around. |
| 16:54 | <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. |
| 16:54 | <TabAtkins_> | Wilto: Wait wait wait. Clarification. |
| 16:54 | <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. |
| 16:55 | <bjankord> | Shit, can't read this fast |
| 16:55 | <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. |
| 16:55 | <hober> | Wilto: what's "an official stance coming out of the WHATWG"? that's not how things work around here... |
| 16:55 | <TabAtkins_> | Wilto: At least until the polyfill comes along and fixes it. |
| 16:56 | <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. |
| 16:56 | <TabAtkins_> | Wilto: Alternately, you can do something like use a data: url for a 0x0 image. |
| 16:56 | <TabAtkins_> | Wilto: But that seems like more work than necessary. |
| 16:56 | <bjankord> | TabAtkins_: How does the polyfill handle users without JS |
| 16:56 | <TabAtkins_> | bjankord: polyfills *don't* handle users without JS. That's the point. |
| 16:56 | <bjankord> | This is something scottjehl's picturefill is capable of |
| 16:57 | <TabAtkins_> | bjankord: If you want to support users without JS, use @src. But then you have two requests in legacy browsers with JS. |
| 16:57 | <TabAtkins_> | There are unavoidable tradeoffs. |
| 16:57 | <Wilto> | TabAtkins_: That’s hardly a _rule_. Better polyfills certainly do. |
| 16:57 | <webben> | or use noscript |
| 16:57 | <Wilto> | TabAtkins_: That’s hardly a _rule_. Better polyfills certainly do. |
| 16:57 | <webben> | or use noscript |
| 16:57 | <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. |
| 16:57 | <mdelcx> | is the prevailing opinion still that the <picture> tag is optimal? |
| 16:57 | <scottjehl> | picture/picturefill avoids that |
| 16:57 | <scottjehl> | and it's a huge concern |
| 16:57 | <Wilto> | mdelcx: From the developer community, yes. |
| 16:57 | <odinho> | How do you turn off js in chrome? |
| 16:57 | <bjankord> | adactio: +1 +1 +1 |
| 16:57 | <mdelcx> | imset is a non-starter for me... poor spec |
| 16:57 | <Wilto> | Agreed with adactio. |
| 16:57 | <webben> | scottjehl: Avoids which? |
| 16:57 | <mdelcx> | IMO, of course |
| 16:58 | <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. |
| 16:58 | <bjankord> | odinho: Google it |
| 16:58 | <TabAtkins_> | adactio: No. I simply am *unable* to tell what necolas is saying is wrong. It's not technical, it appears to be personal. |
| 16:58 | <odinho> | bjankord: Actually did that ,found a nice one now though, -- it was so bad the first one. Thought there had to be better. |
| 16:58 | <TabAtkins_> | scottjehl: No, <picture> doesn't really avoid it. |
| 16:58 | <scottjehl> | I have a test page |
| 16:58 | <bjankord> | TabAtkins_: Can you elaborate? |
| 16:59 | <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">. |
| 16:59 | <scottjehl> | but without any http overhead |
| 16:59 | <scottjehl> | http://scottjehl.github.com/picturefill/ |
| 16:59 | <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." |
| 17:00 | <TabAtkins_> | adactio: Let me repeat the last three sentences of that. |
| 17:00 | <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 |
| 17:00 | <TabAtkins_> | Am I wrong? If so, can you explain it to me better? I've been trying all mornign to understand. |
| 17:00 | <bjankord> | Has any discussion been made here on meta media variables. https://gist.github.com/2702067 |
| 17:00 | <scottjehl> | btw that markup is purposely verbose to illustrate different queries. more than a real scenario in my experience |
| 17:00 | <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. |
| 17:01 | <bjankord> | It seems one of Hixie's issues with <picture> is how verbose it can get |
| 17:01 | <scottjehl> | of course that's a goal. that's every browser that exists today. |
| 17:01 | <TabAtkins_> | necolas: So what, precisely, of Hixie's email wasnt' sufficient? |
| 17:01 | <Wilto> | TabAtkins_: So help me, you can’t possibly be struggling to understand our line here. |
| 17:01 | <bjankord> | Wilto: +1 seriously |
| 17:02 | <Wilto> | TabAtkins_: Obviously this isn’t about ego. I can’t tell if this is misdirection or just condescention. |
| 17:02 | <webben> | scottjehl: None of those browser versions will be significant in 5 years time. |
| 17:02 | <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. |
| 17:02 | <Wilto> | For our part: it’s about technical merit, and has been. |
| 17:02 | <scottjehl> | webben: this is a feature we need yesterday |
| 17:02 | <Wilto> | TabAtkins_: My feedback was ignored. |
| 17:02 | <scottjehl> | webben: this is a feature we need yesterday |
| 17:02 | <Wilto> | TabAtkins_: Or shut down with “please prove it.” |
| 17:02 | <Wilto> | Which I have. |
| 17:02 | <TabAtkins_> | Wilto: omigod please get stories straight. Your line cannot be squared with necolas'. |
| 17:02 | <webben> | scottjehl: And srcset can't be fully imitated (because media queries don't tell you what the UA needs) |
| 17:02 | <Wilto> | Meanwhile, a solution made it into the spec. |
| 17:02 | <hober> | who ignored whose feedback? |
| 17:02 | <Wilto> | This is a waste of everyone’s time. |
| 17:03 | <webben> | scottjehl: But you _can_ imitate it (poorly) if you want to, using <picture> or @srcset. |
| 17:03 | <hober> | the passive voice is not helping with clarity :) |
| 17:03 | <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. |
| 17:03 | <TabAtkins_> | Agreed, unfortuantely. ;_; |
| 17:03 | <Wilto> | You all, as representatives of the WHATWG, are obviously digging in your heels. |
| 17:03 | <TabAtkins_> | tkadlec: Again, was it technical, or was it communication? If it's communication, *nobody will care* in a year. |
| 17:03 | <scottjehl> | Sigh. |
| 17:03 | <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 |
| 17:03 | <scottjehl> | 's not how I imagined this process worked. |
| 17:03 | <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 |
| 17:03 | <scottjehl> | 's not how I imagined this process worked. |
| 17:03 | <Wilto> | So I suppose all that’s left is to publicize your reasonings, to the best we can sort them out. |
| 17:03 | <TabAtkins_> | AGHIO3IPO. |
| 17:03 | <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 |
| 17:04 | <webben> | scottjehl: "after the fact": after what fact? |
| 17:04 | <necolas> | TabAtkins_: there are 2 different things here, which can be squared. |
| 17:04 | <webben> | scottjehl: The WHATWG spec follows a commit-then-review process. |
| 17:04 | <necolas> | 1. The fact that people are not happy with how things have been handled or how they have been spoken to throughout |
| 17:04 | <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". |
| 17:04 | <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) |
| 17:04 | <webben> | scottjehl: Just because @srcset is there today does not mean it's there tomorrow. |
| 17:04 | <zewt> | (You're right, I'm not too happy with how Wilto talks to all of us) |
| 17:04 | <TabAtkins_> | Either I have *no idea* what definitions you are using for those words, or someone else is sending mixed messages. |
| 17:05 | <webben> | scottjehl: You wouldn't believe the amount of material that was one time included in the spec and has later been jettisoned... |
| 17:05 | <Wilto> | zewt: I assumed condescension was the established tone here, based on how I’ve been received. |
| 17:05 | <TabAtkins_> | Philip`: Ah, kk. Well, same effect in the end here. |
| 17:05 | <necolas> | TabAtkins_: being personal is different to adequate communication |
| 17:05 | <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. |
| 17:05 | <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. |
| 17:05 | <hober> | what gsnedders said. |
| 17:05 | <gsnedders> | scottjehl: That fact there's now something in the spec changes little. |
| 17:05 | <zewt> | you're the only one that's been condescending and, well, frankly rather obnoxious; it's pretty uncommon here |
| 17:06 | <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. |
| 17:06 | <Philip`> | TabAtkins_: (...but I think some browsers do still resolve the empty string, at least for an explicit src="") |
| 17:06 | <beverloo> | Being a proponent of <picture> myself, I can see that being frustrating. |
| 17:06 | <necolas> | 2. The other issue is related to the details of the technical proposals. Different issues. |
| 17:06 | <TabAtkins_> | beverloo: But omigod the solution was *based* on the month+ of feedback on the issue. |
| 17:06 | <TabAtkins_> | al;skjdf;als |
| 17:06 | <beverloo> | TabAtkins, I get it, I get it |
| 17:06 | <bjankord> | beverloo: exactly |
| 17:06 | <beverloo> | just emphasizing |
| 17:07 | <TabAtkins_> | beverloo: I don't. ;_ |
| 17:07 | <beverloo> | flip tables. |
| 17:07 | <Wilto> | beverloo: It’s not even that no one reached out to us. |
| 17:07 | <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. |
| 17:07 | <Wilto> | I reached out to the WHATWG, representing the CG. |
| 17:07 | <bjankord> | So much time and effort was put into the CG |
| 17:07 | <Wilto> | And was asked to furnish proof of `picture`s merit, which was summarily dismissed. |
| 17:07 | <Wilto> | Over the course of four days. |
| 17:08 | <bjankord> | How can it not be clear our frustration TabAtkins? |
| 17:08 | <TabAtkins_> | Wilto: It. Was. Not. Dismissed. That proposal was found wanting for reasons which were stated in the email. |
| 17:08 | <TabAtkins_> | Namely, that <picture> was overly verbose and, being MQ based, didn't address the "MQs dont' work for multi-res negotiation" problem. |
| 17:09 | <jreading> | Tab: is there a summary of the "MQs dont' work for multi-res negotiation"? |
| 17:09 | <bjankord> | multi-res negotiation, you mean min-device-pixel-ration? |
| 17:09 | <TabAtkins_> | Having your suggestion rejected is *not* the same as having your feedback dismissed. |
| 17:09 | <TabAtkins_> | Having your suggestion rejected is *not* the same as having your feedback dismissed. |
| 17:09 | <TabAtkins_> | jreading: yes. I can illustrate it best with a real-world example. |
| 17:09 | <TabAtkins_> | Assume for a moment that there was a bandwidth MQ. |
| 17:10 | <annevk> | bjankord: yes, you can query the ratio, but you do not set it for the resource |
| 17:10 | <bjankord> | There are device-pixel-ratio media queries to handle various resolution displays |
| 17:10 | <webben> | Wilto: Not sure why you think four days is an unreasonable time for evaluating a technical proposal. |
| 17:10 | <annevk> | bjankord: and you need to set it, because otherwise your image will be displayed four times as large |
| 17:10 | <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. |
| 17:10 | <bjankord> | The issue of verbosity can be handled by adding meta media variables as an option to the picture element and including URI templates |
| 17:10 | <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. |
| 17:10 | <Wilto> | webben: Because it makes it clear that all this discussion was going on _while_ it was specced. |
| 17:10 | <Wilto> | Not before. |
| 17:10 | <Wilto> | Not before. |
| 17:11 | <annevk> | this discussion has been going on forever |
| 17:11 | <annevk> | since 2007 |
| 17:11 | <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. |
| 17:11 | <necolas> | and it's no less depressing |
| 17:11 | <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. |
| 17:11 | <TabAtkins_> | This is, obviously, a bad situation. |
| 17:12 | <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. |
| 17:12 | <bjankord> | So because bandwidth media queries are a bad situation for serving images, the picture element was disregarded? |
| 17:12 | <bjankord> | So because bandwidth media queries are a bad situation for serving images, the picture element was disregarded? |
| 17:12 | <Wilto> | bjankord: I did get that impression several times. |
| 17:12 | <bjankord> | You've got to be shitting me |
| 17:12 | <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. |
| 17:12 | <TabAtkins_> | bjankord: Well, because of that, any solution that relied solely on MQ was disregarded. Because it's a bad solution.. |
| 17:12 | <jreading> | Tab: I get that, but I would argue that bandwidth MQ's a re bad spec as well |
| 17:12 | <odinho> | bjankord: Because media queries is not the way to solve it. |
| 17:13 | <jreading> | esp. considering latency is more of an issue than bandwdith |
| 17:13 | <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. |
| 17:13 | <webben> | Wilto: Why is it a problem if people produce alternate proposals while evaluating a proposal? |
| 17:13 | <Wilto> | bjankord: Which I posted to the WHATWG wiki, and linked in the mailing list twice. |
| 17:13 | <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. |
| 17:13 | <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 |
| 17:13 | <miketaylr> | what about zooming in on a page, from your desktop? the low-res/mobile image MQ will be triggered. |
| 17:13 | <miketaylr> | what about zooming in on a page, from your desktop? the low-res/mobile image MQ will be triggered. |
| 17:13 | <jreading> | so because of bandwidth MQ, MQ are bad… makes no sense |
| 17:13 | <odinho> | Wilto: Then it's another proposal. Right now we're taking about the flexible image resolutions. |
| 17:13 | <Wilto> | miketaylr: Not when using ems. |
| 17:13 | <scottjehl> | or doesn't yet work anyway... |
| 17:14 | <miketaylr> | Wilto: ORLY |
| 17:14 | <miketaylr> | Wilto: ORLY |
| 17:14 | <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. |
| 17:14 | <Wilto> | It’s worth noting the the specced solution seems to be fully pixel dependent. Is that correct? |
| 17:14 | <TabAtkins_> | Because that means, by definition, that it's not solving an important use-case. |
| 17:14 | <Wilto> | As no detailed use cases have been published, we don’t know. |
| 17:14 | <bjankord> | The network information API is the closest thing we have to detecting a users bandwidth connection. http://www.w3.org/TR/netinfo-api/ |
| 17:14 | <miketaylr> | can everyone start using ems? that's one of my biggest complaints about "responsive" sites. zooming in gets me a mobile layout |
| 17:14 | <hober> | miketaylr: :) |
| 17:14 | <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. |
| 17:15 | <beverloo> | there's other issues with that, though |
| 17:15 | <gsnedders> | Wilto: What use-cases does it fail to fulfil on the discussion on the mailing list? |
| 17:15 | <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? |
| 17:15 | <gsnedders> | Wilto: What use-cases does it fail to fulfil on the discussion on the mailing list? |
| 17:15 | <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? |
| 17:15 | <Wilto> | miketaylr, hober: <3 ems. |
| 17:15 | <beverloo> | I'm not sure whether I agree with a bandwidth MQ at all, actually |
| 17:15 | <beverloo> | it'd be based on estimates |
| 17:16 | <Wilto> | gsnedders: The one I just mentioned. |
| 17:16 | <beverloo> | "wifi" can be significantly slower than "3g" |
| 17:16 | <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. |
| 17:16 | <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" |
| 17:16 | <Wilto> | I’m not sure we’re all on the original topic anymore. |
| 17:16 | <TabAtkins_> | Yes, the Network Info API is *really* flawed. |
| 17:16 | <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)? |
| 17:16 | <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. |
| 17:16 | <Wilto> | beverloo: It seems so. |
| 17:17 | <TabAtkins_> | beverloo: No, we're excluding it based on a ues-case (res negotiation) which requires an ability that MQ can't do. |
| 17:17 | <beverloo> | odinho, yes, I'm aware of that (I'm on the Chrome on Android team) |
| 17:17 | <Wilto> | beverloo: Android Chrome! You do yeoman’s work, beverloo. |
| 17:18 | <bjankord> | TabAtkins_: If the Network Information API is flawed, why have Chrome and Firefox added support for it? |
| 17:18 | <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. |
| 17:18 | <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 |
| 17:18 | <TabAtkins_> | bjankord: Because it's in a spec. |
| 17:18 | <TabAtkins_> | bjankord: Because it's in a spec. |
| 17:18 | <odinho> | beverloo: You obviously knew something about it, just wanted to back you up by extra data point :-) |
| 17:18 | <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. |
| 17:18 | <TabAtkins_> | beverloo: heuristics are fine. the *real* problem is statefulness, which MQ can't provide. |
| 17:18 | <Wilto> | TabAtkins_: I’d prefer to see more information on the specced solution posted publicly. |
| 17:18 | <beverloo> | TabAtkins, changing a mobile device's orientation will influence the width |
| 17:19 | <Wilto> | You don’t have to convince me; the developer community will need citations. |
| 17:19 | <bjankord> | ShaneHudson: +1 |
| 17:19 | <beverloo> | potentially causing the same problem |
| 17:19 | <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. |
| 17:19 | <Wilto> | TabAtkins_: Sure. Sum up for me, real quick. |
| 17:19 | <Wilto> | The community will want an easy-to-digest reasoning. |
| 17:19 | <annevk> | beverloo: so does resizing the browser window on desktop |
| 17:19 | <TabAtkins_> | I explained *literally* a screen or so ago, to jreading. |
| 17:19 | <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. |
| 17:19 | <beverloo> | annevk, TabAtkins, so neither solution is really stateful |
| 17:19 | <beverloo> | annevk, TabAtkins, so neither solution is really stateful |
| 17:20 | <odinho> | beverloo: MediaQueries can't do that. |
| 17:20 | <TabAtkins_> | beverloo: Yeah, I think that Hixie's proposal is somewhat flawed because of that. |
| 17:20 | <Wilto> | TabAtkins_: It seemed like you were discussing bandwidth MQ. |
| 17:20 | <TabAtkins_> | beverloo: I think it should take one length and use the smaller of the window dimensions to check it, precisely for that reason. |
| 17:20 | <Wilto> | TabAtkins_: It seemed like you were discussing bandwidth MQ. |
| 17:20 | <TabAtkins_> | beverloo: I think it should take one length and use the smaller of the window dimensions to check it, precisely for that reason. |
| 17:20 | <beverloo> | odinho, absolutely, the heuristics would be much more accurate than what a user can do |
| 17:20 | <annevk> | beverloo: one solution describes the resource, the other queries the device and selects a resource based on that |
| 17:20 | <annevk> | beverloo: you need the former for e.g. pixel density stuff |
| 17:21 | <TabAtkins_> | Wilto: I was explainign why you can't do bandwidth MQ, yes. And that's why MQ-based solutions are bad. |
| 17:21 | <bjankord> | Tab: What solution do you suggest? |
| 17:21 | <Wilto> | So, neither of these solutions will use hard-coded bandwidth detection, is that correct? |
| 17:21 | <odinho> | TabAtkins_: I think that too. A bounding box. Did I write that on mailing list, or only here? |
| 17:21 | <beverloo> | TabAtkins, issue there is that websites may present different versions based on the orientation (again due to MQs) |
| 17:21 | <Wilto> | TabAtkins_: ^ |
| 17:21 | <TabAtkins_> | bjankord: For what? The general problem? |
| 17:21 | <Wilto> | Nothing inline, in the markup, I mean. |
| 17:21 | <TabAtkins_> | odinho: I think it was you suggesting that, here in the chatroom. |
| 17:21 | <jreading> | bandwidth MQ are bad |
| 17:21 | <beverloo> | TabAtkins, for which you may want a different picture too. |
| 17:21 | <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? |
| 17:22 | <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 |
| 17:22 | <TabAtkins_> | beverloo: Eh, true. Welp, whatever. |
| 17:22 | <Wilto> | TabAtkins_: If neither is using an attribute that detects bandwidth, I’m not sure why we’re still talking about it. |
| 17:22 | <Wilto> | I agree that it’s a flawed idea. |
| 17:22 | <bjankord> | Agreed |
| 17:22 | <Wilto> | On both markup patterns. |
| 17:22 | <Wilto> | Let’s move on. |
| 17:22 | <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) |
| 17:22 | <Wilto> | Apart from _theoretical_ media queries, that is. |
| 17:22 | <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. |
| 17:23 | <annevk> | beverloo: polling for the DPI is not enough |
| 17:23 | <annevk> | beverloo: you need to set it |
| 17:23 | <Wilto> | TabAtkins_: And the specced pattern does not, then? |
| 17:23 | <annevk> | beverloo: because otherwise the image will be displayed four times the size |
| 17:23 | <Wilto> | It incorporates bandwidth in a meaningful way? |
| 17:23 | <TabAtkins_> | Wilto: Wait, have you read the specced proposal? |
| 17:23 | <beverloo> | annevk, got you |
| 17:23 | <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. |
| 17:23 | <beverloo> | annevk, thanks :) |
| 17:23 | <zewt> | TabAtkins: well, you also need to tell it the image's size (even if it's only a hint) |
| 17:23 | <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. |
| 17:23 | <annevk> | beverloo: I'm somewhat surprised everyone thinks MQ magically solve that... |
| 17:24 | <zewt> | file size, I mean |
| 17:24 | <TabAtkins_> | zewt: Filesize *should* correspond to the Nx multiplier you give. |
| 17:24 | <webben> | zewt: Yeah. I'm inclined to suggest srcset should include HxW (always) and would benefit form size. |
| 17:24 | <webben> | TabAtkins_: Doesn't that depend on e.g. jpeg quality? |
| 17:24 | <beverloo> | annevk, let's make a new image format containing the target DPI! |
| 17:24 | <zewt> | TabAtkins: you can also have multiple images at the same resolution with eg. different jpeg compression ratios |
| 17:24 | <beverloo> | annevk, let's make a new image format containing the target DPI! |
| 17:24 | beverloo | runs |
| 17:24 | <webben> | TabAtkins_: Doesn't that depend on e.g. jpeg quality? |
| 17:24 | <zewt> | TabAtkins: you can also have multiple images at the same resolution with eg. different jpeg compression ratios |
| 17:24 | beverloo | runs |
| 17:24 | <TabAtkins_> | zewt: Unless you're being perverse and providing different-sized images for different resolutions. |
| 17:25 | <TabAtkins_> | Yeah, compression ratio is somewhat harder to deal with, particularly since it's so format-specific. |
| 17:25 | hober | mumbles something about jpeg2000 |
| 17:25 | hober | mumbles something about jpeg2000 |
| 17:25 | <TabAtkins_> | I think by the time you're dealing with that, you should just go res-independent. |
| 17:25 | <bjankord> | We could sit here all day discussing pros and cons of each solution, yet still get no where... |
| 17:25 | <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* |
| 17:25 | <annevk> | beverloo: you mean one that browsers are not forced to ignore? |
| 17:26 | <zewt> | TabAtkins: also, file size doesn't change linearly with resolution |
| 17:26 | <zewt> | not always, anyway |
| 17:26 | <beverloo> | annevk, odinho, yup. |
| 17:26 | <grigs> | Wow, lot's of conversation. Took forever to catch up. A couple of quick notes. |
| 17:27 | <bjankord> | grigs: yes, there is a lot to digest here |
| 17:27 | <tantek> | TabAtkins - re: "just go res-independent", let me know when you know of cameras that output SVG photographs :p |
| 17:27 | <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. |
| 17:28 | <annevk> | beverloo: good luck with that :) |
| 17:28 | <beverloo> | annevk, :D |
| 17:28 | <TabAtkins_> | zewt: Yeah, it's not a perfect fit. But I suspect it's probably a good enough approximation. |
| 17:28 | <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. |
| 17:28 | <annevk> | grigs: pointer for that? I asked before but never got it |
| 17:28 | <annevk> | grigs: pointer for that? I asked before but never got it |
| 17:29 | <ShaneHudson> | It should be in a community group anyway, it is the kind of thing the community should have input on |
| 17:30 | <grigs> | @annevk I'll dig it up. |
| 17:30 | <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 |
| 17:31 | <annevk> | ShaneHudson: WHATWG is a community developing HTML |
| 17:31 | <annevk> | ShaneHudson: no need for subgroups in the past eight years |
| 17:31 | <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 |
| 17:31 | <grigs> | annevk: original objection to the conversation on the list http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034775.html |
| 17:31 | <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. |
| 17:31 | <TabAtkins_> | (Or, as people have said, you're printing, or saving, etc.) |
| 17:32 | <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 ;-) ) |
| 17:32 | <annevk> | grigs: interesting, I don't know who that is |
| 17:32 | <TabAtkins_> | zewt: Within a particular resolution level, jpeg quality might be useful, but I think it's a much smaller concern. |
| 17:32 | <grigs> | annevk: still looking for the specific suggestion that we take it to a community group. |
| 17:33 | <TabAtkins_> | Huh. I have also never heard of this Ronjek guy. |
| 17:33 | <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 |
| 17:33 | <annevk> | grigs: the list has 1500 people so if one person tells you something that doesn't mean it's definitive |
| 17:33 | <zewt> | at least for that (isolated, off-the-top-of-my-head) case, it's almost always the better choice |
| 17:33 | <annevk> | grigs: thanks |
| 17:33 | <tkadlec> | grigs: I believe here? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html |
| 17:33 | <annevk> | i have to go now |
| 17:33 | <grigs> | annevk: I get that. To me, that’s the frustrating part. |
| 17:34 | <divya> | annevk: you are just being defensive here. ultimately who do we consider as the 'voice'? |
| 17:34 | <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 |
| 17:34 | <divya> | if we mention to hixie |
| 17:34 | <divya> | thats not enough |
| 17:34 | <divya> | if we mention here |
| 17:34 | <divya> | thats not enough |
| 17:34 | <divya> | if we mention on mailing list its not enough |
| 17:34 | <divya> | when is it enough? |
| 17:34 | <annevk> | divya: not sure what you're saying |
| 17:34 | <annevk> | but I have to go watch a movie |
| 17:34 | <grigs> | tkadlec: thanks, that's the link |
| 17:34 | <grigs> | annevk: enjoy! |
| 17:35 | <webben> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html seems relevant. |
| 17:35 | <grigs> | webben: yep. |
| 17:36 | <webben> | divya: http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 17:36 | <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). |
| 17:37 | <zewt> | TabAtkins: i'd just include the file size by itself |
| 17:37 | <TabAtkins_> | Ah, yeah, that's valid. |
| 17:37 | <TabAtkins_> | Hixie mentions that in a response on the latest thread. |
| 17:37 | <zewt> | that would make the assumption that all available options are in the same or comparable compression types, which is probably reasonable |
| 17:38 | <divya> | webben: all of it was done. |
| 17:38 | <divya> | hober: it would have been nice when you proposed the solution why you decided it over picture |
| 17:38 | <divya> | hober: it seems like the whole work was summarily dismissed even though now it looks like it wasnt |
| 17:38 | <webben> | divya: I'm linking you to that to explain why it doesn't make sense to ask for the voice of the WHATWG. |
| 17:39 | <webben> | divya: The WHATWG as an organization speaks only for administrative reasons basically. |
| 17:40 | <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 implem |
| 17:40 | <divya> | jgraham: i actually am not attached to any one solution |
| 17:40 | <divya> | i suspect none of the people are |
| 17:41 | <divya> | jgraham: only concern is the unreadable syntax that srcset proposes |
| 17:41 | <grigs> | divya: +1 |
| 17:41 | <divya> | and the other concerns that scottjehl raises |
| 17:41 | <divya> | jgraham: we know people will go wrong |
| 17:41 | <divya> | jgraham: we know people will go wrong |
| 17:41 | <divya> | jgraham: i think having an easy to understand solution would make it less difficult to go wrong |
| 17:42 | <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. |
| 17:42 | <grigs> | not trying to be difficult here, but will readily acknowledge I may be dense. ;-) |
| 17:43 | <divya> | just because the GCD is stupid |
| 17:43 | <jgraham> | divya: hmm i don't think I said you were. Just sharing some "thinking" from the bus ride home |
| 17:43 | <grigs> | divya: GCD? |
| 17:43 | <divya> | Greatest common denominator :))) |
| 17:43 | <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 |
| 17:44 | <divya> | doesnt mean we should just do whatever is the most easy for implementors. |
| 17:44 | <divya> | jgraham: ya ya i am just ranting |
| 17:44 | <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. |
| 17:45 | <jgraham> | paul_irish: There is: don't use new elements before they are implemented; for things with no implementation use data- attributes |
| 17:45 | <divya> | jgraham: i am yet to come across a polyfill problem |
| 17:45 | <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 |
| 17:46 | <divya> | jgraham: is there one? |
| 17:46 | <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 |
| 17:46 | <paul_irish> | <x-picture> is the equivalent. it could work effectively the same from the polyfill side. |
| 17:47 | <jgraham> | Yeah, but inventing elements is non-conforming and highly controversial |
| 17:47 | <divya> | jgraham: like we havent been doing that for eons :P |
| 17:47 | <jgraham> | divya: How many things *that no browser implements*? |
| 17:47 | <scottjehl> | jgraham: the polyfill would of course be updated to match implementation |
| 17:48 | <Philip`> | zewt: Yeah, I'm not trying to argue any case - just musing about how lowering resolution is simply a poor lossy compression algorithm |
| 17:48 | <Philip`> | zewt: Yeah, I'm not trying to argue any case - just musing about how lowering resolution is simply a poor lossy compression algorithm |
| 17:48 | <divya> | jgraham: severalll |
| 17:48 | <jgraham> | scottjehl: But existing sites would break |
| 17:48 | <divya> | HOW ABOUT HGROUP |
| 17:48 | jgraham | -> food |
| 17:48 | <divya> | kk bai |
| 17:50 | <jreading> | there.must.be.a.better.way |
| 17:50 | <jreading> | http://davidbcalhoun.com/present/mobile-performance-amazon/#navigator.connection this should be in headers and we can kill that MQ bandwidth nonsense |
| 17:52 | <jreading> | variablize the MQ's in <picture> (like my blog post) and be more DRY |
| 17:52 | <jreading> | variablize the MQ's in <picture> (like my blog post) and be more DRY |
| 17:54 | <paul_irish> | jgraham: speaking of changing implementations, that spec changed. :p |
| 17:54 | <paul_irish> | oops. jreading, rather. |
| 17:55 | <odinho> | I've written a polyfill for srcset now. |
| 17:55 | <zewt> | hey, i've been using gmail for years and I finally figured out how to extend a damned quote block |
| 17:55 | <odinho> | To see it could be done. But, yes, it does have some problems at edge cases. |
| 17:55 | <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 |
| 17:56 | <scottjehl> | odhino: link? |
| 17:56 | <odinho> | scottjehl: Yeah, I need someone to test it in IE :P |
| 17:57 | <scottjehl> | ...and loads of mobile devices |
| 17:58 | <scottjehl> | so what's next for picture element supporters? is there anywhere worthwhile to direct our existing and ongoing efforts? |
| 17:58 | <divya> | scottjehl: i am not sure if we should be so affiliated to pic element |
| 17:59 | <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 |
| 17:59 | <scottjehl> | divya, what do you mean? |
| 18:00 | <grigs> | scottjehl: i'm still trying to definitely figure out if srcset addresses one of the core use cases. |
| 18:00 | <divya> | scottjehl: i am saying we shouldnt be attached to a syntax |
| 18:01 | <divya> | its okay as long as we find a solution that works for implementors and devs alike |
| 18:02 | <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. |
| 18:02 | <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? |
| 18:02 | <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) |
| 18:02 | <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 |
| 18:03 | <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 :-) |
| 18:03 | <grigs> | tantek: exactly |
| 18:03 | tantek | agrees with Philip - why jumping straight to pro/anti any specific syntax? |
| 18:03 | tantek | has yet to see any consensus on which use-cases matter and why. |
| 18:03 | tantek | has yet to see any consensus on which use-cases matter and why. |
| 18:04 | <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. |
| 18:04 | <grigs> | tantek: amen! |
| 18:04 | <tantek> | grigs - I'm looking at the folks proposing <picture> as well |
| 18:05 | <grigs> | tantek: OH I KNOW |
| 18:05 | <grigs> | :-) |
| 18:05 | <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. |
| 18:05 | <tantek> | until you show your work, I'm not buying the proof (proposal) |
| 18:06 | <grigs> | same true for srcset as well then, eh? |
| 18:06 | <tantek> | grigs - of course |
| 18:06 | <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. |
| 18:06 | <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. |
| 18:07 | <tantek> | odinho - that's bass-ackwards |
| 18:07 | <tantek> | "align much more with srcset's use cases" |
| 18:07 | <grigs> | i do think there's a lot of that going on though. |
| 18:07 | <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. |
| 18:07 | <jgraham> | tantek: Not if you are charitable |
| 18:08 | <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 ) |
| 18:08 | <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. |
| 18:08 | <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. |
| 18:08 | <tantek> | group/community specific wikis are a bit of a silo-iziation/tribalization and not useful for broadening consensus (actually harmful) |
| 18:08 | <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>" |
| 18:09 | <grigs> | jgraham: that's the way I read it. |
| 18:10 | <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. |
| 18:10 | <odinho> | http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ <- in fact these are actually very nice. |
| 18:10 | <tantek> | odinho - except it's not editable |
| 18:10 | <tantek> | hence: "put them on a *generally* accessible/usable wiki (e.g. w3.org/wiki/ or wiki.whatwg.org )" |
| 18:10 | <tantek> | give them their own sections so you can link to them |
| 18:11 | <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? |
| 18:11 | <tantek> | example: http://wiki.whatwg.org/wiki/Time_element |
| 18:11 | <odinho> | tantek: I agree with all of them. -- But the media queries doesn't solve them as nicely as the srcset proposal does. |
| 18:11 | <tantek> | ShaneHudson - yes, wiki please |
| 18:11 | <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. |
| 18:11 | <tantek> | that way we can iterate on them in one place |
| 18:12 | <scottjehl> | grigs +1 |
| 18:12 | <tantek> | rather than go round-round in the support forums known as "mailing lists" |
| 18:12 | <tkadlec> | grigs: +1 |
| 18:12 | <jgraham> | tantek: Characterising the whatwg list as a "support forum" is just inaccurate |
| 18:12 | <tantek> | grigs - what part of "document use-cases on the wiki" was not communicated?: |
| 18:12 | <ShaneHudson> | http://wiki.whatwg.org/wiki/Adaptive_images Has everyone seen that page? |
| 18:12 | <jgraham> | Although I agree that using the wiki in this case might be useful |
| 18:13 | <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. |
| 18:13 | <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. |
| 18:13 | <Wilto> | tantek: Just tuning back in, but you saw this, yeah? http://wiki.whatwg.org/wiki/Adaptive_images |
| 18:13 | <Wilto> | I posted it to the list a couple of times. |
| 18:13 | <jgraham> | Wilto: That still has proposed solutions listed under "use cases" |
| 18:13 | <ShaneHudson> | grigs: I agree. For new members at least, it is pretty caotic! |
| 18:13 | <tantek> | Wilto - problem with that wiki page is that it is already assuming <picture> as syntax |
| 18:13 | <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. |
| 18:13 | <tantek> | so you're not going to get people to read past that |
| 18:14 | <tantek> | this style of documenting use-cases is better: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ |
| 18:14 | <grigs> | odinho: how the hell were we supposed to know that? :-) |
| 18:14 | <ShaneHudson> | Okay, lets make a new page. |
| 18:14 | <grigs> | At various points we were told that modifying the img tag was a non-starter so we coached others not to do so. |
| 18:14 | <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. |
| 18:14 | <Wilto> | That’s helpful, tantek. We can put up a page more along those lines, if that’ll help. |
| 18:15 | <tantek> | all email lists eventually devolve into support forums |
| 18:15 | <TabAtkins_> | grigs: That was misinterpreted, unfortunately. Modifying <img> to have *children* is a non-starter. Adding attrs is always okay. |
| 18:15 | <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. |
| 18:15 | <jgraham> | grigs: That was a misunderstanding about what "modify" meant |
| 18:15 | <tantek> | actual design happens in smaller / quicker fora like IRC, with anything of any substance being documented on the web (wiki pages) |
| 18:15 | <tantek> | the whatwg list *appears* to work only because Hixie treats it as his inbox. |
| 18:16 | <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 |
| 18:16 | <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. |
| 18:16 | <tantek> | no, I'm just concluding from the vast majority of email that gets to sent to the whatwg list |
| 18:16 | <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 |
| 18:16 | <tantek> | sure reads like a support forum |
| 18:16 | <jgraham> | You must be reading a very different list to me |
| 18:17 | <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 |
| 18:17 | <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. |
| 18:17 | <odinho> | grigs: It was not like that last time. |
| 18:17 | <ShaneHudson> | How do we register for this wiki? Says I have to be an admin to register... |
| 18:17 | <Philip`> | ShaneHudson: Many things would be much easier if we could ignore reality :-) |
| 18:17 | <grigs> | odinho: Actually, no, we don’t seem to agree on use cases (which was tantek's earlier point). |
| 18:17 | <tantek> | ShaneHudson - any W3C account can sign into w3.org/wiki |
| 18:18 | <odinho> | grigs: I agree with the use cases you've put up. -- And putting media queries up to those points, I find it lacking. |
| 18:18 | <ShaneHudson> | tantek: Ah, so not wiki.whatwg? Ok |
| 18:18 | <jgraham> | ShaneHudson: The whatwg wiki? |
| 18:18 | <jgraham> | Uh Hixie is an admin, maybe annevk, AryehGregor perhaps |
| 18:18 | <grigs> | odinho: happy you agree, not clear everyone else does (again tantek's point) |
| 18:18 | <jgraham> | Uh Hixie is an admin, maybe annevk, AryehGregor perhaps |
| 18:18 | <grigs> | odinho: happy you agree, not clear everyone else does (again tantek's point) |
| 18:18 | <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. |
| 18:19 | <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. |
| 18:19 | <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. |
| 18:19 | <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. :-) |
| 18:20 | <tantek> | odinho - indeed, it's easy to draw incorrect conclusions when we don't have specific use-cases to refer to by URL. |
| 18:20 | <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… |
| 18:20 | <tantek> | jreading - a good solution to *what use-cases*? |
| 18:20 | <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. |
| 18:20 | <ShaneHudson> | Right I am going to grab dinner. Does anyone disagree with the wiki page being http://www.w3.org/wiki/Images ? |
| 18:21 | <tantek> | ShaneHudson - go ahead and start it. we can rename/move later if needed. |
| 18:21 | <jreading> | is their a github of use cases that I can submit pull requests? |
| 18:21 | <tantek> | jreading - wiki editing is easier / more usable/accessible that git for documentation/text |
| 18:21 | <zewt> | let's make discussing a feature as complicated as possible |
| 18:21 | <ShaneHudson> | jgraham: Use the wiki I just linked to.. I will be creating the page after dinner |
| 18:22 | <tantek> | just created it as a stub ;) |
| 18:23 | <jreading> | tantek: I was thinking markup, but I'd be happy to contribute some examples to the wiki that might illustrate my pain |
| 18:23 | <jgraham> | That doesn't follow the general layout of the W3C wiki |
| 18:23 | <jgraham> | But I don't really care |
| 18:23 | <Wilto> | jreading: I started a repo here a while back: https://github.com/Wilto/respimg |
| 18:23 | <jgraham> | (I think the WhatWG wiki would be better since it doesn't require W3C Member access) |
| 18:23 | <Wilto> | jreading: The WHATWG wiki page is more thorough, though. |
| 18:24 | <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. |
| 18:24 | <grigs> | TabAtkins_: not my point. seriously. |
| 18:24 | <tantek> | TabAtkins indeed. |
| 18:24 | <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. |
| 18:24 | <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. |
| 18:24 | <tantek> | TabAtkins indeed. |
| 18:25 | <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. |
| 18:25 | <tantek> | good design must be based on referenceable real world use cases |
| 18:25 | <odinho> | TabAtkins_: And sunken cost-less! |
| 18:25 | <TabAtkins_> | odinho: Yeah. |
| 18:27 | <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 |
| 18:27 | <tantek> | s/below/above |
| 18:27 | <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. |
| 18:28 | <tantek> | grigs - time is usually most wasted on email lists / support forums. |
| 18:28 | <tantek> | grigs - time is usually most wasted on email lists / support forums. |
| 18:29 | <ShaneHudson> | tantek: Thank you :) I have not written anything quite like this before so anyone feel free to help and suggest improvements |
| 18:29 | <ShaneHudson> | Will get started on it in about 30 mins, not cooked dinner yet |
| 18:31 | <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. |
| 18:31 | <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). |
| 18:31 | <tantek> | point being, not all the use-cases were satisfied, that's OK. |
| 18:31 | <tantek> | point being, not all the use-cases were satisfied, that's OK. |
| 18:32 | <grigs> | anyways, for next time, it would be nice to have something a little clearer for outsiders. which was my original point. :-) |
| 18:32 | <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 |
| 18:32 | <TabAtkins_> | grigs: Ah, sure. Yeah, standards is hard. |
| 18:32 | <grigs> | any disagreement with that? |
| 18:32 | <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. |
| 18:33 | <TabAtkins_> | Everything else is details. |
| 18:33 | <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. |
| 18:33 | <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. |
| 18:37 | <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. |
| 18:37 | <grigs> | tantek: would replacing "outsiders" with "people new to the whatwg standards process" be sufficient? i think we're just talking semantics. |
| 18:37 | <tantek> | outsiders just means anyone not editing the spec ;) |
| 18:38 | <adactio> | grigs: What do you mean exactly by "semantics?" ;-) |
| 18:38 | <tantek> | adactio LOL |
| 18:38 | <grigs> | adactio: LOL |
| 18:39 | <grigs> | https://twitter.com/#!/adactio/status/197343204683694080 |
| 18:39 | <grigs> | I’ve got that tweet favorited. |
| 18:39 | <zewt> | so many quotostrophes |
| 18:42 | <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. |
| 18:43 | <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 |
| 18:43 | <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. |
| 18:44 | <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 |
| 18:44 | <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) |
| 18:44 | <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) |
| 18:44 | <grigs> | zewt: blame the tool makers, not the CG users. |
| 18:44 | <tantek> | grigs - from my understanding the recommendation to document persuasive use-cases is quite prevalent |
| 18:44 | <tantek> | \ |
| 18:45 | <tantek> | e.g. http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 18:45 | <tantek> | steps 1 and 2 |
| 18:45 | <tantek> | 1. Research the use cases and requirements by discussing the issue with authors and implementors. |
| 18:45 | <tantek> | 2. Come up with a clear description of the problem that needs to be solved |
| 18:46 | <scottjehl> | tantek did the CG not follow that process in your opinion? |
| 18:47 | <grigs> | tantek: that seems fair. perhaps we got a lot of bad advice during the process. hard to figure out where we went astray. |
| 18:47 | <tantek> | scottjehl - no - based on my request to see a simple wiki page of use-cases and there not being one. |
| 18:47 | <tantek> | the blog post was an excellent start |
| 18:47 | <tantek> | but blog posts are snapshots |
| 18:47 | <tantek> | they're not "living" |
| 18:47 | <tantek> | grigs - "bad advice during the process" - yes that's what happens on mailing lists / support forums. |
| 18:48 | <grigs> | tantek: and the alternative is? |
| 18:49 | <grigs> | tantek: i thought you were suggesting support forums. i think i missed your earlier point. |
| 18:49 | <tantek> | 1. document your research on an open wiki page, 2. post URLs on IRC etc. to gather feedback |
| 18:49 | <tantek> | posting actual "content" on email lists is pretty much a waste of time |
| 18:49 | <jgraham> | To be clear tantek's views on how to do things are personal. |
| 18:49 | <Wilto> | tantek: This sounds a lot like what I did with http://wiki.whatwg.org/wiki/Adaptive_images? |
| 18:49 | <tantek> | jgraham - no, the data fits my generazliations. |
| 18:49 | <tantek> | generalizations even. |
| 18:49 | <jgraham> | So you claim |
| 18:49 | <tantek> | the bad advice that the respimg folks got on the whatwg list is just the latest example |
| 18:50 | <tantek> | no, not claim - have URLs |
| 18:50 | <tantek> | people already posted them above |
| 18:50 | <jgraham> | Anyway the point that you should collect use cases first and present use cases before solutions is sound |
| 18:50 | <scottjehl> | jgraham we certainly did that |
| 18:50 | <jgraham> | scottjehl: That isn't clear |
| 18:51 | <tantek> | scottjehl - I have to agree with jgraham on that - that part wasn't clear. |
| 18:51 | <jgraham> | At least the wiki page I have seen that claims to have use cases mostly has solutions |
| 18:51 | <tantek> | posting use-cases on a wiki page helps make it *more* clear |
| 18:51 | <othermaciej> | tantek: what bad advice do you think the respimg guys got on the whatwg mailing list? |
| 18:51 | <othermaciej> | (interested in hearing because it would be good to ensure future contributors get good advice) |
| 18:51 | <tantek> | jgraham - agreed. intermingling a particular syntax among use-cases is not helpful. |
| 18:51 | <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. |
| 18:51 | <Wilto> | It just got ignored, I assume because it is “done wrong.” |
| 18:51 | <tantek> | Wilto - what post? to a mailing list? |
| 18:51 | <Wilto> | Yes. |
| 18:52 | <tantek> | Wilto - most email is ignored |
| 18:52 | <grigs> | wilto: yeah, tantek did. he said it includes picture element. |
| 18:52 | <tantek> | it's an inherent problem with the medium |
| 18:52 | <tantek> | especially lists |
| 18:52 | <tantek> | "someone else will handle it" |
| 18:52 | <Wilto> | Eesh. |
| 18:52 | <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. |
| 18:52 | <grigs> | Wilto: i missed his comment when it went past the first time, but it is in the irc logs. |
| 18:52 | <Wilto> | I mean, that is fair: this was mentioned, and you guys did try to help. I think I just misinterpreted the feedback somewhat. |
| 18:53 | <grigs> | Wilto: nevermind. i misunderstood. |
| 18:53 | <Wilto> | But, yeah—nothing on the mailing list. |
| 18:53 | <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. |
| 18:54 | <grigs> | Yeah. :-( |
| 18:54 | <Wilto> | Dead-on as always, scottjehl. |
| 18:55 | <zewt> | mail to the whatwg list always gets a reply ... but hixie is overloaded, so sometimes it takes a *long* time |
| 18:55 | <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 |
| 18:55 | <jgraham> | The place where implementors (except Microsoft) typically work on HTML is WHATWG |
| 18:55 | <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 |
| 18:57 | <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. |
| 18:57 | <zewt> | the mail you're replying to was wrong; whatwg is definitely the place for that discussion, IMO |
| 18:57 | <jgraham> | FWIW the CG might have been a good place to gather *requirements* |
| 18:57 | <scottjehl> | this is all very hard to hear now, naturally |
| 18:57 | <smaug____> | Web Audio API is horrible. Hard to even start reviewing because everything is so under-defined |
| 18:58 | <odinho> | scottjehl: http://odin.s0.no/web/srcset/polyfill.htm |
| 18:58 | <jgraham> | grigs: So we will do better next time :) |
| 18:58 | <odinho> | scottjehl: So, come with all the bugs. :P |
| 18:59 | <zewt> | (don't know who "ronjec viktor" is, don't recall seeing his name before) |
| 18:59 | <tantek> | jgraham - yes, CGs are plenty fine places to gather and even prioritize requirements and use-cases |
| 18:59 | <Wilto> | I’m not comfortable saying “oh well, this is a forgone conclusion because the process is broken; better luck next time.” |
| 18:59 | <tantek> | but I think bikeshedding a solution is too tempting for any group to avoid |
| 19:00 | <jgraham> | Wilto: There is no "conclusion" yet |
| 19:00 | <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 |
| 19:00 | <Wilto> | Fair. |
| 19:00 | <jgraham> | Not much has happened really |
| 19:01 | tantek | agrees with jgraham |
| 19:01 | <jgraham> | Hixie has been convinced that a set of requirements exist that are worth solving |
| 19:01 | <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 |
| 19:01 | <tantek> | there's still quite the opportunity to define prioritized requirements and use-cases |
| 19:01 | <Wilto> | Oh no—by no means to I consider this a done deal. |
| 19:01 | <jgraham> | Whether or not these are the same requirements that you have is still unclear |
| 19:01 | <Wilto> | do I. |
| 19:01 | <jgraham> | There is no implementation and so no lock-in |
| 19:01 | <tantek> | zewt - I mostly see discussions either repeated, or based in theory in email |
| 19:02 | <grigs> | Slightly different topic: I have a question about a use case that I’ll document on the stub page later today. |
| 19:03 | <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 |
| 19:03 | <zewt> | tantek: a wiki doesn't stop email; it just duplicates it |
| 19:04 | <grigs> | The browser for Meego image changes depending on the viewport width. |
| 19:04 | <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? |
| 19:05 | <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. |
| 19:05 | <jgraham> | scottjehl: I think you are overestimating the clarity of the requirements |
| 19:06 | <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. |
| 19:07 | <scottjehl> | I don't think anyone involved in the CG was unclear about them |
| 19:07 | <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. |
| 19:08 | <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. |
| 19:08 | <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. |
| 19:09 | <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. |
| 19:09 | <tantek> | zewt - actually it does, because it makes it trivial for anyone to reply with a URL and say - already discussed, see this. |
| 19:09 | <tantek> | email duplicates email |
| 19:10 | <scottjehl> | anyway, both use cases are kind of the same |
| 19:10 | <grigs> | scottjehl: ha ha. your comment makes it clear my fear that i'm not explaining myself clearly is well-founded. :-) |
| 19:11 | <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! |
| 19:11 | grigs | going to lunch. back later. |
| 19:11 | <zewt> | tantek: that's already trivial; a link to list archives |
| 19:11 | <scottjehl> | tantek rehashing things we've already agreed upon in the wrong channel is all. These are the same use case |
| 19:11 | <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. |
| 19:11 | <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) |
| 19:12 | <Wilto> | Sure thing, odinho. My mistake. |
| 19:12 | <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 |
| 19:12 | <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) |
| 19:13 | <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. |
| 19:13 | <tantek> | put substantial content on the web where it can be trivially found by search engines. wikis tend to be very good for that. |
| 19:14 | <zewt> | i find mailing list conversations constantly; stuff on wikis is more hidden |
| 19:14 | <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 |
| 19:14 | <zewt> | gross |
| 19:14 | <odinho> | Wilto: Thanks. :-) |
| 19:14 | <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. |
| 19:14 | <tantek> | google (bing etc.) find thing things on wikis MUCH more easily than mailing lists |
| 19:15 | <zewt> | wikis are pretty much useless for any kind of discussion |
| 19:15 | <tantek> | so is email |
| 19:15 | <tantek> | irc is a bit better |
| 19:15 | <zewt> | uh, no it isn't? |
| 19:15 | <zewt> | i've had countless useful discussions on email, so the claim just doesn't make any sense |
| 19:16 | <scottjehl> | zewt sorry, my claim? |
| 19:16 | <tantek> | scottjehl - there is no "whatwg" to have "asked" you to "clarify portions" - that's an illusion perpetrated by some individuals |
| 19:16 | <tantek> | there is the editor of the spec, Hixie |
| 19:17 | <zewt> | (your what?) |
| 19:17 | <scottjehl> | zewt disregard sorry |
| 19:17 | <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 |
| 19:17 | <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. |
| 19:18 | <jgraham> | You know this whole doublespeak thing of saying "support forum" instead of "mailing list" gets old fast |
| 19:18 | <tantek> | etherpad is a nice realtime improvement upon wikis also - works better for some discussions |
| 19:18 | <zewt> | http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent |
| 19:18 | <tantek> | etherpad is a nice realtime improvement upon wikis also - works better for some discussions |
| 19:18 | <tantek> | jgraham - I don't think you understand what "doublespeak" means. |
| 19:18 | <scottjehl> | yeah, picture planning originated in etherpad |
| 19:18 | <tantek> | it's more like, acts like a duck, probably is a duck |
| 19:18 | <tantek> | email lists that act like support forums may as well be considered support forums |
| 19:19 | <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. |
| 19:19 | <zewt> | (i didn't say any of that, heh) |
| 19:19 | <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 :] |
| 19:19 | <tantek> | hmm krijnhoetmer.nl appears to be slow to respond for me |
| 19:19 | <tantek> | hmm krijnhoetmer.nl appears to be slow to respond for me |
| 19:19 | <bjankord> | CG was a great place to read info, far better than IRC logs or email lists |
| 19:19 | <scottjehl> | +1 |
| 19:20 | <bjankord> | CG was also open to everyone |
| 19:20 | <bjankord> | The best ideas rise to the top this way |
| 19:20 | <zewt> | odinho: you seem to be responding to things i didn't say :) |
| 19:22 | <odinho> | 21:19 < zewt> http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2154 sort of permanent |
| 19:22 | <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. |
| 19:22 | <odinho> | zewt: You said that irc was sort of permanent. |
| 19:23 | <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) |
| 19:23 | <scottjehl> | Loads of developers actually thought they were taking the right steps to help plan this feature. |
| 19:23 | <zewt> | odinho: ... none of what you said has anything to do with that :) |
| 19:23 | <zewt> | i never said anything about reading IRC logs |
| 19:24 | <zewt> | only responding to "less permanent" |
| 19:24 | <bjankord> | entering lurk mode |
| 19:25 | <scottjehl> | http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/ |
| 19:25 | <odinho> | zewt: I talked about it, -- and your comment seemed to be pointed at me. |
| 19:26 | <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. |
| 19:26 | <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. |
| 19:26 | <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 |
| 19:27 | <MarcDrummond> | Obviously, process is important, but what we really care about is the implementation for responsive images. |
| 19:27 | <zewt> | MarcDrummond: that belongs on the list, most of the time |
| 19:28 | <MarcDrummond> | And so the wheel continues to spin. |
| 19:28 | <zewt> | ... |
| 19:28 | <jgraham> | MarcDrummond: If you have points that require real-time interaction feel free to discuss them here |
| 19:28 | <jgraham> | If you have points that you want documented, use the wiki or the mailing list |
| 19:29 | <jmather> | scottjehl: thanks for the link |
| 19:30 | <odinho> | zewt: Hehe, I know very well about the krijnhoetmer.nl public logs. :-) I ever wrote a irc log indexer internally for Opera. |
| 19:31 | <tantek> | thanks scottjehl for the ALA link - I added it to: http://www.w3.org/wiki/Images#see_also |
| 19:31 | <tantek> | thanks scottjehl for the ALA link - I added it to: http://www.w3.org/wiki/Images#see_also |
| 19:31 | <tantek> | (which you should feel free to edit directly as well) |
| 19:32 | <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. |
| 19:33 | <odinho> | MarcDrummond: It has nothing to do with how the picture is presented. None whatsoever. |
| 19:33 | <jmather> | MarcDrummond: I think srcset only sets rules on when to use which image, you can size it with css width/hight as normal |
| 19:33 | <odinho> | MarcDrummond: You can write 100000000w for a picture that is 234px wide. |
| 19:33 | <odinho> | MarcDrummond: You can write 100000000w for a picture that is 234px wide. |
| 19:33 | <scottjehl> | sure thing |
| 19:33 | <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). |
| 19:33 | <tantek> | A solution that fails to solve the "important" use-cases is useless. |
| 19:34 | <tantek> | s/solution/implementation etc. |
| 19:34 | <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) |
| 19:34 | <jmather> | scottjehl: this is totally OT, but i've been following your trip on twitter -- absolutely fantastic. It must be incredible. |
| 19:34 | <jmather> | scottjehl: this is totally OT, but i've been following your trip on twitter -- absolutely fantastic. It must be incredible. |
| 19:35 | <jgraham> | Right, the Aw Bh syntax is *somewhat* like a max-width:Apx max-height:Bpx media query |
| 19:35 | <tantek> | zewt - apparently the list has a wider audience that includes sufficient misinformation (the "go away" email on whatwg) to actually *harm* discussion. |
| 19:35 | <tantek> | zewt - apparently the list has a wider audience that includes sufficient misinformation (the "go away" email on whatwg) to actually *harm* discussion. |
| 19:35 | <jgraham> | Uh, +viewport somewhere |
| 19:36 | <zewt> | tantek: that's uncommon, and present in all media |
| 19:36 | <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? |
| 19:36 | <jgraham> | It basically means "don't display this image unless the viewport is at least A x B" |
| 19:36 | <tantek> | zewt - nope. such miscommunication is quickly corrected in places like IRC. but not apparently email. |
| 19:36 | <scottjehl> | jmather ah! Kind of you to say, thanks :) |
| 19:36 | <tantek> | this is a failing of email, and especially heavy lists. |
| 19:36 | <tantek> | too much crap goes by that no one bothers to correct, so it gets propagated. |
| 19:37 | <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 |
| 19:37 | <jgraham> | MarcDrummond: tantek has an aversion to mailing lists which he spreads with evangelical fervour |
| 19:37 | <jmather> | scottjehl: not kind really… I'm just jealous. Hah. |
| 19:37 | <tantek> | jgraham - you can stop the ad hominem anytime you like. |
| 19:37 | <jgraham> | tantek: Which part isn't true? |
| 19:37 | <tantek> | I'm simply communicating based on actual experiences (with citations) |
| 19:37 | <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 |
| 19:37 | <tantek> | you're on the otherhand simply being defensive about emailing lists |
| 19:38 | <odinho> | othermaciej: Nice summary. |
| 19:38 | <jgraham> | tantek: "Citations" being more or less anecdotes |
| 19:38 | <tantek> | othermaciej - right, whatwg list works as inbox for Hixie, beyond that, it's effectively a support forum. |
| 19:38 | <jgraham> | I'm saying that overall the WHATWG list has been super-effective |
| 19:38 | <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 |
| 19:39 | <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. |
| 19:39 | <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. |
| 19:40 | <jgraham> | But I am not really interested in discussing the merits of these things |
| 19:40 | <jmather> | scottjehl: I was a little disheartened when Jen pointed me to your picture implementation though. I thought I had something novel… :D |
| 19:40 | <tantek> | then why do you keep bringing it up? |
| 19:40 | <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 |
| 19:40 | <tantek> | othermaciej - it's a support forum for standards development for folks who don't realize they need a support forum. |
| 19:40 | <jgraham> | The fact is that in order to engage with WHATWG/Hixie the mailing list is the primary veichle |
| 19:40 | <bjankord> | Agreed |
| 19:41 | <tantek> | nah, the whatwg list is a nice convenient public inbox for Hixie, nothing more really. |
| 19:41 | <jgraham> | But you keep trying to discourage its use |
| 19:41 | <scottjehl> | dropping off. |
| 19:41 | <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 |
| 19:41 | <scottjehl> | dropping off. |
| 19:41 | <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 |
| 19:41 | <jgraham> | and are trying to coin some phrase to keep people away from it (the support forum thing) |
| 19:41 | <tantek> | othermaciej, sure, because Hixie prefers it as his inbox, so it makes sense to send emails to whatwg accordingly. |
| 19:42 | <tantek> | jgraham, I'm not trying to discourage you from contributing to a support forum, please go on doing so. |
| 19:42 | <jgraham> | See there we go again |
| 19:42 | <jgraham> | It is tiresome |
| 19:42 | <jgraham> | Plese stop |
| 19:42 | <jgraham> | We are not children |
| 19:42 | <othermaciej> | tantek: it is kind of trollish to refer to a communication medium repeatedly using a term that its participants would not self-apply |
| 19:43 | <tantek> | primarily Hixie's inbox? |
| 19:43 | <othermaciej> | "support forum" |
| 19:44 | <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⊙wo Discussion from interested parties is welcome." |
| 19:44 | <othermaciej> | in my experience, many active participants on the list see it that way as well |
| 19:44 | <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. |
| 19:45 | <tantek> | btw - I would say the same about public-html as well FWIW. |
| 19:45 | <othermaciej> | you may well have a point that discussion lists have intrinsic dysfunctions by nature |
| 19:45 | <tantek> | sure, there are intrinsic dysfunctions, that's perhaps a broader statement. |
| 19:45 | <othermaciej> | but referring to the discussion list with a dismissive term is somewhat rude and not a very effective way to make that point |
| 19:45 | <tantek> | I mean more that discussion lists tend to become support forums, and have seen this occur with pretty much every standards list. |
| 19:46 | <othermaciej> | doing so is likely to generate more heat than light |
| 19:46 | <jgraham> | I am unaware of any communication medium that doesn't have some dysfunction |
| 19:46 | <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. |
| 19:47 | <jgraham> | And for any reasonable definition of "support forum" the whatwg list isn't. People almost never ask how-to type questions there. |
| 19:47 | <tantek> | you're right that it will/does cause some to react defensively and simply dig-in to support a tradition. |
| 19:47 | <jgraham> | Anyway like I say, this is dull |
| 19:47 | <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/ |
| 19:48 | <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 |
| 19:48 | <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. |
| 19:48 | <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 |
| 19:48 | <ShaneHudson> | I was surprised to see he was able to ublish to ALA so quickly,I would expect to wait for ages! |
| 19:48 | <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. |
| 19:48 | <tantek> | MarcDrummond, why limit yourself to two possible solutions? |
| 19:48 | <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. |
| 19:48 | <tantek> | MarcDrummond, why limit yourself to two possible solutions? |
| 19:49 | <tantek> | when the use-cases aren't even broadly understood, prioritized, and agreed upon? |
| 19:49 | <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' |
| 19:49 | <tantek> | othermaciej - I'm not sure about that, I think if Hixie is influenced, that's sufficient for change (in the spec or elsewhere) |
| 19:49 | <tantek> | othermaciej - I'm not sure about that, I think if Hixie is influenced, that's sufficient for change (in the spec or elsewhere) |
| 19:50 | <tantek> | the "community" doesn't really have much power in that way |
| 19:51 | <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. |
| 19:52 | <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 |
| 19:52 | <ShaneHudson> | So is Hixie in charge of the entire spec? Still trying to get my head around the pecking order |
| 19:52 | <necolas> | tantek: agreed. it shouldn't be about one early proposal vs another. |
| 19:52 | <tantek> | ShaneHudson, yes, Hixie is the editor of HTML. |
| 19:53 | <othermaciej> | Hixie derives his influence in large part from being responsive to other influential people |
| 19:53 | <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. :) |
| 19:53 | <annevk> | tantek: is there a wiki page for your suggested process or do I have to extract it from the IRC logs somehow? |
| 19:53 | annevk | can probably read a little backlog |
| 19:53 | <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. |
| 19:53 | <ShaneHudson> | tantek: Thanks.. I didn't realise before there was one person in charge |
| 19:53 | <tantek> | annevk - I was citing whatwg FAQ earlier. |
| 19:53 | <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 |
| 19:54 | <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 |
| 19:54 | <tantek> | jmather - you're right, this discussion is likely beyond the point of diminishing returns. |
| 19:54 | <annevk> | tantek: I thought your point was that the mailing list didn't work; I was wondering what you think would be better |
| 19:54 | <annevk> | tantek: I thought your point was that the mailing list didn't work; I was wondering what you think would be better |
| 19:54 | <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). |
| 19:54 | <tantek> | annevk - I've continuously reiterated the request for well documented use-cases. |
| 19:54 | <ShaneHudson> | tantek: I am working on the use-cases now :) |
| 19:54 | <tantek> | which from my understanding is what WHATWG tends to prefer ;) |
| 19:55 | <annevk> | tantek: there's http://wiki.whatwg.org/wiki/Adaptive_images |
| 19:55 | <MarcDrummond> | tantek: But I'm quessing your question was rhetorical, since you know all that. |
| 19:55 | <tantek> | annevk - that page is problematic because it presumes <picture> too much |
| 19:55 | <annevk> | tantek: and they have been provided via email too, I think Hixie mentioned them upfront |
| 19:55 | <annevk> | tantek: easy enough to read around that |
| 19:55 | <jgraham> | annevk: Beter to edit around it |
| 19:55 | <jgraham> | i.e. rewrite the page |
| 19:55 | <othermaciej> | annevk: do you understand how the "DOM Scripting and Bandwidth" item on that paye is a use case? |
| 19:55 | <tantek> | annevk - better is: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ |
| 19:55 | <jgraham> | But some people wanted accounts |
| 19:55 | <tantek> | but that's not on a wiki page |
| 19:56 | <jgraham> | Do you have admin access? |
| 19:56 | <tantek> | so it can't be edited/ prioritized etc. |
| 19:56 | <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 |
| 19:56 | <annevk> | othermaciej: I don't agree with all the use cases :) |
| 19:56 | <ShaneHudson> | http://www.w3.org/wiki/Images |
| 19:56 | <annevk> | jgraham: I do |
| 19:56 | <jgraham> | Someone also started a page on the W3C wiki, but you need a W3C ccount to edit that |
| 19:56 | <annevk> | haha |
| 19:56 | <annevk> | four places already |
| 19:56 | <tantek> | annevk - exactly, we need this on a wiki so we can all contribute to the use-cases |
| 19:56 | <annevk> | way to go internet :) |
| 19:56 | <tantek> | annevk - exactly, we need this on a wiki so we can all contribute to the use-cases |
| 19:56 | <ShaneHudson> | (I am writing it at the moment, but that is the page it will be) |
| 19:57 | <tantek> | thanks ShaneHudson |
| 19:57 | <tantek> | thanks ShaneHudson |
| 19:57 | <jgraham> | tantek: Which of the muliple wikis it is on did you have in mind |
| 19:57 | <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 |
| 19:57 | <jgraham> | (all with non-overlapping sets of authorised users) |
| 19:57 | <jmather> | othermaciej: I think someone is working on that... |
| 19:57 | <tantek> | othermaciej - my conclusion exactly |
| 19:57 | <annevk> | tantek: anyway I was talking about your meta point, the mailing list being a "support forum" |
| 19:57 | <ShaneHudson> | In fact, if everyone wants to post or email (shane⊙sn) what use-cases you think there are then I will compile them with the others |
| 19:57 | <jmather> | but i could have misunderstood what's going on here. :D |
| 19:57 | <Philip`> | Someone should set up a Tumblr with a list of all the wikis |
| 19:57 | <annevk> | tantek: you mentioned that irl before, but I didn't quite what you meant or what you want to replace it with |
| 19:58 | <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 |
| 19:59 | <jgraham> | That seems to exclude most developers |
| 19:59 | <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. |
| 19:59 | <jgraham> | Also, http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ is indeed very nice |
| 19:59 | <jmather> | jgraham: which is kind of what is causing the current uproar, which might not want to be perpetuated... |
| 19:59 | <tantek> | annevk - here's some more reading on it: http://microformats.org/wiki/wiki-better-than-email |
| 20:00 | <tantek> | jgraham - yes, even just moving that blog post to a wiki for iteration would be a huge help |
| 20:00 | <ShaneHudson> | jgraham: I will add those points in that article to the wiki. Please stop moaning, instead helping would be appreciated |
| 20:00 | <tantek> | I think we just need to give ShaneHudson some time to update w3.org/wiki/Images :) |
| 20:00 | <jmather> | I don't think Anselm would be upset if someone copy/pasted it. |
| 20:01 | anatolbroder | just wants to tell thank you to othermaciej and other nice guys who brought the srcset attribute |
| 20:01 | <othermaciej> | very little of the credit goes to me! |
| 20:02 | <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) |
| 20:05 | <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/ |
| 20:06 | <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." |
| 20:06 | <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 |
| 20:07 | <annevk> | tantek: mkay, I think we use wikis pretty often actually; they just haven't been used in this instance |
| 20:07 | <annevk> | tantek: mkay, I think we use wikis pretty often actually; they just haven't been used in this instance |
| 20:07 | <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? |
| 20:07 | <tantek> | jgraham - if you could provide a link to your criticisms of the w3c wiki, I'd like to understand that better. thanks. |
| 20:07 | <jgraham> | tantek: How does one get an account? |
| 20:07 | <tantek> | annevk - agreed. that was part of my point. |
| 20:07 | <annevk> | tantek: see e.g. timed tracks, the recent canvas additions |
| 20:07 | <tantek> | annevk - agreed. that was part of my point. |
| 20:08 | <ShaneHudson> | jmather: it is easier to access the w3c wiki than it is the whatwg, which is why we decided on it |
| 20:08 | <ShaneHudson> | General question (perhaps tantek could answer).. I presume everyone is fine with me writing the wiki in British English? |
| 20:08 | <tantek> | jgraham, right at the top of the home page: http://www.w3.org/wiki/Main_Page |
| 20:08 | <tantek> | Request a Public W3C Account to get started. |
| 20:08 | <tantek> | Request a Public W3C Account to get started. |
| 20:09 | <tantek> | where Public W3C Account links to: |
| 20:09 | <tantek> | http://www.w3.org/Help/Account/Request/Public |
| 20:09 | <MarcDrummond> | Wish somebody would answer jmather's very reasonable question. |
| 20:09 | <tantek> | since it's right at the top of the home page, I'm not sure how that could be made more obvious |
| 20:09 | <import-logic> | ShaneHudson: I don't see why it would matter, if anyone had a problem with that they would be way too picky :) |
| 20:09 | <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 |
| 20:09 | <tantek> | (i.e. not sure that adding it to an FAQ would help any) |
| 20:09 | <jgraham> | tantek: It sounds a lot like it is for people who are becoming invited experts |
| 20:10 | <import-logic> | jmather: lol'd |
| 20:10 | <jgraham> | Anyway if it works for people I don't care |
| 20:10 | <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 ..." |
| 20:11 | <tantek> | if you'd like to suggest different prose, I'm sure we could ask W3C to improve the content. |
| 20:11 | <tantek> | if you'd like to suggest different prose, I'm sure we could ask W3C to improve the content. |
| 20:11 | <annevk> | afaik they can be created by anyone |
| 20:11 | <annevk> | if people want an account on the WHATWG wiki btw I can create them |
| 20:11 | <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." |
| 20:11 | <tantek> | jmather, exactly, perhaps consider the sign-up form to be a light-weight captcha ;) |
| 20:11 | <annevk> | we disabled account creation because of the amount of spam :( |
| 20:11 | <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.) |
| 20:11 | <jgraham> | Neither of which is the case here |
| 20:11 | <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 |
| 20:12 | <annevk> | jreading: MQs don't handle the pixel density case |
| 20:12 | <jgraham> | jmather: If all the people who are interested in contributing have accounts there, that's fine |
| 20:12 | <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 |
| 20:12 | <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 |
| 20:12 | <jmather> | annevk: I thought they did? |
| 20:12 | <annevk> | jreading: they can query it, but you need to set the pixel density |
| 20:13 | <jgraham> | http://www.w3.org/wiki/index.php?title=Special:UserLogin&returnto=Main_Page then "Account Request Form" |
| 20:13 | <tantek> | a-ha! thanks |
| 20:14 | <tantek> | that page, http://www.w3.org/Help/Account/ , is quite confusing :/ |
| 20:14 | <jmather> | jreading: hrm… i haven't seen anything about statefulness… link? |
| 20:15 | <jmather> | annevk: which pixel density case? link? |
| 20:15 | <annevk> | jmather: you cannot do <img src=lala srcset="tralla 2x"> in a way that works properly using the <picture> proposal |
| 20:16 | <MarcDrummond> | annevk: Why not? |
| 20:16 | <jmather> | annevk: device-pixel-ratio: 2 in the media query should do it, no? |
| 20:16 | <annevk> | jmather: how does that downscale "trallla"? |
| 20:16 | <annevk> | "lala" is 10x10; "tralla" is obviously 20x20 |
| 20:17 | <jmather> | the width/height defined to the pixel element forms the size from what I understand (if I get your question right) |
| 20:17 | <annevk> | if you just display tralla it would be way bigger |
| 20:17 | <ShaneHudson> | Is resolution and DPI technically synomynous? |
| 20:17 | <annevk> | jmather: so each source element would always have a width/height attribute? |
| 20:17 | <annevk> | ShaneHudson: sure |
| 20:17 | <annevk> | jmather: because all the <picture> examples got this wrong |
| 20:17 | <jreading> | width/height attrs |
| 20:17 | <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. |
| 20:17 | <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. |
| 20:17 | <ShaneHudson> | annevk: thanks |
| 20:17 | <annevk> | jmather: so nobody seems to be knowing what is going on |
| 20:17 | <jmather> | annevk: from my understanding, sizing would work the same with srcset and picture |
| 20:17 | <annevk> | jmather: and including them all over seems bloat |
| 20:18 | <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 |
| 20:18 | <scottjehl> | img: max-width: 100%; is commonly used in responsive layouts. It'd address that |
| 20:18 | <annevk> | jmather: again, how does <picture> downscale it if you don't set height/width? |
| 20:18 | <annevk> | scottjehl: that doesn't work for icons |
| 20:18 | <jreading> | and why not work to improve MQs instead of creating a whole new spec outside of that... |
| 20:18 | <scottjehl> | icons? |
| 20:18 | <MarcDrummond> | annevk: why prioritize avoiding code bloat over clarity for authors and extensibility? |
| 20:19 | <annevk> | jreading: MQ is about reading device info, it's not about sizing images |
| 20:19 | <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 |
| 20:19 | <annevk> | MarcDrummond: dunno, you think including height/width attributes all over is better? |
| 20:19 | <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 |
| 20:19 | <annevk> | jmather: we don't know the ratio |
| 20:19 | <jmather> | annevk: no other width/height would be included than with srcset |
| 20:19 | <jmather> | annevk: no other width/height would be included than with srcset |
| 20:19 | <jmather> | annevk: but we do |
| 20:19 | <annevk> | jmather: how? |
| 20:20 | <scottjehl> | icons are the use case the makes picture impractical? |
| 20:20 | <jmather> | device-pixel-ratio knows the density |
| 20:20 | <scottjehl> | the/that |
| 20:20 | <jmather> | and then downloading the picture gets the dimensions |
| 20:20 | <annevk> | scottjehl: no |
| 20:20 | <annevk> | jmather: what if the ratio of the device is greater than 2? |
| 20:20 | <annevk> | jmather: you need to know the ratio of the image, not the device |
| 20:20 | <jmather> | on a 2x image, 1/2 the width/height would be the natural display size |
| 20:21 | <annevk> | but the MQ applies to the device, not the image... |
| 20:21 | <annevk> | but the MQ applies to the device, not the image... |
| 20:21 | <jmather> | annevkhwo often do you include images with no width/height? |
| 20:21 | <jmather> | I've never done it, at least recently |
| 20:21 | <annevk> | jmather: I do it all the time, but I'm told I'm not a normal author |
| 20:21 | <jmather> | always at least width |
| 20:21 | <annevk> | but you are shifting the argument now |
| 20:21 | <annevk> | but you are shifting the argument now |
| 20:21 | <jmather> | but then my main job is maintaining a CMS, so I have a different angle than a lot of people :) |
| 20:21 | <annevk> | and again |
| 20:21 | <scottjehl> | very common in responsive design to omit width and height attrs |
| 20:22 | <annevk> | all the <picture> examples thus far got this wrong |
| 20:22 | <jmather> | Not trying to shift the argument, just answering your questions |
| 20:22 | <scottjehl> | annevk - I'm unclear what "this" is that you're referring to |
| 20:22 | <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? |
| 20:22 | <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 |
| 20:22 | <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? |
| 20:22 | <jmather> | scottjehl: but even then you would still have width: 100% or whatnot in the css applied to it somewhere, right? |
| 20:22 | <scottjehl> | jmather yes max-width: 100% is the usual fluid images CSS |
| 20:23 | <jmather> | right |
| 20:23 | <jmather> | annevk's argument is what happens when there is /no/ width/height guideline |
| 20:23 | <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 |
| 20:23 | <annevk> | MarcDrummond: <img src=x srcset="y 2x"> x is 10x10; y is 20x20 |
| 20:23 | <annevk> | MarcDrummond: tell me how to do that with <picture> |
| 20:23 | <jreading> | <picture> <source media="device-pixel-densiity:2" src="2xbig.jpg" width="50%"> |
| 20:23 | <jreading> | how's that? |
| 20:24 | <annevk> | that's not the same |
| 20:24 | <jreading> | .picture {width:100%} |
| 20:24 | <scottjehl> | no no. width: 100% would stretch an image, sure. But max-width: 100% never goes beyond the dimensions of the image itself |
| 20:24 | <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 |
| 20:24 | <ShaneHudson> | tantek: Thanks, I don't think I am ready to write the actual spec quite yet :p |
| 20:24 | <annevk> | scottjehl: it would be displayed four times the size if you just use max-width |
| 20:24 | <ShaneHudson> | Hard enough writing a wiki haha |
| 20:24 | <MarcDrummond> | annevk: <picture alt=""> <source src="x.jpg" /> <source src="y.jpg" media="min-device-pixel-ratio: 2" /> <img src="x.jpg" /> </picture> |
| 20:25 | <annevk> | MarcDrummond: yeah that fails |
| 20:25 | <MarcDrummond> | annevk: Why? |
| 20:25 | <annevk> | MarcDrummond: if y is selected it would be displayed four times as big as x |
| 20:25 | <jmather> | annevk: why? |
| 20:25 | <jgraham> | FWIW I think this is reenforcing my belief that media queries are only a superficially good match for this use case |
| 20:25 | <annevk> | the reason is this |
| 20:25 | <MarcDrummond> | annevk: I don't see why that would be the case. |
| 20:25 | <annevk> | the reason is this |
| 20:25 | <MarcDrummond> | annevk: I don't see why that would be the case. |
| 20:26 | <annevk> | MQ asks the device if it's pixel ratio is at least 2; device says yes |
| 20:26 | <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 |
| 20:26 | <annevk> | browser thus selects y |
| 20:26 | <tantek> | ShaneHudson - just figured I'd give you a heads-up and provide citations accordingly ;) |
| 20:26 | <annevk> | browser starts laying out y |
| 20:26 | <annevk> | its 20x20 |
| 20:26 | <annevk> | there's no information about DPI associated with the image thus the browser uses 1 CSS pixel for each image pixel |
| 20:26 | <MarcDrummond> | annevk: That association goes in the CSS. |
| 20:27 | <annevk> | and you get something that's four times as big as x |
| 20:27 | <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> |
| 20:27 | <annevk> | MarcDrummond: are you saying your example was incomplete? |
| 20:27 | <jreading> | pave the freakin' cowpaths |
| 20:27 | <jmather> | annevk: I see where you're coming from, but I don't think it actually works out as a problem in actual practice. |
| 20:27 | <annevk> | jreading: that's not the same as my example |
| 20:27 | <annevk> | jmather: it's a problem in all the <picture> examples |
| 20:27 | <scottjehl> | jmather +1 |
| 20:28 | <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 |
| 20:28 | <jmather> | logically, I totally see your point |
| 20:28 | <jmather> | but scott says he hasn't seen this particular issue actually occur in the wild |
| 20:28 | <jgraham> | Isn't that going to break if the pixel ratio is not exactly 2 |
| 20:28 | <jmather> | and he's done quite a bit of leg-work regarding picture |
| 20:28 | <annevk> | well he's wrong |
| 20:28 | <jmather> | and he's done quite a bit of leg-work regarding picture |
| 20:29 | <jmather> | annevk: umm, not sure how actual results from testing an implementation directly are … wrong. |
| 20:29 | <MarcDrummond> | annevk: Why do you say he's wrong. Have you tested this? He has. |
| 20:30 | <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 |
| 20:30 | <annevk> | I can tell he's wrong because I know how media queries and images work |
| 20:30 | <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? |
| 20:30 | <scottjehl> | no the testing we did was more... deliver a higher density image to a retina iphone |
| 20:31 | <TabAtkins> | If you're using explicit sizes on the <img>, it'll "work", because the browser is downscaling. |
| 20:31 | <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. |
| 20:31 | <TabAtkins> | And in a retina environment, the downscaling will work well. |
| 20:31 | <jmather> | I don't think we have any 3x displays to test on yet annevk |
| 20:31 | <annevk> | jmather: not sure how that's an argument |
| 20:31 | <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. |
| 20:31 | <annevk> | scottjehl: I'd be interested in a pointer to the test |
| 20:32 | <jmather> | annevk: basically just that there's time to solve it |
| 20:32 | <annevk> | jmather: it doesn't work now either |
| 20:32 | <annevk> | jmather: unless you specify width/height all the time which is rather insane |
| 20:32 | <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? |
| 20:32 | <annevk> | if you ask me anyway |
| 20:32 | <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? |
| 20:33 | <jmather> | so, specify width/height? :) |
| 20:33 | <jmather> | I dunno. |
| 20:33 | <jreading> | scottjehl: that's what I'm trying to figure out wtf they are saying... |
| 20:33 | <jmather> | What does srcset do with a 2x image on a 3x display? |
| 20:33 | <TabAtkins> | Whatever the UA decides is appropriate. |
| 20:34 | <scottjehl> | did my example make sense? |
| 20:34 | <TabAtkins> | Yeah, that example works. |
| 20:35 | <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 |
| 20:35 | <scottjehl> | that's what I imagine to be the 95% use case |
| 20:35 | <TabAtkins> | If you set a size, the "original" size doesn't matter. |
| 20:35 | <jmather> | TabAtkins: but what is spec'd to happen? |
| 20:35 | <annevk> | it doesn't seem at all clean to me to not have that semantic embedded |
| 20:35 | <TabAtkins> | jmather: Literally what I just said. |
| 20:35 | <scottjehl> | right. this fact can be used to our advantage. How is this a failing of picture? |
| 20:36 | <jmather> | TabAtkins: that sounds like IE all over again. Not trying to start aright, just saying, that sounds highly … open to … alternative implementations. |
| 20:36 | <annevk> | scottjehl: it requires a bunch of extra attributes |
| 20:36 | <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. |
| 20:36 | <scottjehl> | what attributes? |
| 20:36 | <annevk> | width/height |
| 20:37 | <annevk> | if CSS is disabled the image will be way large |
| 20:37 | <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 |
| 20:37 | <annevk> | *otherwise |
| 20:37 | <scottjehl> | tabatkins that's a very different subject, no? |
| 20:37 | <scottjehl> | annevk no width or height attrs are used here |
| 20:37 | <TabAtkins> | scottjehl: Not really, no. |
| 20:37 | <annevk> | scottjehl: exactly, but you need to |
| 20:37 | <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. |
| 20:37 | <TabAtkins> | If you're doing *anything* with high-res images, you want the browser to be the one deciding when to request them. |
| 20:37 | <annevk> | scottjehl: because otherwise with CSS disabled it'll turn ugly |
| 20:38 | <jmather> | TabAtkins: your first paragraph after tl;dr is … i believe highly inccorect |
| 20:38 | <jmather> | that's the central starting point for any responsive image implantation, i think |
| 20:38 | <jmather> | that or ipad3… either way |
| 20:38 | <scottjehl> | annevk... disabling css on a retina ipad is the reason picture isn't practical? |
| 20:39 | <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. |
| 20:39 | <jmather> | annevk: can you even disable css on an iPad in safari? |
| 20:39 | jmather | has never even thought to try |
| 20:40 | <annevk> | that was just to illustrate a point |
| 20:40 | <annevk> | that you want the semantic that the image is twice its actual size in the markup |
| 20:40 | <MarcDrummond> | What point? What use case are you highlighting where this wouldn't work? |
| 20:40 | <annevk> | so that if you do anything with that image it's known what is going on |
| 20:41 | <scottjehl> | partially kidding there, but seriously, this doesn't seem like a real problem we're facing |
| 20:41 | <jmather> | annevk: thus why with picture you instruct the element to it's size and then source is used to fill the element |
| 20:42 | <jmather> | annevk: which is why the styling/sizing applies to picture and then whatever source is selected is used to fill it |
| 20:42 | <TabAtkins> | jmather: Interesting. private message me to discuss? |
| 20:43 | <annevk> | jmather: that doesn't work if you want to vary both width and pixel density |
| 20:43 | <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 |
| 20:43 | <annevk> | scottjehl: e.g. you hit that problem as soon as you draw the image on a <canvas> |
| 20:43 | <scottjehl> | I could easily update the picture demo to include a high-density source |
| 20:43 | <annevk> | scottjehl: because instead of only taking up 500px it would take up 1000px |
| 20:44 | <TabAtkins> | jmather: I meant relative to your assertion that my tl;dr paragraph is wrong. |
| 20:44 | <jmather> | the iPad/iphone retina displays are what threw so much fuel on the fire of getting something working |
| 20:44 | <TabAtkins> | jmather: I meant relative to your assertion that my tl;dr paragraph is wrong. |
| 20:44 | <jmather> | the iPad/iphone retina displays are what threw so much fuel on the fire of getting something working |
| 20:44 | <annevk> | scottjehl: whereas with srcset we know the image is only 500px because of the 2x indicator |
| 20:44 | <scottjehl> | that also seems fairly avoidable to me |
| 20:44 | <scottjehl> | that also seems fairly avoidable to me |
| 20:44 | <jmather> | TabAtkins: not your tl;dr, first para after. |
| 20:44 | <TabAtkins> | jmather: Oh, that's even more interesting if you think it's wrong. |
| 20:44 | <annevk> | jmather: yeah and only Apple managed to make a proposal that works |
| 20:44 | <annevk> | jmather: yeah and only Apple managed to make a proposal that works |
| 20:44 | <annevk> | thus far anyway |
| 20:45 | <scottjehl> | that's unfair, I think |
| 20:45 | <krijnh> | Quiet day on the internets today, what's happening? |
| 20:45 | <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. |
| 20:45 | <jmather> | annevk: the only time that comes in to play is when no dimensions of any kind are set on picture |
| 20:46 | <TabAtkins> | jmather: Oh, okay. Well, the proposals that the CG put forward weren't taking resolution into account, afaict. |
| 20:46 | <jgraham> | krijnh: Heh. Going for gold in your own logs? |
| 20:46 | <annevk> | jmather: actually no, that would always occur |
| 20:46 | <annevk> | jmather: actually no, that would always occur |
| 20:46 | <jmather> | i don't know how to get any sort of statistics on that, but i would have to bet it's fairly low |
| 20:46 | <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 |
| 20:46 | <annevk> | jmather: unless there's a semantic that tells the pixel density |
| 20:47 | <TabAtkins> | jreading: Note my blog post linked above - bandwidth is *not* the only consideration you want to make, and it's not static. |
| 20:48 | <jmather> | annevk: it doesn't need pixel density info |
| 20:48 | <jmather> | it needs to know how many css pixels the image has to fill |
| 20:48 | <scottjehl> | what works seems highly subjective here. |
| 20:48 | <scottjehl> | sorry, gotta drop off again. thanks |
| 20:48 | <jreading> | Tab: seems like bandwidth MQ is the only sticking point for why MQs fail with respimgs, no? |
| 20:48 | <jmather> | TabAtkins: depends on what context you mean |
| 20:49 | <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 |
| 20:49 | <jmather> | but i don't think it's really required |
| 20:50 | <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? |
| 20:50 | <MarcDrummond> | annevk: It really seems you are beating an imaginary issue into the ground. |
| 20:50 | <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? |
| 20:50 | <MarcDrummond> | annevk: It really seems you are beating an imaginary issue into the ground. |
| 20:50 | <jmather> | at least from a content guy's perspective… I have a box, 100x100 in css pixels |
| 20:50 | <jmather> | I want it filled with an image |
| 20:50 | <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 |
| 20:51 | <jmather> | ShaneHudson: that's something that really interested me about picture as well |
| 20:51 | <jmather> | not so much in that i think we need it |
| 20:51 | <jmather> | but that it would give room for new file formats to grow |
| 20:51 | <jmather> | like, say, a stereographic image format, perhaps? |
| 20:52 | <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. |
| 20:52 | <annevk> | MarcDrummond: hey man, I'm just telling you what's wrong with <picture> |
| 20:52 | <annevk> | MarcDrummond: at the end of the day, I don't really care what happens here |
| 20:52 | <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. |
| 20:52 | <annevk> | feel free to ignore me |
| 20:53 | <annevk> | MarcDrummond: even if they add width, it would still blow up on <canvas> |
| 20:53 | <MarcDrummond> | annevk: I do care. As do a lot of other developers/authors. Feel free to pay attention to our concerns! |
| 20:53 | <annevk> | MarcDrummond: as I mentioned before |
| 20:53 | <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. |
| 20:53 | <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..." |
| 20:54 | <jmather> | TabAtkins: picture covers for that well |
| 20:54 | <annevk> | jmather: you're coming accross as someone who doesn't want to hear about problems with <picture> |
| 20:55 | <TabAtkins> | jmather: Based on the last thing I've seen of <picture>, it doesn't, unless you hack in @srcset functionality. |
| 20:55 | <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. |
| 20:55 | <annevk> | that ease of authoring is not a serious concern; or drawing images with a higher pixel density on <canvas> is not a concern |
| 20:55 | <TabAtkins> | In which case the difference between "<picture> with <source srcset>" and "<img srcset>" is verbosity and slight differences in how you do fallbacks. |
| 20:55 | <MarcDrummond> | TabAtkins: So, image displays ONLY for retina displays with sufficient bandwidth, otherwise no image at all? That also seems unlikely. |
| 20:56 | <MarcDrummond> | TabAtkins: So, image displays ONLY for retina displays with sufficient bandwidth, otherwise no image at all? That also seems unlikely. |
| 20:56 | <jmather> | TabAtkins: <picture><sourcr src="image⊙2" media="min-device-pixel-ratio: 2"><source src="image.jpg"></picture> I think |
| 20:56 | <jmather> | well, aside from bandwidth, granted |
| 20:56 | <jmather> | but if a bandwidth mq were added, easy enough |
| 20:56 | <annevk> | a bandwidth MQ? haha |
| 20:57 | <gsnedders> | Have we not been over why MQ don't work for bandwidth often enough yet? |
| 20:57 | <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? |
| 20:57 | <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. |
| 20:57 | <annevk> | jmather: expose it how? |
| 20:57 | <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. |
| 20:57 | <annevk> | jmather: did you read Hixie's email explaining the problems with bandwidth and how they're shifting from size to latency etc.? |
| 20:58 | <annevk> | jmather: btw, your media queries thus far miss the required parenthesis and would therefore fail |
| 20:58 | <gsnedders> | FWIW, I don't like the srcset syntax at first glance, but that's a syntatual issue |
| 20:58 | <gsnedders> | FWIW, I don't like the srcset syntax at first glance, but that's a syntatual issue |
| 20:58 | <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 |
| 20:59 | <annevk> | jmather: ease of authoring is important ;) |
| 20:59 | <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? |
| 20:59 | <davatron5000> | jmather: +1 |
| 20:59 | <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 |
| 20:59 | <annevk> | I didn't come up with srcset |
| 20:59 | <annevk> | I don't really care for it either |
| 20:59 | <jmather> | kevinSuttle: I have no idea |
| 21:00 | <annevk> | but given the alternative... |
| 21:00 | <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. |
| 21:00 | <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. |
| 21:00 | <jmather> | but TabAtkins wanted the browser to account for bandwidth in it's downloading provision |
| 21:00 | <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. |
| 21:01 | <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. |
| 21:01 | <zewt> | shouldn't you understand it before deciding you don't like it :) |
| 21:01 | <jmather> | zewt: gut instincts are there for a reason :) |
| 21:01 | <jmather> | not to say they can't be wrong |
| 21:02 | <jreading> | so i think the srcset folks agree with me that bandwidth MQ is a bad idea |
| 21:02 | <jreading> | also, seems that's the ONLY sticking point |
| 21:02 | <jreading> | so lose it |
| 21:02 | <gsnedders> | jmather: Someone saying an issue with picture (or bandwidth MQs, etc.) doesn't mean they like srcset is my point |
| 21:03 | <jmather> | gsnedders: true enough |
| 21:03 | <zewt> | (you can do bandwidth without trying to actually strictly define it, eg. as i suggested with the file-size hint) |
| 21:03 | <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? |
| 21:03 | <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? |
| 21:03 | <annevk> | zewt: but not in MQs |
| 21:03 | <annevk> | MQs are about device capabilities |
| 21:03 | <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>). |
| 21:03 | <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>). |
| 21:03 | <jmather> | kevinSuttle: I think it's mainly because video/audio is considered "done" with the tags |
| 21:03 | <annevk> | whereas we are concerned here with capabilities from the image |
| 21:03 | <zewt> | annevk: i'm talking about srcset, don't know much of anything about MQ |
| 21:04 | <annevk> | such as its size and aspect ratio |
| 21:04 | <gsnedders> | jmather: Nah, they aren't done. They can always have more done to them, as can img. |
| 21:04 | <jmather> | TabAtkins: at which point with html , verbose and readable usually wins |
| 21:04 | <zewt> | and file size, which is a relative representation of content quality (relative to the other options, at least) |
| 21:04 | <jreading> | and if the concern is the flipping on/off of bandwidth MQ, make them behave differently or lose it |
| 21:04 | <TabAtkins> | jmather: That's an arguably point. ^_^ |
| 21:04 | <jmather> | Unfortunately I have to take off now :) |
| 21:04 | <annevk> | using device queries (=MQs) for resource selection is the wrong solution (for <video> too imo) |
| 21:04 | <annevk> | using device queries (=MQs) for resource selection is the wrong solution (for <video> too imo) |
| 21:04 | <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? |
| 21:05 | <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? |
| 21:05 | <jmather> | TabAtkins: it does seem to go back and forth, but I do like matt's argument that picture is less error brone |
| 21:05 | <jmather> | kevinSuttle: because html video sucks. :D |
| 21:05 | <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 reason |
| 21:05 | <annevk> | jmather: I haven't seen much people make mistakes with srcset yet, plenty with <picture> though... |
| 21:05 | <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. |
| 21:06 | <jreading> | so bandwidth MQ is out and <picture> is back in, right? |
| 21:06 | <zewt> | (nothing screams troll like calling someone a "dictator"; do you even know how standards work?) |
| 21:06 | <jmather> | alright, c-ya guys. Gotta run. |
| 21:06 | <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? |
| 21:06 | <annevk> | me too |
| 21:06 | <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. |
| 21:06 | <TabAtkins> | MarcDrummond: HTML is a benevolent dictatorship, but that seems to be a successful model for tech. |
| 21:07 | <gsnedders> | It doesn't matter whether the use-cases are documented in one place or fourty. It'd be nice for the former, but… |
| 21:07 | <MarcDrummond> | zewt: Thank you for your condescension. |
| 21:07 | <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… |
| 21:07 | <zewt> | TabAtkins: it's not, since implementors effectively have (as a unit, not individually) veto power |
| 21:08 | <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. |
| 21:08 | <gsnedders> | zewt: Well, as a unit of two or more |
| 21:08 | <gsnedders> | Not necessarily as a unit of all of them. |
| 21:09 | <zewt> | gsnedders: sure--just didn't want to claim that they *individually* have veto power (it just gets muddier when just one vendor balks) |
| 21:09 | <gsnedders> | zewt: Yeah, I was just trying to clarify more than correct *you*. I think you know well enough how things work. |
| 21:09 | <bjankord> | What happens when Hixie makes bad choices? |
| 21:10 | <zewt> | everyone tells him :) |
| 21:10 | <bjankord> | Does he listen? |
| 21:10 | <bjankord> | Does he care? |
| 21:10 | <TabAtkins> | If he doesn't, browsers do what they want anyway. |
| 21:10 | <TabAtkins> | And that means the spec doesn't match brwosers, which lowers the reputation of the spec and it's power in general. |
| 21:11 | <TabAtkins> | So yes, it's ultimately the slave of the browsers. |
| 21:11 | Hixie | pops his head in and then ducks the incoming tomatoes |
| 21:11 | <tantek> | but at least they're high-resolution tomatoes. |
| 21:11 | <bjankord> | +1 |
| 21:11 | <Hixie> | 'sup people |
| 21:12 | <Hixie> | please direct your ire at me :-) |
| 21:12 | <adactio> | Oh hai. |
| 21:12 | <Hixie> | happy to answer any questions |
| 21:12 | zewt | BEAM |
| 21:12 | <davatron5000> | Hixie: You have lots of explaining' to do [/rickyricardo] |
| 21:12 | <bjankord> | Hixie: Is there any chance the picture element would be reconsidered |
| 21:12 | <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. |
| 21:12 | <bjankord> | I've heard if it is revised there is a chance that it will be reconsidered |
| 21:13 | <Hixie> | bjankord: if there is new information, absolutely |
| 21:13 | <Hixie> | bjankord: however generally speaking it's better to talk about use cases, not solutions |
| 21:13 | <Hixie> | bjankord: and to point out what is wrong with the existing solutions |
| 21:14 | <Hixie> | bjankord: so e.g. "srcset="" doesn't address use case X" or "srcset="" is overly complicated for use case X" |
| 21:14 | <necolas> | Hixie: by "existing solutions" do you mean @srcset? |
| 21:14 | <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." |
| 21:14 | <Hixie> | necolas: now, yes |
| 21:14 | <zewt> | zzz |
| 21:14 | <zewt> | zzz |
| 21:14 | <TabAtkins> | adactio: Welcome to a multitude of opinions. |
| 21:14 | <jgraham> | In other news TabAtkins and zewt are the same person |
| 21:15 | <zewt> | :| |
| 21:15 | <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 |
| 21:15 | <TabAtkins> | adactio: That's why references to the "cabal" are so misleading. ^_^ |
| 21:15 | <annevk> | there's disagreement in the cabal? |
| 21:15 | <annevk> | quick krijn, disable public logging! |
| 21:15 | <jgraham> | annevk: Not in #secret-treehouse |
| 21:15 | <Hixie> | bjankord: (the point being that agreement that there is a problem to solve is more important than getting agreement on the solution) |
| 21:15 | <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. |
| 21:16 | <jgraham> | Just for show |
| 21:16 | <annevk> | jgraham: ssssh |
| 21:16 | <bjankord> | Hixie: Would examples of use cases of picture element be helpful, or you specifically looking for use cases of srcset? |
| 21:16 | <tantek> | adactio, I thought the accepted term was BDFL per http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life |
| 21:16 | <zewt> | (I don't feel like dignifying that with a reply, beyond this one) |
| 21:16 | <Hixie> | bjankord: use cases don't mention solutions |
| 21:16 | <necolas> | Hixie: we can consider it progress that it is now agreed that there is a problem to solve |
| 21:16 | <Hixie> | bjankord: use cases don't mention solutions |
| 21:16 | <necolas> | Hixie: we can consider it progress that it is now agreed that there is a problem to solve |
| 21:16 | <Hixie> | bjankord: srcset and <picture> are solutions |
| 21:17 | <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. |
| 21:17 | <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" |
| 21:17 | <Hixie> | MarcDrummond: one of the lessons we learnt from <video> is that hte <source> pattern is a bad one, unfortunately |
| 21:18 | <davatron5000> | The problem with the <source> pattern is multiple codecs across various browsers. not @media, imo. |
| 21:18 | <MarcDrummond> | Hixie: Just curious, in what ways is that markup pattern considered bad? I hadn't heard that. |
| 21:18 | <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. |
| 21:18 | <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 |
| 21:18 | <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 |
| 21:18 | <Hixie> | MarcDrummond: also we really haven't had much luck with media="" on <Source> so far for <video> |
| 21:18 | <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 |
| 21:19 | <zewt> | *blink* |
| 21:19 | <Hixie> | bjankord: you're still talking about solutions not problems :-) |
| 21:19 | <zewt> | *blink* |
| 21:19 | <Hixie> | bjankord: you're still talking about solutions not problems :-) |
| 21:19 | <MarcDrummond> | Hixie: Thanks. Helpful to understand those problems. |
| 21:19 | <MarcDrummond> | Hixie: Thanks. Helpful to understand those problems. |
| 21:19 | <Hixie> | ShaneHudson: i think i listed the use cases that led to srcset="" in my big e-mail, are there others? |
| 21:19 | <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 |
| 21:20 | <Hixie> | necolas: numerous lessons, e.g. the ones i just mentioned. |
| 21:20 | <necolas> | sure, but those are lessons about the actual details |
| 21:20 | <bjankord> | Hixie: Thanks for the feedback, good to know what direction to go from here. |
| 21:20 | <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. |
| 21:20 | <TabAtkins> | Do you mean "the lesson is: don't use <source> children"? |
| 21:20 | <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 |
| 21:20 | <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. |
| 21:20 | <ShaneHudson> | Hixie: Well we realised that all the solutions have been focusing on different use-cases |
| 21:21 | <ShaneHudson> | tantek: good idea |
| 21:21 | <annevk> | TabAtkins: it's not equivalent to max-width |
| 21:21 | <annevk> | TabAtkins: because it would be used for a viewport of 700px |
| 21:21 | <annevk> | (re mailing list) |
| 21:21 | <TabAtkins> | annevk: Oh. So it's equivalent to min-width? |
| 21:21 | <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". |
| 21:21 | TabAtkins | thinks the microsyntax for MQ is a bad idea. |
| 21:21 | <Hixie> | ShaneHudson: in the threads i replied to i'm not sure that was the case, but it's certainly possible. |
| 21:21 | <Hixie> | ShaneHudson: in the threads i replied to i'm not sure that was the case, but it's certainly possible. |
| 21:22 | <annevk> | TabAtkins: it's not a MQ microsyntax though |
| 21:22 | <Hixie> | microsyntax for MQ? |
| 21:22 | <annevk> | TabAtkins: e.g. 2x is not something MQ can do |
| 21:22 | <Hixie> | srcset="" isn't mq |
| 21:22 | <TabAtkins> | Hixie: The "100w 100h" part. |
| 21:22 | <TabAtkins> | Hixie: The "100w 100h" part. |
| 21:22 | <TabAtkins> | annevk: Yes, I'm only talking about the w/h part. |
| 21:22 | <Hixie> | that's just describing the environment for the image, it's not a mq-equivalent |
| 21:22 | <jgraham> | that is a really limited subset of mq |
| 21:22 | <Hixie> | it doesn't evaluate to true or false |
| 21:22 | <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 |
| 21:23 | <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. |
| 21:23 | <jgraham> | necolas: Video had *lots* of discussion and changes to the design |
| 21:23 | <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. |
| 21:23 | <necolas> | im just interested if that is considered one of the lessons learnt, rather than trying to make judgements |
| 21:23 | <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. |
| 21:23 | <Hixie> | TabAtkins: i don't understand the relevance of mq here |
| 21:23 | <zewt> | jgraham: it's describing the image, and leaving what to do with it to the implementation (I believe), which is a different approach |
| 21:24 | <annevk> | adactio: based on the use cases to date |
| 21:24 | <jgraham> | zewt: Well it's not actually describing the image |
| 21:24 | <zewt> | jgraham: describing attributes about the image |
| 21:24 | <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 |
| 21:24 | <necolas> | jgraham: in those discussions, were concerns about verbosity, orphan <source>, rendering logic discussed? or did it not occur at the time? |
| 21:24 | <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. |
| 21:24 | <jgraham> | It's describing some things about the browser environment that will be used to pick the right image |
| 21:24 | <TabAtkins> | Hixie: Correct? |
| 21:25 | <Hixie> | necolas: the problem with <video> is we don't really have a good alternative for handling it other than <source> (and <track>) |
| 21:25 | <Hixie> | necolas: so it's not that we made a bad decision |
| 21:25 | <Hixie> | necolas: so it's not that we made a bad decision |
| 21:25 | <Hixie> | necolas: it did teach us that the decision is not as obviously good as one would have thought |
| 21:25 | <Hixie> | TabAtkins: not really |
| 21:25 | <Hixie> | TabAtkins: the browser can pick whichever image it wants |
| 21:26 | <Hixie> | TabAtkins: there's a recommended algorithm that picks the image based on some priorities |
| 21:26 | <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 |
| 21:26 | <Hixie> | TabAtkins: but even that algorithm doesn't knock things out necessarily |
| 21:26 | <jgraham> | Hixie: BTW "return a random image" in the spec is wrong |
| 21:26 | <necolas> | you live and learn |
| 21:26 | <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 |
| 21:26 | <jgraham> | "return an image according to an algorithm of the UA's choosing" would be right |
| 21:27 | <Hixie> | necolas: yes, all the lessons we learn with everything we do impact how we make future decisions |
| 21:27 | <hober> | jgraham: agreed |
| 21:27 | <Hixie> | jgraham: did i really say "random" in the spec text? |
| 21:28 | <jgraham> | "Optionally, return the URL of a random entry in candidates, and that entry's associated pixel density, and then abort these steps." |
| 21:28 | <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? |
| 21:28 | <Hixie> | jgraham: oh man. let me fix that. |
| 21:28 | <TabAtkins> | Hixie: Yeah, the "if nothing matches, choose X" is fine. But aside from that, it acts like a strict filter, right? |
| 21:28 | <jgraham> | Heh |
| 21:28 | <Hixie> | necolas: of course. that happens with everything we do. |
| 21:28 | <Hixie> | necolas: of course. that happens with everything we do. |
| 21:28 | <jgraham> | TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates |
| 21:29 | <Hixie> | necolas: at the end of the day though it's better to have something mediocre than nothing at all. |
| 21:29 | <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 |
| 21:29 | <Hixie> | TabAtkins: well, modulo the way the UA can do whatever it wants, sure |
| 21:29 | <necolas> | Hixie: in which case, what was compelling enough to add it to the draft before further discussion could take place? |
| 21:29 | <zewt> | TabAtkins: step 16 means "the browser can come up with its own decision/heuristics", from what I understand |
| 21:29 | <zewt> | (the "random" line they're talking about) |
| 21:30 | <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. |
| 21:30 | <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") |
| 21:30 | <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. |
| 21:30 | <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. |
| 21:31 | <jgraham> | MarcDrummond: FWIW I consider that an advantage unless there are other axes along which we have a clear need to vary stuff |
| 21:31 | <Hixie> | MarcDrummond: the format is intentionally extensible |
| 21:31 | <Hixie> | MarcDrummond: but in general unless there's something specific you have in mind, it's good to not be open-ended. |
| 21:31 | <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 |
| 21:31 | <annevk> | wow http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0195.html is an instant classic |
| 21:32 | <zewt> | TabAtkins: (oh. it says as much in the note right below it. :) |
| 21:32 | <Hixie> | jgraham: fixed |
| 21:32 | <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 |
| 21:32 | <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. |
| 21:33 | <jgraham> | Hixie: Thanks |
| 21:34 | <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. |
| 21:34 | <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 |
| 21:34 | <Hixie> | TabAtkins: certainly they're in a similar space, sure |
| 21:34 | <annevk> | zewt: yeah |
| 21:34 | <annevk> | zewt: yeah |
| 21:35 | <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. |
| 21:35 | <TabAtkins> | zewt: I think I just ignored the email. The responsive images stuff generated a bunch of noise, so I only skimmed things. |
| 21:35 | <annevk> | zewt: doesn't seem like anyone got through in time :( |
| 21:35 | <Hixie> | MarcDrummond: (assuming the only thing you need for print images is an even higher res) |
| 21:35 | <zewt> | (it's also pretty odd for someone apparently new to a list to come on and tell people what they can talk about) |
| 21:35 | <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. |
| 21:36 | <zewt> | i wasn't following those threads; too much traffic vs. not enough personal interest in the subject |
| 21:36 | <annevk> | zewt: yep, guess I'll be doing more careful reading of threads I'm not too interested in going forward |
| 21:36 | <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 |
| 21:36 | <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! |
| 21:36 | <annevk> | at least to make sure nobody is pointing people away from where they should be... |
| 21:36 | <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! |
| 21:36 | <annevk> | at least to make sure nobody is pointing people away from where they should be... |
| 21:37 | <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 |
| 21:37 | <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. |
| 21:37 | <Hixie> | MarcDrummond: are you aware of anyone trying to do that? |
| 21:37 | <ShaneHudson> | Hixie: Could I have an account on the whatwg wiki please? |
| 21:37 | <zewt> | MarcDrummond: that'd be an easy addition: add a greyscale flag |
| 21:37 | <Hixie> | ShaneHudson: e-mail? |
| 21:37 | <ShaneHudson> | Hixie: shane⊙sn |
| 21:38 | <TabAtkins> | zewt: I don't think that's scalable, honestly. Translating a significant set of MQ into the srcset microsyntax is silly. |
| 21:38 | <necolas> | Hixie: that's true. |
| 21:38 | <jgraham> | TabAtkins: Is there any evidence it is a significant set? |
| 21:38 | <Hixie> | ShaneHudson: account details in the mail |
| 21:38 | <TabAtkins> | jgraham: I dunno. |
| 21:39 | <ShaneHudson> | Hixie: Thank you :) |
| 21:39 | <ShaneHudson> | Hixie: Thank you :) |
| 21:39 | <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. |
| 21:39 | <Hixie> | hence it not being one of the use cases i considered |
| 21:39 | <TabAtkins> | 'A |
| 21:39 | <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. |
| 21:39 | <TabAtkins> | Actually, looking over MQ, the only one I might consider useful is the grayscale one. |
| 21:39 | <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? |
| 21:39 | <TabAtkins> | So, shrug. |
| 21:40 | <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" |
| 21:40 | <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. |
| 21:40 | <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? |
| 21:40 | <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 |
| 21:41 | <divya> | necolas++ |
| 21:41 | <annevk> | Hixie: maybe we should rename "Contribute" to "Join" on http://www.whatwg.org/ |
| 21:41 | <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.) |
| 21:41 | <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. |
| 21:41 | <Hixie> | zewt: it could just be "mono" |
| 21:41 | <annevk> | although it does state pretty clearly already everyone can make proposals |
| 21:41 | <necolas> | TabAtkins: again, you seem to think it is *our* job to correct your failings |
| 21:42 | <divya> | exactly |
| 21:42 | <annevk> | but "Join" is nicer and more what we mean than "Contribute" I think; it's a community after all |
| 21:42 | <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... |
| 21:42 | <necolas> | Fortunately, hixie has done a better job of explaining the situation |
| 21:43 | <jgraham> | Pretty sure the only kind of community you have to join is a gated one |
| 21:43 | <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) |
| 21:43 | <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. |
| 21:43 | <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. |
| 21:43 | <annevk> | jgraham: so leave Contribute? :) |
| 21:43 | <TabAtkins> | Shrug. |
| 21:43 | <Hixie> | annevk: done |
| 21:44 | <jgraham> | annevk: I think so :) |
| 21:44 | <necolas> | TabAtkins: to be fair, you were the one who started suggesting that the problem lay with *us* and "egos" etc. |
| 21:44 | <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 c |
| 21:44 | <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! |
| 21:44 | <Hixie> | jgraham: we tried contribute for a while, let's try join for a while and see if it helps :-) |
| 21:45 | <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. |
| 21:45 | <zewt> | when i decided to look at specs, i just subscribed to webapps and whatwg and started reading, heh |
| 21:45 | <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". |
| 21:45 | <Hixie> | ShaneHudson: ah, yeah, if you approached the w3c then i could see why you'd get that impression |
| 21:45 | <zewt> | (couldn't say how I stumbled across the lists in the first place) |
| 21:45 | <Hixie> | ShaneHudson: unfortunately we cannot control the w3c's messaging |
| 21:46 | <Hixie> | necolas: i'm eager to change things to be more welcoming for developers and users and anyone else who isn't currently contributing |
| 21:46 | <necolas> | TabAtkins: well people are entitled to disagree over proposals. any frustration centred around that is distinct from those of people feeling disconnected. |
| 21:46 | <Hixie> | necolas: if you have any ideas i'm all ears |
| 21:46 | <Hixie> | necolas: but i don't think just talking more would have achieved that |
| 21:46 | <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/ |
| 21:46 | <zewt> | if there's anything whatwg doesn't lack, it's talking more :) |
| 21:46 | <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 |
| 21:46 | <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) |
| 21:46 | <divya> | Hixie: completely agreed. |
| 21:46 | <necolas> | TabAtkins: and fwiw, no hard feelings. i know you have the right intentions |
| 21:47 | <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. |
| 21:47 | <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 |
| 21:48 | <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. |
| 21:48 | <TabAtkins> | divya: Heh, every single CSS property in existence is a brand new microsyntax to learn. ^_^ |
| 21:49 | <Hixie> | ShaneHudson: good idea. any idea how one of us can go about writing an article for ALA? |
| 21:49 | <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. |
| 21:49 | <annevk> | isn't sharing the syntax with image-set therefore good? |
| 21:49 | <adactio> | Hixie: write the article. Send it to ALA. I can put you in touch if you want. |
| 21:50 | <divya> | TabAtkins: at the minimum they have adaptability, or some level of consistency with other syntaxes |
| 21:50 | <TabAtkins> | annevk: It's the "NNNw NNNh" part that's new. |
| 21:50 | <TabAtkins> | annevk: And not shared with image-set(). |
| 21:50 | <annevk> | also, given how much markup <picture> requires; avoid needless complexity seems considered... |
| 21:50 | <TabAtkins> | annevk: And duplicated from MQ. ^_^ |
| 21:50 | <Hixie> | divya: well any solution in this space would involve new syntax of some sort. new elements, new attribute, something has to be new. |
| 21:50 | <adactio> | annevk: Yes, it is. It's one of the things in srcset's favour. |
| 21:50 | <divya> | Hixie: yeah i feel if it is a pattern devs can relate with. |
| 21:51 | <divya> | it would be less difficult to make mistakes with. |
| 21:51 | <divya> | it would be less difficult to make mistakes with. |
| 21:51 | <annevk> | TabAtkins: someone proposed using 10x10 instead like rel=icon; but often you don't need one or the other |
| 21:51 | <divya> | annevk: i would prefer verbose/readable to concise machine language. |
| 21:51 | <Hixie> | necolas: that's reasonable. What channels should we be using? We have forums, a blog, a wiki, a Google+ page, and a FAQ. What else should we be doing? |
| 21:51 | <TabAtkins> | annevk: I agree with that criticism. |
| 21:51 | <miketaylr> | Hixie: Wilto is the "technical curator" of ALA. Publishing wouldn't be hard. |
| 21:51 | <Hixie> | adactio: how do we "send it to ALA"? |
| 21:51 | <TabAtkins> | annevk: My preference is something like "w:200px" like Zewt suggested, or full-bore embedding of some MQs like "min-width:200px". |
| 21:52 | <ShaneHudson> | miketaylr: So THAT is how he managed to get an article out today so quickly! |
| 21:52 | <annevk> | TabAtkins: why use units? |
| 21:52 | <annevk> | TabAtkins: nothing in HTML has units |
| 21:52 | <miketaylr> | ShaneHudson: heh |
| 21:52 | <TabAtkins> | annevk: Because people are used to it. And by people, I mean "me". |
| 21:52 | <Hixie> | TabAtkins: w:200px is still new syntax, and if we're going to have new syntax, 200w seems better. |
| 21:52 | <divya> | annevk: this discussion seems to mirror the discussion around open font ligatures |
| 21:53 | <divya> | from what i gather the movement there has been from terse opentype syntax |
| 21:53 | <TabAtkins> | The big problem I have is that sometimes I want to use min-width, and sometimes it's clearer to say max-width. |
| 21:53 | <divya> | to a longer descriptive one |
| 21:53 | <divya> | but then again, i maybe wrong. |
| 21:53 | <adactio> | Hixie: I'll drop you a line in an email and introduce you to some of the ALA people. |
| 21:53 | <annevk> | divya: don't think I was involved in that discussion |
| 21:53 | <ShaneHudson> | Hixie: submit⊙ac is their official submit email address, but there are quite a few people that I am sure could speed it up |
| 21:53 | <annevk> | divya: or know much about it |
| 21:53 | <zewt> | 200w vs w:200 seems pretty much dead-on even to me (intuitively) as far as readability/typability/etc |
| 21:53 | <necolas> | Hixie: The G+ page, for example, hasn't been updated for over 3 weeks. There is no mention of any of the discussions or plans surrounding "responsive images" |
| 21:53 | <necolas> | Hixie: The G+ page, for example, hasn't been updated for over 3 weeks. There is no mention of any of the discussions or plans surrounding "responsive images" |
| 21:54 | <annevk> | necolas: you want to help maintain it? |
| 21:54 | <necolas> | If you have the channels, then it seems like the information isn't being fed into them before (or even after, in this case) the fact. |
| 21:54 | <Hixie> | necolas: if you'd like to help that would be awesome :-) the problem is i don't know what to mention -- there's over 1000 e-mails in the queue for me to deal with, i can't very well mention each one of them on g+ :-) |
| 21:55 | <zewt> | being able to parse all entries as "%c:something" and tell what it is based soley on the %c seems a plus--but a minor one (it's not likely to end up with tons of possible values), so I don't feel strongly about it |
| 21:55 | <Hixie> | necolas: i don't know what is an issue developers want to be told about and what isn't |
| 21:55 | <dreadnaut> | With css using units after the number, 200w would look a bit strange. |
| 21:55 | <divya> | Hixie: if you could like broadly group what you are looking to solve currently. |
| 21:55 | <divya> | and mention it publicly. |
| 21:55 | <divya> | it would be useful. |
| 21:55 | <TabAtkins> | dreadnaut: Spot on. That's my objection, I think. |
| 21:55 | <divya> | we can simply subscribe to threads within that set that is useful. |
| 21:55 | <ShaneHudson> | Hixie: If there is anything I can do to help, let me know.. I have been wanting to get involved for ages as I said earlier |
| 21:55 | <Hixie> | divya: i don't know what i'm going to be working on. I go through e-mail more or less on a first-come-first-served basis, so it's all over the place. |
| 21:56 | <necolas> | annevk Hixie: i'd be tentatively willing to be involved with others in helping out. i've got a full time job + open source commitments also consume most of my time. |
| 21:56 | <Hixie> | divya: http://whatwg.org/issues/ lists all the e-mails |
| 21:56 | <Hixie> | divya: "broadly categorised" |
| 21:56 | <zewt> | if any variable string values are ever added then x: is better, but I can't think of any (even theoretically) |
| 21:56 | <annevk> | ShaneHudson: necolas: we've had this "WHATWG Weekly" running on http://blog.whatwg.org/ but I've been getting worse at maintaining it |
| 21:56 | <divya> | perhaps what we need then Hixie is someone to summarize your current week's responses. :P |
| 21:57 | <divya> | its right now too much effort to follow everything you respond to. |
| 21:57 | <divya> | its right now too much effort to follow everything you respond to. |
| 21:57 | <annevk> | ShaneHudson: necolas: if you think having blog posts of standards activity will help and you can help out with that I can set you up |
| 21:57 | <MarcDrummond> | Hixie: One concern I have with the srcset syntax is that the breakpoints are defined in pixels. However, for a responsive design, it's better to set breakpoints in ems, so that the layout can shift if the text is resized. This could lead to a disconnect between the breakpoints in the layout and for the images. |
| 21:57 | <zewt> | sounds like a good way to confuse things :) |
| 21:57 | <Hixie> | divya: anne was doing that with whatwg weekly but yes, it'd be awesome to have people help him with that |
| 21:57 | <Hixie> | divya: shelley helped for a while |
| 21:57 | <Hixie> | which was cool |
| 21:57 | <necolas> | annevk Hixie, you know, it might be worth also looping some people in who are already trying to do this stuff: bruce lawson, the html5doctor people. |
| 21:57 | <divya> | yeah :) |
| 21:57 | <necolas> | annevk Hixie, you know, it might be worth also looping some people in who are already trying to do this stuff: bruce lawson, the html5doctor people. |
| 21:57 | <divya> | yeah :) |
| 21:58 | <ShaneHudson> | annevk: An 0 comments on most of the articles.. that blog needs promoting! I am surprised actually that with the amount of high profile people I have seen in the irc today that promotion has not been easy! |
| 21:59 | <Hixie> | necolas: bruce is around sometimes |
| 22:00 | <Hixie> | MarcDrummond: (i'm not familiar with the term "breakpoint" as you use it... do you have a link to a page explaining that by any chance?) |
| 22:00 | <annevk> | ShaneHudson: it has about 7000 people subscribed to it via Google Reader |
| 22:00 | <Hixie> | MarcDrummond: in practice 1rem = 16px and the font size changes are all known to the author so i'm not sure it really matters if it's pixels or ems |
| 22:01 | <TabAtkins> | Hixie: A "breakpoint" is a point where you suddenly shift your layout. |
| 22:01 | <Hixie> | ah |
| 22:01 | <TabAtkins> | In other words, where your current layout breaks and you need to rearrange. |
| 22:01 | <Hixie> | ah |
| 22:01 | <divya> | Hixie: i think what we need is what you are currently responding to :P basically a hixie-response-summary-bot |
| 22:01 | <annevk> | necolas: I talk with Bruce now and then; he's not so close to the activities though that he could summarize what is going on |
| 22:01 | <jreading> | OMG |
| 22:01 | <ShaneHudson> | annevk: Really? Ok I reckon I could help out with the blog... though I am new to this group |
| 22:02 | <jreading> | 'nuff…. |
| 22:02 | <necolas> | Hixie and annevk, what is a good avenue to continue the discussion and bring in others who are already partially involved in commenting on whatwg happenings? this feels like something that would be worth attempting. |
| 22:02 | <Hixie> | annevk: (btw, the width and height in srcset are viewport width/height, not image width/height. still about the images, but not necessarily the image dimensions per se.) |
| 22:02 | <necolas> | mailing list? :P |
| 22:02 | <gsnedders> | necolas: Yeah, the mailing list is the place |
| 22:02 | <adactio> | Hixie: you've got mail (some intros to ALA folk). |
| 22:03 | <Hixie> | adactio: thanks |
| 22:03 | <zewt> | Hixie: that's on the unintuitive side |
| 22:03 | <Hixie> | zewt: yeah, unfortunately we're kinda stuck on that. see the e-mail. |
| 22:04 | <zewt> | "viewport-width: ..." would be clearer (but not crazy about the verboseness) |
| 22:04 | <Hixie> | yeah |
| 22:05 | <annevk> | CSS has vw / vh but they mean something else |
| 22:05 | <MarcDrummond> | Hixie: TabAtkins summarized breakpoints well. file.jpg 600w 200h would have breakpoints at 600 pixels wide and at 200 pixels high. The issue is that I would define the layout shift at 37.5em. If the user increases their text size, then the layout shift and the file shift might not sync up. |
| 22:05 | <TabAtkins> | Unfortunately "max-width" is both a MQ and a property. |
| 22:05 | <zcorpan> | annevk: it's not describing the image |
| 22:05 | <annevk> | yeah I was just told |
| 22:06 | <annevk> | silly me |
| 22:06 | <Hixie> | MarcDrummond: if the user increases their font size, they also increase their pixel density, but they don't change the number of pixels |
| 22:06 | <zcorpan> | ah. i failed at reading the logs then :-) |
| 22:06 | <MarcDrummond> | Hixie: This could be really important because I might want images to fill 100% of the width of their container below 37.5 em and only 40% of the container above 37.5em. |
| 22:06 | <Hixie> | MarcDrummond: (don't change the pixel font size, i should say) |
| 22:06 | <Hixie> | MarcDrummond: (assuming they change font size using regular browser zoom) |
| 22:07 | <TabAtkins> | Hixie: Problem still occurs when they have a minimum font-size. |
| 22:07 | <MarcDrummond> | Hixie: Yes, but the issue is if they change the actual text size rather than using browser zoom. |
| 22:07 | <Hixie> | TabAtkins: does that affect teh computed font size? |
| 22:07 | <Hixie> | TabAtkins: i guess in certain cases it does |
| 22:08 | <TabAtkins> | Hixie: Yeah, that's the whole point. |
| 22:08 | <Hixie> | MarcDrummond: i don't expect browsers going forward to really support changing the font size. too many sites break if 1rem != 16px. |
| 22:08 | <TabAtkins> | I've considered enforcing a 16px minimum font size before, but I don't think Chrome lets me do that. |
| 22:08 | <Hixie> | TabAtkins: web breaks if you do that, i have in the past tried |
| 22:08 | <zcorpan> | can the syntax for 200w be more obvious about what it means, maybe? |
| 22:08 | <zcorpan> | can the syntax for 200w be more obvious about what it means, maybe? |
| 22:09 | <MarcDrummond> | Hixie: Lots and lots of browsers do support changing the actual font size right now. I haven't seen evidence that ability will be eliminated. |
| 22:09 | <zewt> | TabAtkins: pretty sure they finally added the option for that (but chrome is being stupid and timing out loading the ... options screen? so I can't check) |
| 22:09 | <MarcDrummond> | Hixie: And if there was, there would be a huge outcry from the accessibility community. The primary purpose of changing font size is for low vision users. |
| 22:10 | <TabAtkins> | zewt: Aww yeah! |
| 22:10 | <TabAtkins> | Everything's big now, woo! |
| 22:10 | <Hixie> | zcorpan: suggestions always welcome, mail the list :-) |
| 22:10 | <zewt> | yeah it's sort of hidden but it's there |
| 22:10 | <MarcDrummond> | Hixie: That's why the best practice is to use ems to determine break points rather than pixels. That allows your layout to still work if the base font size is not equal to 16 px. |
| 22:10 | <TabAtkins> | I was pretty sure that pkasting was fighting against it at some point, but whatever. |
| 22:11 | <zewt> | minimum font size is a pretty critical feature, in a world where people with better-than-20/20 vision design websites with no understanding of people with less-than-20/20 |
| 22:11 | <Hixie> | MarcDrummond: the primary purpose of zooming is for low vision users, too, but without the disadvantages of text size changing. |
| 22:11 | <Hixie> | MarcDrummond: i would expect browsers going forward to more and more drop their font size settings ui |
| 22:11 | <zewt> | (i don't want to zoom in and make *everything* needlessly big; i just want excessively small text fixed) |
| 22:11 | <zcorpan> | zewt: better-than-20/20? |
| 22:12 | <zewt> | yes, 20/20 isn't a maximum |
| 22:12 | <zewt> | don't recall how it works offhand (not that it's really the point :) |
| 22:12 | <MarcDrummond> | Hixie: Zooming works well too. But the reality is that people *can* change font sizes right now. And probably next month. And probably the next month after that. |
| 22:12 | zcorpan | looks it up |
| 22:13 | <MarcDrummond> | Hixie: This isn't an insurmountable problem. I'm just saying that if srcset is used as a syntax, it would be good to be able to define the breakpoints in units beyond pixels. |
| 22:13 | <zcorpan> | so 20/10 means that you have supervision, and 20/100 means that you have crappy vision, and 20/20 is "normal" |
| 22:13 | <zewt> | cool, we have a Mr. Development posting on the list |
| 22:13 | <TabAtkins> | zewt: A/B means that, at A feet, you see things about as well as a "normal" person does a B feet. |
| 22:14 | <ShaneHudson> | Right, added myself to the irc users wiki page :) It is times like this that I realise how boring I am! No books, no active blogs, no awards and not even working for a browser :[ |
| 22:14 | <ShaneHudson> | * :p |
| 22:14 | <zcorpan> | at least when looking at something 20 feet away |
| 22:14 | <zewt> | at least he's not posting as a company name; that's one of the more annoying things on lists |
| 22:14 | <Hixie> | MarcDrummond: in general we're designing for 10 years from now, so what they'll be doing in a few months isn't a huge concern. i am pretty sure that font size setting ui is headed out, and that it's ok to treat 1rem=16px. |
| 22:14 | <zewt> | (that is, as a company name with no real name) |
| 22:14 | <zcorpan> | usually people's screens are closer than that, so 20/20 is not really relevant |
| 22:14 | <TabAtkins> | Hixie: I'm curious why you think minimum font-szies are heading out. |
| 22:15 | <TabAtkins> | Do you think people are going to inevitably get better vision? |
| 22:15 | <zewt> | Hixie: i don't have any opinion on whatever he's arguing, but I'd object ferociously if people removed minimum font sizes |
| 22:15 | <Hixie> | TabAtkins: minimum font sizes may not be but they're not really where you see this kind of image |
| 22:15 | <Hixie> | i'm talking about the definition of rem, not the definition of 0.1rem |
| 22:16 | <MarcDrummond> | Hixie: There's a lot of websites that have been developed between 2002 and 2012. There will be even more between 2012 and 2022. The markup pattern for srcset *will break* how images work within responsive design until font size uis are removed in 2022. That is a problem. |
| 22:17 | <TabAtkins> | Hixie: The point is that if a webdev, say, sets "html { font-size: 10px; } body { font-size: 1.6rem; }" (which I've seen in tutorials), it may break the page. |
| 22:18 | <Hixie> | TabAtkins: that page will be broken long before srcset="" gets involved, though, no? |
| 22:18 | <MarcDrummond> | Hixie: To be clear, it's not that the font size will be different, and that will screw up the image. The problem is that the layout is based on the font size. So if the font size changes, the entire layout can change, the widths of containers can change. |
| 22:18 | <TabAtkins> | Hixie: Maybe, but maybe not. If the author is being very consistent about sizing in rems, though, the page will at least scale up uniformly. It would suck if the image breakpoints weren't allowed to do the same. |
| 22:19 | <Hixie> | MarcDrummond: maybe i'm not understanding what you mean. can you show me a realistic example of where one would use srcset that would be broken if someone set a minimum font size? |
| 22:19 | <TabAtkins> | MarcDrummond: Yeah, that's right. |
| 22:19 | <MarcDrummond> | MarcDrummond: This isn't an isolated use case either. The best practice for responsive design is to change layouts based on ems, not px. And responsive design is swiftly becoming one of the primary techniques for designing new sites. |
| 22:19 | <Hixie> | TabAtkins: well i don't disagree in principle, but there's already a solution: don't set a 10px font size if you want a 16px font size. |
| 22:19 | <TabAtkins> | Hixie: You use a breakpoint at a particular spot, set in ems or rems or something, that changes your layout via MQ. You set up your @srcset to match it, translating into px based on your assumptions about the user's font size. |
| 22:20 | <Hixie> | TabAtkins: no need to massively increase the complexity of srcset="" to handle something that can already be addressed, imho |
| 22:20 | <TabAtkins> | The user's minimum font-size kicks in, suddenly your conversions to pixels are inaccurate, and your images swap at weird points. |
| 22:20 | <TabAtkins> | The user's minimum font-size kicks in, suddenly your conversions to pixels are inaccurate, and your images swap at weird points. |
| 22:22 | <zcorpan> | TabAtkins: why would the conversion be inaccurate? surely the minimum font-size only affects actual text, not computed values of other things like width:10rem ? |
| 22:23 | <MarcDrummond> | Hixie: Here's a simple test page. http://www.vistasmith.com/responsive-ems/responsive-ems.html |
| 22:23 | <TabAtkins> | zcorpan: 10rem is the font-size of the root element. If the minimum font-size causes the font-size of the root to go up, well... |
| 22:23 | <Hixie> | zcorpan: no, minimum font-size affects the computed value for 'em' |
| 22:24 | <Hixie> | zcorpan: see the bottom of http://hixie.ch/specs/css/font-size-ui/font-size-ui |
| 22:24 | <Hixie> | zcorpan: see the bottom of http://hixie.ch/specs/css/font-size-ui/font-size-ui |
| 22:24 | <Hixie> | (it doesn't affect inheritance though) |
| 22:24 | <zcorpan> | hmm. ok. |
| 22:24 | <Hixie> | MarcDrummond: i see no images there |
| 22:25 | <TabAtkins> | Yeah, it's just literally "if an element's font-size is below the minimum, change it to the minimum". |
| 22:25 | <MarcDrummond> | Right. It's just a test page I already have. |
| 22:25 | <MarcDrummond> | Hixie: I'll throw some in there quick. |
| 22:25 | <Hixie> | MarcDrummond: (fundamentally, the problem is that we can't use 'em's because 'em's rely on layout and we need to be able to pick the image before layout happens, btw. so unfortunately even if you convince me that it would be nice to do this, i think we're stuck here.) |
| 22:25 | <Hixie> | MarcDrummond: (but i would still like to understand the problem.) |
| 22:26 | <MarcDrummond> | So the short summary is this. |
| 22:27 | <MarcDrummond> | With that layout, there's two columns above 30ems up to 880px. At 1em=16px, that's 480px to 880px. |
| 22:27 | <zcorpan> | TabAtkins: so if you have something like <h1 style="width:30rem">Hello!</h1>, that will be way too wide if the user increases the minimum font-size |
| 22:28 | <ShaneHudson> | After seeing what it has been like with responsive images... I am really glad I was not involved on the spec side of the original browser wars! |
| 22:28 | <MarcDrummond> | However, if the base font size is 1em = 20px, then there will be two columns between 600px and 1100px. |
| 22:29 | <zcorpan> | but maybe it makes sense for rem-based layouts to get bigger when minimum font-size is increased |
| 22:29 | <necolas> | adactio Hixie: if an ALA article happens, that might be a good time both to highlight whatwg communication channels with the wider dev community, and ask for people to help filter the key mailing list content for summary on the whatwg blog etc. |
| 22:29 | <adactio> | necolas: Agreed. |
| 22:30 | <akamike> | necolas: I've sent a call to action to the other H5Ds, so we might be able to help |
| 22:30 | <Hixie> | zcorpan: it's only a problem if the font-size of the root element is smaller than the minimum, which it shouldn't be unless the minimum is really high, in which case imho the user should just be using zoom (and the UA UI imho should just be taking care of that detail automatically; see the top of the aforementioned page) |
| 22:30 | <TabAtkins> | zcorpan: Yes. |
| 22:30 | <MarcDrummond> | That filters down to the column widths. So if you have an image set to the full width of the second column, that's going to be a different number of pixels when the font size increases. |
| 22:30 | <necolas> | akamike: nice! |
| 22:30 | <ShaneHudson> | akamike: What is a H5D? |
| 22:30 | <Hixie> | MarcDrummond: sure but when is the user going to set a minimum font size of 20px?? the entire web would fall apart. |
| 22:31 | <akamike> | ShaneHudson: http://html5doctor.com/ |
| 22:31 | <ShaneHudson> | akamike: Oh! Of course, sorry and thanks :) |
| 22:31 | <MarcDrummond> | Hixie: The point of defining the layout in ems rather than px is so that the web does not fall apart. |
| 22:31 | <Hixie> | MarcDrummond: i mean the existing web |
| 22:32 | <ShaneHudson> | What is the opinion in here of rem instead of em? |
| 22:32 | <Hixie> | MarcDrummond: not future web pages written by perfect web authors, the web pages that already exist that implicitly assume that when they say font-size: 16px it won't turn into 20px |
| 22:33 | <MarcDrummond> | Hixie: So the problem is that at 16px, the columns shift at480px, but at 20px, they shift at 600px. However, if srcset has the image coded to shift at 480px, then at 20px, the wrong image will be delivered. |
| 22:33 | <MarcDrummond> | Hixie: Unfortunately, that assumption is incorrect. |
| 22:34 | <MarcDrummond> | Hixie: Lots and lots of web developers design their sites assuming that users *can* change their font sizes. |
| 22:34 | <MarcDrummond> | Hixie: Lots and lots of web developers design their sites assuming that users *can* change their font sizes. |
| 22:34 | <MarcDrummond> | Hixie: That's the best practice that's being taught with responsive design right now. |
| 22:34 | <Wilto> | I use em-based media queries, yeah. |
| 22:35 | <MarcDrummond> | Hixie: So if the srcset breakpoints are hard-coded as px, incorrect images will be delivered. |
| 22:35 | <Wilto> | CloudFour has a great write-up on them; it’s really impressive stuff in practice. http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ |
| 22:35 | <zcorpan> | so for em- or rem-based layouts, it seems it would be useful to be able to use em/rem in srcset as well to describe the viewport |
| 22:35 | <Hixie> | MarcDrummond: lots and lots of web developers design their sites assuming that users *can* change their font sizes, but they are utterly swamped by the number of web developers who do not. |
| 22:35 | <MarcDrummond> | zcorpan: Exactly. |
| 22:35 | <MarcDrummond> | zcorpan: Exactly. |
| 22:36 | <TabAtkins> | Hixie: It kind of sucks to tell webdevs that are doing responsible things "sucks to be you, maybe you should do what all the sucky devs are doing instead". |
| 22:36 | <MarcDrummond> | Hixie: That doesn't mean that people who are following best practices should be unable to deliver a solution for their users. |
| 22:36 | <zcorpan> | Hixie: we don't need to cripple a new feature just because most authors don't use rem-based layouts :-P |
| 22:36 | <Hixie> | TabAtkins: agreed, but i don't know what else we can do. |
| 22:36 | <ShaneHudson> | Hixie: But that does not mean the ones that do not are right for not doing it |
| 22:36 | <Wilto> | Completely agreed, on all counts. |
| 22:37 | <TabAtkins> | Hixie: Um, use zewt's idea? |
| 22:37 | <TabAtkins> | w:200px |
| 22:37 | <TabAtkins> | Or w:40em |
| 22:37 | <TabAtkins> | whatever. |
| 22:37 | <Wilto> | I mean, I have an idea, but… y’know. |
| 22:37 | <MarcDrummond> | Hixie: I'm not trying to criticize you here. I'm just saying that this is a very important use case, and that incorporating the usage of ems into the syntax of srcset is essential. |
| 22:37 | <Hixie> | MarcDrummond: my point is that people who are following best practices _can_ deliver a solution for their users anyway, because users aren't going to pick a minimum font size of great than 16px. |
| 22:37 | <Hixie> | MarcDrummond: they'll just zoom instead |
| 22:37 | <Hixie> | MarcDrummond: and zoom works fine if you use pixels |
| 22:37 | <Hixie> | MarcDrummond: since it zooms the CSS pixels |
| 22:38 | <TabAtkins> | Hixie: Bonus advantage of zewt's suggested syntax: it doesn't like a CSS "w" unit. |
| 22:38 | <Hixie> | TabAtkins: as i said earlier, we can't actually use em even if we want to, because we need to be able to do the calculations before layout happens. i'm just trying to work out if there is a problem because if there is then maybe we need another solution altogether. |
| 22:38 | <MarcDrummond> | Hixie: What evidence do you have that users *never* change their default font size? Because accessibility folks would tell you, they do. |
| 22:38 | <TabAtkins> | Hixie: Make the same assumption that MQs do about rem. |
| 22:39 | <TabAtkins> | MQs interpret em as relative to the initial font size. |
| 22:39 | <TabAtkins> | s/rem/em/ |
| 22:39 | <TabAtkins> | (rem is identical, obviously). |
| 22:39 | <Wilto> | Except Opera, I think. |
| 22:39 | <TabAtkins> | Bwuh? |
| 22:39 | <Wilto> | I _think_ it uses the body font size? |
| 22:39 | <TabAtkins> | That's nonsense. |
| 22:39 | <zcorpan> | what? |
| 22:39 | <MarcDrummond> | Hixie: I don't think you have to calculate the layout. You just have to calculate the base font size. Then both the images and the layout are calculated from that font size. |
| 22:39 | <TabAtkins> | (Opera might do it, but it's still nonsense.) |
| 22:40 | <Hixie> | TabAtkins: initial font size is always 16px, so then you're fine with pixels. |
| 22:40 | <Wilto> | Oh, right. I mean, submitted without comment. |
| 22:40 | <TabAtkins> | Hixie: Nope, initial font-size is adjustable by the user. |
| 22:40 | <MarcDrummond> | Hixie: Initial font size is not always 16px. |
| 22:40 | <zcorpan> | i don't follow, what does opera do? |
| 22:40 | <Hixie> | TabAtkins: not in practice. |
| 22:40 | <Hixie> | TabAtkins: we should just fix it to 16px and use zoom. |
| 22:40 | <TabAtkins> | Hixie: Sigh. |
| 22:41 | <Hixie> | see http://hixie.ch/specs/css/font-size-ui/font-size-ui |
| 22:41 | <TabAtkins> | So, nobody does anything like what you suggest there. |
| 22:42 | <TabAtkins> | We have font-size prefs, and zoom is always a full-page zoom. |
| 22:42 | <Hixie> | i should point out that i used to say the same kind of things as you (MarcDrummond, TabAtkins) are saying, but the truth is it just isn't compatible with the web. |
| 22:42 | <Hixie> | too many sites make bad assumptions for it to work. |
| 22:42 | <Hixie> | (i know this from personal experience of intentionally browsing with unusual font defaults) |
| 22:42 | <TabAtkins> | That's what web browsers do *right now*, so browsers apparently don't find it too incompatible. |
| 22:43 | <MarcDrummond> | Hixie: I understand how you found that lots of websites don't work at other font sizes. However, that doesn't invalidate the fact that some people do so. |
| 22:43 | <MarcDrummond> | Hixie: I have seen people in my office who have changed the font size on their browser, because of their eyesight. |
| 22:43 | <MarcDrummond> | Hixie: They are not alone. |
| 22:45 | <Hixie> | i 100% agree we should address their use case |
| 22:45 | <Hixie> | i'm just saying that what we have now does a bad job and we can do much better |
| 22:45 | <Hixie> | and when we do, the issue about using pixels goes away |
| 22:45 | <ShaneHudson> | I often zoom into pages, but haven't changed my default font-size |
| 22:46 | <Hixie> | exactly |
| 22:47 | <zcorpan> | odinho: 200w isn't a hint. read the spec :-P |
| 22:47 | <MarcDrummond> | Hixie: All I ask is that you look into the possibility of using zewt's suggested syntax of putting w: before the number rather than after, and allow for ems to be used instead of px. It really would make a difference for developers. |
| 22:47 | <MarcDrummond> | Hixie: Heading out. Thanks for listening. |
| 22:48 | <Hixie> | ttyl |
| 22:49 | <ShaneHudson> | Quick question, probably stupid.. In Zurb's Foundation Template they use the classes hide-on-phones show-on-desktop etc. Has there been any suggestion (or is it worth it) making it so only one appears in the source? Seems very unsemantic to have duplicates. Or is it recommended to just keep as much in the css as possible? |
| 22:49 | <TabAtkins> | The latter, but when necessary, use @hidden to hide the stuff that is irrelevant. |
| 22:49 | <TabAtkins> | Or just use JS to remove it. |
| 22:50 | <ShaneHudson> | Ok, fair enough |
| 22:51 | <zcorpan> | a team of editors for html5? awesome |
| 22:57 | <Velmont> | TabAtkins: Nice blog post. (odinho here btw) |
| 22:57 | <ShaneHudson> | It is getting late. It has been good to meet you all and to finally see where to contribute. Goodnight all |
| 22:57 | <TabAtkins> | Velmont: Ah, keep a consistent ircnick! |
| 22:59 | <tantek> | TabAtkins indeed, hence we now have: http://wiki.whatwg.org/wiki/Irc-people |
| 22:59 | <tantek> | add yourself and others |
| 23:03 | <zcorpan> | there's http://gavinsharp.com/irc/whatwg.html already |
| 23:06 | <smaug____> | if gavin's scripts just were updating that page regularly |
| 23:06 | <gavin> | they are? |
| 23:07 | <smaug____> | gavin: looks like that page is updated randomly |
| 23:07 | <gavin> | smaug____: there were a few cases where the machine was disconnected recently |
| 23:07 | <smaug____> | the "Statistics generated on" gives usually too optimistic date |
| 23:07 | <gavin> | but it's on a cron job to update every day, with a full rebuild of the cache every three days |
| 23:08 | <zcorpan> | gavin: would be nice if the page showed /whois in the first table |
| 23:20 | <Hixie> | so i'm going to be mostly offline for the next few days, is there anyone who would like to work on that ALA article we discussed earlier? |
| 23:20 | <Hixie> | if not i can work on it when i get back |
| 23:20 | <Velmont> | TabAtkins: Can't, odinho is taken by my work computer :P I should really just not speak when I'm reading from home. |
| 23:20 | <Hixie> | or use odinho_ :-) |
| 23:20 | <Hixie> | that's what most people do :-P |
| 23:22 | <hober> | didn't someone already write an ALA article about how to contribute at the whatwg? |
| 23:22 | <hober> | that sounds really familiar |
| 23:22 | <Velmont> | 00:48 < zcorpan> odinho: 200w isn't a hint. read the spec :-P <---- Ohwell, but you can put 5000w or something else. You can make it up, -- and it will do removal based on your device width. However, -- as far as I understand, browser is actually free to use those numbers as it want. Breaking that would at least not be really evil (as far as I can see, although I haven't really thought about it). |
| 23:23 | <Velmont> | Hixie: Heh, have my legacy nick that people in other channels than #whatwg know me by. :-/ -- But I can just as well pose as two different people. Might be less confusing overall :P |
| 23:23 | <adactio> | hober: it would be good to see an ALA article that responded directly to the concerns raised there today by Wilto: http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/ |
| 23:23 | <adactio> | hober: would you up for writing such an article? |
| 23:25 | <Velmont> | adactio: You're speaking much truth in your answer to my mail. |
| 23:27 | <adactio> | Velmont: Thanks. Just trying to take a step back and look at the problem we're trying to solve ...and realising that actually it's problem*s*, plural. So that's why I suspect that instead of a solution, there probably needs to be solution*s*, plural. |
| 23:27 | <Velmont> | adactio: Yes. We had a talk a bit earlier about that. Hmmm... |
| 23:30 | <Velmont> | Having trouble finding it. So extremely many emails :P |
| 23:33 | <zcorpan> | Velmont: oh, right. for some reason i thought the heuristics step was only for choosing between 2x etc, not for width/height |
| 23:34 | <Velmont> | adactio: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035819.html like this strawman. |
| 23:34 | <zcorpan> | but is that what we want? why do we want to allow heuristics for deciding on the width/height descriptors? |
| 23:35 | <grigs> | adactio: thank you for that email. good summary of what I think is going on as well. |
| 23:36 | <Hixie> | zcorpan: we don't, generally, hence the discouragement in the spec. but there are certain cases where maybe the UA has reason to do otherwise, e.g. it wants to use the image for the biggest possible viewport width because it has reason to believe the user is about to switch to a wide viewport width (e.g. because the tab is only displayed narrowly when in the background) |
| 23:36 | <adactio> | grigs: Thanks. I think a good next step would be to consolidate the use-case examples for art-directed responsive images (e.g. Boston Globe) *separately* from the use-case examples of retina/bandwidth responsive images (e.g. Apple.com). |
| 23:37 | <adactio> | grigs: Also: your blog post does an excellent job of separating out the two use-cases. Thanks for writing it. |
| 23:38 | <grigs> | one thing i've been thinking a lot about in the last few days is that in art directed changes, it may be both a combination of the image and the layout changing. |
| 23:38 | <zcorpan> | Hixie: rendering background tabs at a different width than they would be when active seems like asking for problems |
| 23:39 | <grigs> | which is why even if the Obama example can be handled by srcset (which Hixie’s email argued it could) i don’t think it would work for art direction overall. |
| 23:40 | <grigs> | The Obama example keeps the same ratio for dimensions which won't necessarily be the case. |
| 23:40 | <Hixie> | zcorpan: yeah, it's rarely the right thing, but i don't want to make it completely non-conforming, because there are some rare cases where it makes some sense. |
| 23:40 | <grigs> | The Obama example keeps the same ratio for dimensions which won't necessarily be the case. |
| 23:40 | <Hixie> | zcorpan: yeah, it's rarely the right thing, but i don't want to make it completely non-conforming, because there are some rare cases where it makes some sense. |
| 23:42 | <zcorpan> | Hixie: my knee-jerk reaction is to not allow it |
| 23:42 | <Hixie> | yeah that was mine too, had to go back and add in that step |
| 23:42 | <Hixie> | hence why it was so poorly written originally, as jgraham pointed out :-) |
