| 12:48 | <annevk> | https://twitter.com/WHATWG/status/201293054546685952 |
| 13:37 | <bga_> | Google replaces GET params to json |
| 13:37 | <bga_> | http://e2a66cn9997j2srbkidin2psq2dusjaa-a-fc-opensocial.googleusercontent.com/ps/ifr?viewParams={%22displayLink%22:true, ... ,%22FONT_FACE%22:%22normal%20normal%2012px%20'Trebuchet%20MS',%20Trebuchet,%20Verdana,%20sans-serif%22}} |
| 13:39 | <bga_> | web is losing common protocol |
| 13:40 | <bga_> | external program can not parse it completely |
| 13:40 | <bga_> | :/ |
| 14:51 | <charlvn> | bga_: i have seen similar implementations, that would not be the only one (although probably from the most major institution) |
| 15:03 | <bga_> | charlvn young devs that does not care about common standards disappoint me. RFC is law book of internet |
| 15:34 | <annevk> | bga_: what's wrong with using custom format in GET parameters? |
| 16:08 | <kennyluck> | I think asking people to join the WHATWG mailing list is futile, given that the Responsive Images Community Group actually uses the blog system for discussions... |
| 16:08 | <kennyluck> | And now the CG site is down *shrug* |
| 16:10 | <annevk> | kennyluck: you're welcome to try something else |
| 16:11 | <kennyluck> | annevk, I was going to suggest the CG site but now it's down :( |
| 16:11 | <annevk> | the CG is currently about 90 people whereas the WHATWG is 1500 |
| 16:12 | <annevk> | not sure it's helpful to require all those to subscribe to the CG... |
| 16:16 | <Wilto> | annevk, kennyluck: Nah, I wouldn't expect everyone to. Anyone deeply rooted in the issue should take some time to familiarize themselves with the work of the CG, at least. Otherwise, I'm happy to act as the CG's representative on the mailing list. |
| 16:17 | <Wilto> | It just seems like the most practical approach. |
| 16:17 | <annevk> | Wilto: I do get the feeling the CG has been misinformed about a number things, 1) purpose of CGs 2) mutability of <img> 3) prefetching logic |
| 16:17 | <annevk> | which is kind of sad :( |
| 16:18 | <annevk> | I just noticed there's even an article on A List Apart with the same (mis)information |
| 16:18 | <Wilto> | 2 and 3 may very well be. I hope to work with you guys on clarifying those points, for certain. |
| 16:18 | <Wilto> | annevk: Yeah. I wrote it, based on the information we had at hand. |
| 16:19 | <annevk> | oh and fwiw, typos are just as likely with media queries |
| 16:19 | <Wilto> | I wish more members of the WHATWG had been involved in the CG from the start, for that reason. |
| 16:19 | <Wilto> | Sure. But we’re a lot more apt to spot those. MQ are familiar. |
| 16:19 | <Wilto> | As for item 1, I was under the impression that CGs were intended to allow the community to work together on finding solutions, and contribute to the standards process. |
| 16:19 | <annevk> | I doubt most authors know media queries |
| 16:20 | <Wilto> | —Most authors catering to multiple screen sizes and resolutions will. Of course they will. |
| 16:20 | <annevk> | when they got some traction at one point they looked mostly misused :( |
| 16:20 | <annevk> | people using device-width to detect iPhone/iPad |
| 16:20 | <Wilto> | You can’t make a case that learning two syntaxes is more simple. It's fundamentally flawed. |
| 16:21 | <jgraham> | If I have the right meme, familiar thing is familiar |
| 16:21 | <Wilto> | That doesn’t seem related. |
| 16:21 | <Wilto> | But this isn’t about some developers making poor choices. |
| 16:21 | <annevk> | sure it is, it's about all developers |
| 16:21 | <Wilto> | This is about an unfamiliar syntax, leading to more points of failure, leading to a poor experience for _users_. |
| 16:21 | <jgraham> | Having a syntax that doesn't let you do insane things is good for ergonomics |
| 16:21 | <annevk> | can't just ignore the ones that do the wrong thing |
| 16:22 | <Wilto> | You’re saying this proposed syntax is completely free from potential abuse. |
| 16:22 | <jgraham> | Even if it means not reusing a more general syntax that would let you do the insane thing |
| 16:22 | <Wilto> | Let’s just assume developers can do things wrong in either case. That’s not a stretch. |
| 16:22 | <jgraham> | I'm saying it's tailored to meet the use cases |
| 16:22 | <Wilto> | And in any case, if you were to convince me personally that developers would prefer the proposed syntax, it doesn't matter. |
| 16:23 | <Wilto> | I sincerely hope you saw the comparison thread in the WG, when it was live. |
| 16:23 | <annevk> | Wilto: no |
| 16:23 | <Wilto> | Developers are almost unanimously in favor of <picture>. I lined to it in my last post on the mailing list. |
| 16:23 | <jgraham> | I haven't seen the comparison thread yet |
| 16:23 | <Wilto> | linked* |
| 16:23 | <Wilto> | Once it’s back up, it's a worthwhile read. |
| 16:23 | <jgraham> | But this isn't design-by-democracy aka design-by-committee |
| 16:24 | <Wilto> | jgraham: You're toeing a dangerous line, there. |
| 16:24 | <Wilto> | The developers should absolutely have a say in these matters. |
| 16:24 | <jgraham> | Not really |
| 16:24 | <Wilto> | And they are emphatic on this. |
| 16:24 | <jgraham> | Oh |
| 16:24 | <jgraham> | That was a reply to the first line |
| 16:24 | <jgraham> | Of course people should be free to present arguments |
| 16:24 | <jgraham> | Including ones based on ergonomics |
| 16:25 | <Wilto> | The fact remains that I am speaking for the developers I've worked with on this matter for almost a year now and every "+1" that comes along with that. |
| 16:26 | <jgraham> | Sure. But the important thing to communicate is the arguments they have presented |
| 16:26 | <jgraham> | Not how many people agreed with them |
| 16:26 | <Wilto> | This is the developer's preference, which trumps implementor convenience. And if this syntax stands to introduce more developer error, it isn't best for the user. That's the important thing, above all else. |
| 16:27 | <jgraham> | Sure, developer ergonmoics are an important consideration |
| 16:27 | <Wilto> | But discussing it in here likely isn't a convenient use of anyone's time. Keeping it on the mailing list is probably best. |
| 16:27 | <jgraham> | They are not the only consideration of course |
| 16:27 | <Wilto> | I suppose I haven't seen a clear argument made for the proposed change either, apart from "this is easier to implement." |
| 16:28 | <annevk> | it's a lot simpler to author as well |
| 16:28 | <Wilto> | Authors seem to disagree. |
| 16:28 | <Wilto> | As an author, I personally disagree. |
| 16:29 | <annevk> | it would be interesting to do some usability testing |
| 16:29 | <Wilto> | I'm sorry; there is no case to be made that this is somehow the developer preference. We can work together with that information and find a solution, or the WHATWG can choose to ignore it. |
| 16:29 | <jgraham> | Well I can see that it could be worse if you want to manipulate the srcset with script for example. Although I don't know if there is a use case for that, and it could be trivially made better with a DOM api like srcList |
| 16:30 | <annevk> | Wilto: I don't think you can claim to represent all authors |
| 16:30 | <annevk> | well you can I guess |
| 16:30 | <Wilto> | annevk: Of course not. |
| 16:30 | <jgraham> | Wilto: So far it seems that at least some of your preference might be based on miscommunication (the prefetch thing) |
| 16:30 | <Wilto> | I _assumed_ my role in this would be to share the prevailing sentiment from developers. |
| 16:30 | <Wilto> | That has nothing to do with syntactical preference, jgraham. |
| 16:31 | <jgraham> | Presumably it affects your overall preference though |
| 16:31 | <Wilto> | I suppose I don't entirely understand the "not invented here"-esque resistance I'm encountering here. |
| 16:32 | <Wilto> | I would like to think that developers stand to bring a great deal of valuable information to this discussion. |
| 16:32 | <annevk> | Wilto: it's not at all that, it's just that a design not based on <img> is way more complicated |
| 16:32 | <jgraham> | I think the problem is that you are thinking in terms of NIH |
| 16:32 | <Wilto> | annevk: For whom? |
| 16:32 | <annevk> | for everyone |
| 16:33 | <Wilto> | annevk: What’s more complicated and error prone: an especially long sentence in a language one understands, or an especially short one in a language one doesn't fully understand? |
| 16:33 | <jgraham> | Wilto: I seriously suggest not thinking of this as an us-vs-them situation, and taking the time to present the arguments that you have |
| 16:33 | <jgraham> | and being open to arguments from people who are coming to the problem afresh, or from a different perspective |
| 16:33 | <Wilto> | jgraham: That is exactly what I've wanted. Somehow, it seems that all this has been framed as a defense of the syntax that we've been working on — the burden of proof is on us. |
| 16:34 | <Wilto> | jgraham: I'd like to share what we've learned with those people. |
| 16:34 | <Wilto> | But again, all we're going to do here is dig in our heels further. It's best if we hash these things out on the mailing list. |
| 16:35 | <jgraham> | Wilto: My suggestion is that you post a mail to WHATWG presenting an alternative proposal and giving as many pros/cons relative to hober's proposl as you think are relevant |
| 16:35 | <Wilto> | jgraham: I will, for certain. That's been the plan. |
| 16:36 | <jgraham> | Great. When you do that I think we can have a more productive discussion :) |
| 16:36 | <Wilto> | I certainly hope so. |
| 16:37 | <Wilto> | And if I've come across as "attacking," I promise you all it wasn't my intention. I just want to make sure we're all on equal footing, so that we can work together on getting this solved. |
| 16:38 | <Wilto> | My written tone kinda sucks, too. That's on me, and I apologize if I've seemed confrontational here. |
| 19:06 | <divya> | /msg wilto yoyo |
| 19:06 | <divya> | Oops :) |
| 20:54 | <Wilto> | Protocol question for you guys, if anyone’s here. |
| 20:54 | <webben> | ? |
| 20:55 | <Wilto> | So, I’ve assembled all my details and use-cases and such at https://github.com/Wilto/respimg/#adaptive-image-element |
| 20:56 | <Wilto> | What would be less obnoxious: posting it wholesale to the mailing list, or preparing a quick summary with links to the important sections? |
| 20:56 | <Wilto> | I’m almost certain the latter, but didn’t know if having it all the information centralized on the list might be easier for everyone. |
| 21:04 | <webben> | dunno that either's obnoxious |
| 21:05 | <Wilto> | Well, suppose that’s fair. What’s the best way to present this information, then? |
| 21:05 | <Wilto> | Happy to serve this up in whatever way is most helpful to everyone. |
| 21:05 | <webben> | Wilto: Posting a link to the page seems fine. So does converting it to plain text and putting it in an email with a link. |
| 21:06 | <webben> | The advantage of the later is it makes it easier to quote and respond. |
| 21:06 | <webben> | Wilto: but hey, it's markdown so it's not too much trouble either way. |
| 21:06 | <Wilto> | That’s fair. Didn’t want to post a whole novel to the list if that’s frowned-upon. |
| 21:06 | <Wilto> | Thanks! |
| 21:07 | <webben> | yw |
| 21:32 | <jgraham> | Wilto: Post the whole thing, but I reccomend reordering it so that the use cases are at the top, not the proposal |
| 21:33 | <Wilto> | Yeah, that makes sense. Also, I might post it to the WHATWG wiki—some GitHub readme floating out in the aether probably isn’t the most practical thing in the world. |
| 21:34 | <Wilto> | I’ll also be making it less… spec-ish. I was just winging it based on real specs. |
| 21:52 | <Wilto> | Hixie: Sorry; would you mind setting me up a WHATWG Wiki account? |
| 21:52 | <Wilto> | Hixie: mat⊙mc |
| 22:06 | <Hixie> | done |
| 22:09 | <othermaciej> | Wilto: I believe your proposed sample solution to "3.4. High-Resolution Displays" is not complete |
| 22:09 | <othermaciej> | Wilto: you need to explicitly set a size or image-resolution for the higher-defeinition images, otherwise they will just be treated as larger, not higher resolution |
| 22:11 | <othermaciej> | (if setting image-resolution it would require a stylesheet rule embedded in a media query @-rule) |
| 22:12 | <othermaciej> | Wilto: also, it would be really useful to identify whether there are any important use cases besides resolution adaptation and available screen width adaptation |
| 22:14 | <tantek> | network bandwidth / reliability adaptation? |
| 22:15 | <tantek> | happens often in mobile use-cases |
| 22:16 | <othermaciej> | I'm sure there's lots of potential other use cases, it just happens that Wilto picked ones which are also arguably covered by <img srcset> |
| 22:17 | <tantek> | othermaciej - hence I'm contributing those specific use-cases |
| 22:18 | <othermaciej> | hopefully the use case page gets added to a wiki so it's easy for folks to extend |
| 22:18 | <tantek> | if there are other potential use cases that others care about, they can contribute them. their potential existence does not refute or diminish the significance of the actual existence of the specific use cases I provided. |
| 22:18 | <tantek> | agreed |
| 22:19 | <tantek> | document all the use-cases! |
| 22:22 | <Wilto> | Hixie: Thanks! |
| 22:23 | <Wilto> | And still a work in progress; grain of salt and all. |
| 22:23 | <Wilto> | I noticed `img set` seemed to cover specific widths— 200w, in the example markup. |
| 22:24 | <Wilto> | I’m not sure if the plans include min-width, max-width, etc. I don’t think it’s a matter of one pattern out… adapting the other, so much as it’s a matter of making sure all our bases are covered with either. If we’d be extending `set` to cover all the same things media queries do, maybe media queries are the better option. |
| 22:25 | <Wilto> | `200w` just seemed very specific, at face value. |
| 22:26 | <Wilto> | I’ve added a few more while reformatting the document to be more wiki-appropriate. I’ll have something final posted soon. |
| 22:36 | <othermaciej> | Hixie's proposed width/height semantics for imgset come along with a selection algorithm |
| 22:36 | <othermaciej> | so it doesn't mean just that one width |
| 22:37 | <othermaciej> | it picks the widest that will fit in the available space, if I recall correctly |
| 22:37 | <Wilto> | Based on the container, or the viewport? |
| 22:37 | <Wilto> | Sorry; I’ve just been going on http://junkyard.damowmow.com/507. |
| 22:37 | <Wilto> | I can leaf back through the mailing list. |
| 22:38 | <othermaciej> | "The algorithm here could be to sort the images by width, and remove all |
| 22:38 | <othermaciej> | those that are wider than the available width (except for the widest one |
| 22:38 | <othermaciej> | if they're all too wide) or that don't have a width unless none have |
| 22:38 | <othermaciej> | widths" |
| 22:38 | <othermaciej> | it depends on what "available width" means |
| 22:38 | <othermaciej> | if it means the viewport, then it does the same thing as media query width selection |
| 22:38 | <Wilto> | Right. |
| 22:39 | <othermaciej> | if it means the available layout space, then it's a huge pain to implement and would do something not achievable by media queries |
| 22:39 | <othermaciej> | I don't really know which was intended |
| 22:40 | <othermaciej> | I also don't know which is more useful to authors |
| 22:40 | <Wilto> | Oh, here’s something I’ve been turning over in my head: |
| 22:41 | <Wilto> | Should I put together use cases based on specced behavior? Obviously this is just an example, but the `monochrome` media query could _theoretically_ be used to serve a monochrome image. |
| 22:41 | <othermaciej> | the best way to put together use cases is to base them on things people actually want to do |
| 22:41 | <Wilto> | But in my experience, no browser really pays that media query any mind. |
| 22:42 | <othermaciej> | regardless of whether a given proposal supports them |
| 22:42 | <Wilto> | Yeah, I’ve been sticking to real-world examples. I mean, that certainly stands to reason. Just checking. |
| 22:42 | <othermaciej> | I doubt any substantial number of authors is interested in creating and serving separate monochrome images for monochrome displays |
| 22:42 | <Wilto> | I've worked with way too many wacky mobile browsers to believe in the phrase "in a perfect world." |
| 22:43 | <Wilto> | othermaciej: Of course. As I said, that was obviously just an example. |
| 22:47 | <Hixie> | the algorithm is actually in the spec now, fwiw |
| 22:47 | <Hixie> | the only thing i haven't specced is some mechanism for the browser to automatically flip in a new image on the fly |
| 22:47 | <Hixie> | which is hard because it means doing an async network fetch and then switch it in a stable state, which is non-trivial to spec |
| 22:48 | <Wilto> | I can only imagine. |
| 22:49 | <Wilto> | As media queries are expanded over time, can we assume that this disparate method of detecting client information will be updated in parallel? |
| 23:23 | <Wilto> | othermaciej: In example 3.4, the size of the image would be controlled through CSS. Or am I not following you? |
| 23:28 | <othermaciej> | Wilto: yes, you could control it through CSS, the point is that it won't give the right result without specific additional CSS (whereas for example the imgset proposal could handle scaling and lay out based on intrinsic size) |
| 23:29 | <othermaciej> | Hixie: when you wrote the algorithm spec how did you operationalize "available width"? |
| 23:30 | <othermaciej> | we weren't sure what was intended from the rough draft |
| 23:30 | <Wilto> | Ah, okay. |
| 23:33 | <Hixie> | othermaciej: width of the img element's containing block |
| 23:33 | <Hixie> | othermaciej: or some such |
| 23:34 | <othermaciej> | Hixie: so, that's awkward because it means you can't start loading the image (or preloading for that matter) until after you do layout |
| 23:34 | <othermaciej> | Hixie: a version based on viewport/window width would not have the same issue and could even participate in prefetching |
| 23:35 | <othermaciej> | not starting the load until after first layout would have a significant negative effect on page load performance, based on my experience with these things |
| 23:36 | <Hixie> | othermaciej: a version based on viewport width wouldn't really handle the use cases, but i'll keep that in mind |
| 23:36 | <Hixie> | gotta go |
| 23:37 | <othermaciej> | good point, to the extent that you are describing the image rather than writing a rule list |
| 23:57 | <Wilto> | othermaciej: So the higher density image is rendered within the intrinsic dimensions of the original src if no w/h values are specified, yeah? |
| 23:59 | <othermaciej> | I don't know if the w/h are supposed to affect intrinsic size of the image as Hixie is drafting it |
| 23:59 | <othermaciej> | but the resolution selection does |