Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Personally I think it's better than either picture or srcset alone. But I don't think it's good enough even so, it still has problems: * It's verbose (but less-so than picture). * It has two attributes that could easily be confused as doing the same job. There's little clear logic as to why they're split, from an authors viewpoint. * It bakes design properties into the mark-up. They will be the wrong breakpoints come any re-design. That last one is killer for me. And I've no idea how to address it either :s -Matt On 28 May 2012 17:23, Mathew Marquis m...@matmarquis.com wrote: On May 24, 2012, at 3:58 AM, Florian Rivoal wrote: On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl sc...@scottjehl.com wrote: With this proposal, could src be used on a source element if you don't need the features srcset provides? Or maybe, would that just be equivalent to srcset with a single source listed? I have no strong preference for src vs srcset with a single source and no density qualifier, but yes, one of them should be available. I’m a little uneasy at the silence following Florian’s proposal. I’d love to hear the WHATWG’s thoughts on this compromise. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 28 May 2012 18:21, Scott Jehl sc...@scottjehl.com wrote: Matt Wilcox's first two points are fair, though I see them as inconveniences rather than blockers. To his third point, however: I see the suggestion mentioned on occasion that content image sizes and design breakpoints should be coordinated, but in practice, I personally haven't found much of a need for that coordination. In the responsive layouts I've worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions. Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I've found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the bostonglobe.com for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them. If an image needs finer coordination than that with its design, perhaps it might be considered a design asset that should be handled in CSS with background images; I guess I'd need to see some examples of where this problem could occur. There are sure to be gray areas here. I'm just not sure I agree that the redesign problem is all that much of a real concern for this feature. Matt, if you disagree, do you have any examples you could provide? Sure :) In many ways I agree with you - the entire img problem is really all about *the space they fit into* and not about the design. And if CSS and HTML could work with that then we would be in a far better position because they'd be able to adapt to any space regardless of what the design is. The problem is that CSS media queries do not work with the space an image fits into - they can only measure the viewport. Which means that in practice you're actually coupled to the design breakpoint, even when you're intentionally working with the containing element into which the image is sitting. I.e., the space into which the image can fit is defined in the design breakpoint. It can't be known any other way because we can't measure the containing space itself - we have to define it as part of the design based on the value of the viewport width. Does that make sense?
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 28 May 2012 20:37, Matthew Wilcox m...@matthewwilcox.com wrote: On 28 May 2012 18:21, Scott Jehl sc...@scottjehl.com wrote: Matt Wilcox's first two points are fair, though I see them as inconveniences rather than blockers. To his third point, however: I see the suggestion mentioned on occasion that content image sizes and design breakpoints should be coordinated, but in practice, I personally haven't found much of a need for that coordination. In the responsive layouts I've worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions. Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I've found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the bostonglobe.com for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them. If an image needs finer coordination than that with its design, perhaps it might be considered a design asset that should be handled in CSS with background images; I guess I'd need to see some examples of where this problem could occur. There are sure to be gray areas here. I'm just not sure I agree that the redesign problem is all that much of a real concern for this feature. Matt, if you disagree, do you have any examples you could provide? Sure :) In many ways I agree with you - the entire img problem is really all about *the space they fit into* and not about the design. And if CSS and HTML could work with that then we would be in a far better position because they'd be able to adapt to any space regardless of what the design is. The problem is that CSS media queries do not work with the space an image fits into - they can only measure the viewport. Which means that in practice you're actually coupled to the design breakpoint, even when you're intentionally working with the containing element into which the image is sitting. I.e., the space into which the image can fit is defined in the design breakpoint. It can't be known any other way because we can't measure the containing space itself - we have to define it as part of the design based on the value of the viewport width. Does that make sense? To illustrate the example: I have my first design, and it is intended for 1600px wide viewports. In this design I have a main column that's 1200px wide, and I've set all my img's to adapt to that breakpoint. When those imgs see a viewport in excess of 1600px they go and load the matching resource; which is a 1600px wide image. All is dandy. Two years later there's a re-design, and I've got hundreds of blog posts with embedded img elements that match a 1600px wide viewport. But the re-design isn't the same layout. It now has three columns at that viewport width, not one main column. And now all of the img elements match the viewport... but lead to images which are much too large for the new design. Or, even worse, the new design has completely different breakpoints, and the img's that are being loaded when the viewport hits 1600px are completely at odds with the layout bracket that I'd defined for 1200-1800px ranges. This is what I mean by saying that we're tying our img elements to design breakpoints. Everything is based on Viewports, and we could *really* do with them not being. That's incredibly unlikely to happen though because the technologies just aren't designed that way. Which means we have to hope for a second-best approach of some hefty abstraction.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Excellent, sorry I was not clear on that; this is looking good! I would like to re-iterate that this solution is another which puts design properties into mark-up directly, and just like old picture and srcset, this means that when it's time to re-design a site an author is going to have to trawl through all picture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. -Matt [re-posted to the group, I'd hit reply and not reply-all, sorry!]
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 24 May 2012 09:45, Markus Ernst derer...@gmx.ch wrote: Am 24.05.2012 10:27 schrieb Matthew Wilcox: Excellent, sorry I was not clear on that; this is looking good! I would like to re-iterate that this solution is another which puts design properties into mark-up directly, and just like oldpicture and srcset, this means that when it's time to re-design a site an author is going to have to trawl through allpicture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. This is true only for the art-direction use case, as MQs are removed from the optimization use case. Yep, I can see that's the case :) Unless a new proposal comes up that solves this issue, too, I think this is something we can live with, for two reasons: - The art direction use case is somehow at the edge between content and design. Serving a cropped version of an image is actually dealing with content, even if it is about the design situation. I agree, the problem is that... it's still a problem. It's not always a cropped version, it's sometimes a different image entirely - but we can only sense the viewport rather than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on how much room is there for this image?. However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. In my practice I have seen several redesigns of websites; none of them was restricted to CSS, in all cases, the whole websites were rebuilt, or at least the content was entirely reviewed. This always happens at the agency where I work too, but we also tend to keep an awful lot of the existing content even if we re-shuffle the organisation. There's a lot of existing content that will be re-used in new designs, and as before: while it's easy to change overall template aspects like div structure, it's an entirely different matter to go editing detailed *parts* of content like embedded images. (My experience is very much focused on corporate situations, so this may be different in other fields such as academic.) We do academic, corporate, personal, all sorts. We almost always end up keeping content (but it's nice on the occasions where we dont!)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
I think this is a good step forward, however nless I am mis-understanding something (entirely possible given how much has been going on over this recently) there are problems still... Resolution of an image and a device is not a guarantee of suitability of an image at a given physical size. This solution seems to take the art-directed aspect out of the equation. Just because there's enough resolution on the device does not mean that the image itself is suitable at the size the device is outputting the image. Without some form of other qualifier you end up in a situation where an iPhone 4 with it's retina display will load an image intended for a device twice as big. Now, unless you've got perfect eyesight that image will be displayed at the correct resolution, but *half the size* on an iPhone 4. That's going to be a problem for some users, especially older users. There needs to maintain an art-directed aspect, and it doesn't seem possible for a device to have the required intelligence to know which image is appropriate based solely on the device's pixel density and a collection of images at given dimensions. -Matt On 23 May 2012 18:27, Scott Jehl sc...@scottjehl.com wrote: I agree with Mat. This idea appears to elegantly satisfy the goals we originally set out to address in the responsive images group (and ended up subsequently coming to like the picture/source syntax), while also bringing the advantages of the pixel density notation. From: Florian Rivoal flori...@opera.com Subject: [whatwg] Media queries, viewport dimensions, srcset and picture Date: May 23, 2012 11:21:44 AM EDT To: whatwg@lists.whatwg.org Sorry for not replying to the right message in the thread, I was previously not subscribed to this list, so I can't. As the editor of the CSS Media Queries spec, I've been asked to share my opinion about this debate on responsive images, srcset, media queries, etc. Disclamer: I haven't followed the discussion too closely, and I haven't really done my homework of reading everything that's been said so far, so I'm sure I'll miss the point in a bunch of places, but here's my brain dump, for what it's worth. The responsive image problem is made significantly harder by the fact that in most cases, the decision of whether you want to use a high res or low res image depends both on the resolution of the device and on the network bandwidth. For a low res device, no matter what the bandwidth is, you're going to want a low res image (at least as long as you don't take zooming into account). For a high res device, you want a high res image, unless the bandwidth would make it to slow to load, in which case you might prefer a low res image. If you have a variable bandwidth, the last thing you want to do is to change your mind about which resolution you wanted half way through due to a change of bandwidth, and discard already downloaded data because it's the wrong one after all. This situation gets worse as with high latency. Leaving syntax aside, I think media queries in relation to images can be useful. Providing a different image based on aspect ratio, color depth, viewport size, etc can certainly make sense. But I am skeptical that media queries can solve the responsive image problem well, because I don't see how one could make a bandwidth or latency media query that doesn't cause already downloaded content to be discarded when the conditions change, other than by making it not update to reflect the current conditions, which would make it fairly useless. Given a set of images of different qualities, browsers can have fairly advanced heuristics to pick the right one. For example switching from low res to high res halfway through the rendering of the page if the device is high resolution and the bandwith just went from bad to good and the latency is low enough. Most authors are not going to bother writing media queries of that complexity, and as media queries are stateless, even if they wanted they couldn't be as sophisticated as browsers. This gets even more true if you consider zooming. Having said all that, I think srcset=foo.jpg 1x, foo2.jpg 2x is quite good, because it does indeed provide the browser with a set of images with different quality, leaving it free to pick the appropriate one. On the other hand, I think that including 600w 400h in there is misguided. It doesn't help for the problem of picking the right image for the right resolution/bandwidth combination, but is too crippled to be useful as media queries meant to serve different images to in different scenarios. picture serves these use cases much better. Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the source sub-element of the picture element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: picture source
Re: [whatwg] Features for responsive Web design
On 19 May 2012 00:37, Kornel Lesiński kor...@geekhood.net wrote:
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com
wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
Yes indeed, but the problem is not about srcset, picture or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.
The syntax allows addition of KB descriptor later, which — assuming UAs
will figure out how to measure actual bandwidth well enough — will allow
even more sophisticated selection based on file size (rather than only 1x/2x
scale factors which are only a proxy for the file size).
As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
Or you do what we do now and supply a double resolution image and set
it to a given CSS size. Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
I'd like to see idea's on how this might work.
The current URI template proposal is limited. I've pointed out few cases for
which a single global set of breakpoints is not sufficient. I'd be nice if
you tried to extend the proposal to support those cases as well (e.g. {case}
→ {case:category} and define breakpoints per category such as 'sidebar',
'gravatar', etc.)
All solutions are limited. The more I work on this the more convinced
I am that the nature or HTML and the layout system makes any truly
efficient solution impossible.
I actually prefer the limits of meta than any others simply because
meta does not postpone the issues until a re-design. meta is the
one and only solution I have seen that does not in some way
contaminate the mark-up with values dependent on the current design.
The price for that is less efficient image compression.
I can't see how to extend it as you're suggesting without also falling
to the same presentational properties embeded problem that picture
and srcset fall into. And that to me is a no-go. We already have
srcset if that's the compromise we want to make.
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
picture
source src=200px media=(min-device-pixel-ratio:2)
source src=100px
/picture
This will only choose between large pixelated image and small pixelated
image, and will not make use of high display density.
On it's own you're right. But no-one actually builds a site like that.
If you're doing a fluid responsive site you've got img {
max-width:100% } in there, and in that case you do actually take
advantage of the high DPI.
I've explained it in more detail previously (using srcset as an example, but
it all applies to min
Re: [whatwg] Bandwidth media queries
On 18 May 2012 11:17, Kornel Lesiński kor...@geekhood.net wrote: I think we may be talking past each other, as I don't see how your answers address the problems I'm trying to highlight. Indeed, I'm not debating your points - I accept that it isn't realistically achievable in HTML/CSS :) All the last comment was doing is pointing out that regardless of this, people will try to achieve the same effect using JS (and already are), and will wonder why it's not in HTML/CSS.
Re: [whatwg] Features for responsive Web design
You have to understand that the picture idea was not the result of idle thought. We went through a *lot* of thinking to reach that point, and so it's not actually an attachement to that idea so much as *we know* that idea inside out, what it does, what it doesn't, and why it's like that. We had thought about it from a lot of angles, thrown everything we could at it, and determined that picture was the most robust, familiar, and flexible solution out of half a dozen possibilities - each of which was under similar scrutiny. Then along comes srcset - which has not been subject to the same scrutiny by that group. So *of course* it's getting questioned hard, and *of course* picture is being held as answering the needs best. Until srcset has been properly discussed, inspected, picked apart, and subjected to the same level of scrutiny as picture was, it's not the trusted thing that picture is. Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Personally I'm coming around to a refined version of the srcset idea rather than picture after some clear explanation. But, again, I only see it being appropriate for one-off use cases - singular special-case images within a page. I don't think anyone has yet come up with a good enough general purpose solution that avoids contaminating the mark-up with design-dependent properties which will all be invalid come a re-design - that to me is not acceptable. The closest I've seen that could possibly address that limitation is meta variables, but that has it's own issues and does not answer the same use-cases as srcset or picture. -Matt On 18 May 2012 16:40, Andy Davies dajdav...@gmail.com wrote: On 18 May 2012 15:28, Glenn Maynard gl...@zewt.org wrote: Only if there are actual problems solved by doing so, which there don't seem to be. Instead, people seem to be hunting for excuses to use parts of the other proposal just for the sake of using them, not to solve any actual problem. (That's not a good reason to do it? Hold on, let me try to come up with another...) Perhaps but I think the real problem may be this... The other proposals have been knocked around by various parties who wanted to solve a problem, they had time to discuss it, digest it and see how it grew to meet their needs. Now srcset was dropped on them as a surprise, they're still trying to understand it, they keep being re-assured it meets their needs but no-one who developed the srcset proposal has really come out and explained to them how it meets their needs so they keep asking questions... I wasn't involved in the picture discussion so have no particular attachment to it, I think both picture and srcset have problems in that they move breakpoints into the markup, srcset's microsyntax is pretty horrible and the picture syntax has issues too. The thing that really astounds me about the responsive/adaptive images hullabaloo is: The responsive image problem has been discussed for at least a year with plenty of ideas / workarounds floated around (only got to look a slidedecks form Mobilism, Breaking Development etc. for this) yet WHATWG seemed pretty unaware of it. When WHATWG did decide to do something about it they just dropped it on the people who wanted it by surprise without talking to them first even just to say this is our proposal, this is how we think it solves your problem, what do you think? I can understand why some of the authors are upset and I still thing the srcset needs explaining clearly rather than them having to chew through the spec. Cheers Andy
Re: [whatwg] Features for responsive Web design
Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. picture in its current form is unable to support bandwidth-based negotiation well By all accounts no solution proposed can do this. This is not a picture only problem. (and that's not simply a matter of adding bandwidth media query) and has no mechanism to specify scaling factor for intrinsic sizes of images. Not actually sure what intrinsic sizes of images means. IMHO those are pretty serious drawbacks that limit its functionality, which is much worse than ugly, but gets job done state of srcset. I see no difference between the end result of either syntax. Both approaches fail utterly in abstracting the query from the mark-up, which means both approaches are suited only to individual images. Should the design of the site change at any point, both solutions break completely. It's a major problem I pointed out with picture over in the CG. Srcset is no better in this regard. There are two categories of use-cases (art-directed and dpi/optimization) and picture is suited for only one of them, so please don't frame the decision as discarding of a perfectly good solution, as it wasn't. Picture dealt with both of these by simple use of the pixel density media query - i.e, in exactly the same way CSS already does it. I do not understand your argument. srcset addresses both dpi/optimisation and art-directed use-cases. It has its own problems, such as confusing microsyntax, so suggestions how to improve this are welcome. Agreed, and already underway. Lamenting picture and accusing WHATWG of wrongdoing is not productive. With respect, finding out where there have been fuck-ups is in everyone's interest if we want to get the most out of the process and communities who are all trying to better the web. If you'd like to see picture proposal succeed, then please help fixing its drawbacks. I've said I don't. No part of my argument said I condone continued argument for supporting picture - I in fact said I don't like it and haven't liked it since it was in the CG. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. That last bit is annoying. Some of the key players in that group seem to ignore stuff since they decided picture was finished - I've had the same problem myself. -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 17 May 2012 11:05, Kornel Lesiński kor...@geekhood.net wrote: On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? That following link does it: [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ Sorry, you're right. I glanced over URI template and assumed it was for media=(case: breakpoint1) in source. -- regards, Kornel Lesiński That particular solution is, to my mind, the most flexible and useful implementation I've seen, because it's really about breakpoint management and abstraction - which is what all responsive elements need in order to work together well and be future-friendly. It does, no doubt, have some technical considerations and implications I'm not aware of. I would love to see this worked on more, I don't think there's much more I can add to it from my authors perspective, it needs work from an implementor perspective. But as a pattern, it has a lot of plus points going for it.
Re: [whatwg] Bandwidth media queries
Cheers for that feedback Andy - it is indeed a complicated issue with much more nuance than I think many people (myself included) would have expected. I still think there's a technical solution there, but as you say - it's making that solution reliable enough to be worth it. The problem really is what is reliable enough? How accurate does it need to be. I can understand that this is in practical terms too complex an issue to be worth the effort required to get something workable. And the logic isn't simple either. That said, it's only a matter of making a decision about what to do. The actual mechanics shouldn't be hard, it's the decision making that is.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
That particular solution is, to my mind, the most flexible and useful implementation I've seen, because it's really about breakpoint management and abstraction - which is what all responsive elements need in order to work together well and be future-friendly. It does, no doubt, have some technical considerations and implications I'm not aware of. I would love to see this worked on more, I don't think there's much more I can add to it from my authors perspective, it needs work from an implementor perspective. But as a pattern, it has a lot of plus points going for it. I'm trying to figure out how it's going to work in other situations than the happy case. That's cool, it needs that level of how do I break it thinking. I'd also point out I'm not claiming this is a replacement for srcset or picture. I think it's a useful additional tool for web developers, but it is aimed at *site wide* generalised uses to make life a lot easier - I can't see a way to make it also cater to specific individual instances without fundamentally breaking the benefits of the generalisation. What if you want to provide copypasteable code snippet with an adaptive image? (like W3C Validator badges) That would not be a case this method could support fully. Srcset and picture would offer full support for this use case. That said, I'm not sure of the use case of pasting an adaptive image into another domain; we're usually adapting the image to a design on a given domain; any such image is unlikely to work properly in another context anyway (because that other context has it's own measures at that or other breakpoints). What if you're creating WYSIWYG editor for CMSes and want to have button for inserting adaptive images, but have no access to head? This is not a valid use case (to my mind). You'd not be choosing response points for individual pictures, it is the design that has response points and it's the CSS (and JS/HTML) which fit into the design's breakpoints. All a CMS does is cater to the upload a source image, create and/or associate other images for the breakpoints. What if you want to insert a single image with custom/unique breakpoints (say an infographic prepared by an agency which used different breakpoints) on a website that already has its own breakpoints defined? This is where picture and srcset are useful. However as I say: in general breakpoints are a property of a design, they are not a property of the content directly. You do present a valid case for when a breakpoint may actually be based on the content rather than the design: infographics are more sensitive to this than the general image use case (which I believe are photographs or other graphic illustration). I see no nice solution for case when authors put meta breakpoint in body — it'd either have re-evaluate and potentially reload images (wasted requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly closes head or when people want to work around lack of access to the head) This solution does not allow for meta in the body, and nor does the HTML5 spec unless I'm mistaken? How do you work with URLs you have no control over? e.g. you'd have to name your breakpoints 40 and 80 to have adaptive size of gravatar.com URLs. I'm not sure I understand this point. However you cook it, you have no access to those images so you can't do anything with them regardless of the method of adaption, be it this method, srcset, or picture. What do you do when you have only two breakpoints for sidebar, but more for the main content? (mostly fixed-width sidebar with fluid main column) or if your page header adapts to portrait orientation, but images in main content only adapt to width? Breakpoints are not something that apply to individual components, they apply to the page as a whole? -- regards, Kornel Lesiński
Re: [whatwg] Correcting some misconceptions about Responsive Images
WHATWG does not exist to be a closed society. (Is this a joke? This is probably the most open and approachable spec development community in existance today.) This is probably the best square wheel there is today does not make it a good wheel, even if it's better than all the other square wheels. If there was only one thing taken from the RICG I'd hope that it was the observation that it got a *lot* more feedback from general authors than any of the mailing lists do. It's simply much easier to access and read than the mailing lists - it's not about the people running either group, it's about the medium it is in.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 16:07, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 2:18 AM, James Graham jgra...@opera.com wrote: FWIW I think that forming community groups that are limited in scope to gathering and distilling the relevant use cases could be a functional way of working. For example if, in this case, people had said we will form a group that will spend 4 weeks documenting and prioritising all the use cases that a responsive images feature needs to cover and then the results of that work had been taken to a forum where browser implementors are engaged (e.g. WHATWG), I think we would have had a relatively smooth ride toward a universially acceptable solution. While this is true in some form, in order to be useful we had to consider different approaches and get the feedback about those approaches. It wasn't just get use cases so much as get use cases, decide whether a pattern we are suggesting answers them, and then canvas authors to see if they actually understand it and react well to it?. If the WHATWG are not willing to join CG's in order to give their input then the route would effectively end up being: 1) Spin off a CG to gather use cases 2) grab info and apply back to WHATWG mail list 3) WHATWG mail list decides on possible approaches 4) Spin the approaches off to CG and gather wider feedback 5) goto 2 I don't mind that approach, but the problem is once you involve a wider community you *will* get that community discussing technical stuff there - divorced from the WHATWG members. The fact of the matter is that the wider public find a website in the format of the CG far easier to access and engage than mail lists. That's neither a good or bad thing, it just is. How it should be managed is where it gets difficult. Yup. This is basically what the CG *did*, in practice, and it was very useful. There was an unfortunate expectation that their goal was to write spec text that would be simply adopted into the spec, though. Making sure the expectations are clearer in the future would be a good move. That would have been a hugely beneficial thing. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 17:00, Rafael Weinstein rafa...@chromium.org wrote: As a UA implementor, this seem to me to be purely a success story for the single reason that it drew so much developer participation. Regardless of what makes it into the spec, the worst possible outcome would be if the developer community learned the lesson that UA implementors are hostile to/dismissive of their problems, ideas and solutions. It seems to me like there's a problem of walking a mile in someone else's shoes in both directions, but ultimately developers are our customers -- not vice versa. If it's required for either camp to go the extra mile to accomodate the other -- it seems to me that it ought to be us. It's been a series of unfortunate things to be honest. 1) First off many members of the CG have been working on the adaptive images problem for close to a year at this point. 2) When a few went to the mailing lists some months ago, we were met with the realisation that Hixie was not even aware there was a problem (at this point it had already had months of outspoken and loud attention in the wider community, including a few publications in major web sites and magazines). That the 'lead' of the WG was ignorant of the issue left a few of us incredulous. 3) Then because the mail lists are not friendly to newcomers members of the group were mis-directed to form a spin off group. 4) Then the more recent communication fiasco with regard to srcset and picture The problem of miscommunication and poorly documented newcomer-unfriendly channels is not new. The rub on this one is *just how much work* has been put into the subject - as I say, close to a year - and then the realisation of so much seemingly being a waste. Or at least not seen to be valued, used, or openly discussed by the WHATWG, before some other (apparently random, to us) idea got pushed forward. As I say, the CG have discussed all of this openly, published in prominant magazines, done our due diligence research into any number of existing solutions etc. To see srcset appear from the shrouded mists of the WG mailing list was a shock.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 18:49, Rafael Weinstein rafa...@chromium.org wrote: It's easy to see how the experience you describe below would be frustrating. FWIW, I routinely feel frustration at seemingly wasted time. Unfortunately, it's inescapable that reaching consensus can be exhausting, especially via email -- and doing so always requires re-explaining the same thing multiple times in multiple ways. This is true for everyone. Agreed, there will always be an element of this - although in the case of the CG this got to the point that we addressed it with a FAQ page. That helped us and people visiting. It didn't seem to help the WG, for whatever reason? In fairness to Hixie -- being an editor is fairly thankless and he does a remarkable job of keeping up even just with whatwg, webapps and a few others (I gave up long ago). If you need someone to understand something, it's best to directly bring it to their attention. The internet is a big place =-). I can see both sides of this. When you're busy, you're busy, and Hixie is busy. On the other hand, this was a long drawn out multi-month problem that was talked about quite literally everywhere. It's the fact that the scope of awareness everywhere else was so large that makes it so surprising it was missed in the one group that it ought to have been forefront of that subject. I agree with both Jonas and Maciej's points above about lessons for the future. It seems like the basic problem is that a feature which needs lots of work collecting use cases and developer feedback requires a setting which isn't intimidating for developers -- but ultimately, if it wants to land in a spec, it needs the perspective and experience of implementors and editors. I think we all agree on that :) A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. -Cross-post significant outputs decisions to whatwg, public-webapps, etc... E.g. collected use cases, strawman proposals, recommendations, etc... Even with the help of an implementors/editor, the ideas that survive are those that withstand the scrutiny of the entire community and getting that scrutiny early is nearly always better. Cross posting is always risky. If the items under discussion are still maliable then what happens is two discussions break out between two lots of un-related groups and things get messy. I'd be up for this route only if it was very clear of the role of each party, and lines could be drawn that properly segment the discussions. i.e., 1) CG: We have collected enough use cases from a wide spread of authors; we are now presenting this back to the WHATWG - if you wish to follow along with possible solutions, please take part there 2) WG: discusses possible solutions and *whenever* there is doubt about what an author would prefer to do or what they will understand, it gets bounced back to the CG 3) CG: present the WG's dilema in a succinct way that presumes no prior knowledge, and solicit feedback from authors outside of the WG list, which is then fed back to the WG. 4) WG: makes decisions based on that feedback. That to me would work best for both communities.
Re: [whatwg] Problems with width/height descriptors in srcset
I also agree with Tab and Jeremy on this one - that makes a lot more sense to me and removes any ambiguity without being overly verbose. I asked: Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). And Tab replied: No, if we're aping the CSS syntax more closely, we should just use CSS units. I agree. Seems like the sensible approach. It also allows authors who are using ems for their media queries in CSS to also use ems for their srcset declarations. Jeremy
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 19:15, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. FWIW, I wanted to do this, but Google's policy of having us talk to the patents guys before joining CGs turned me off from actually joining. So, I just followed from the side and couldn't interact enough. :/ Is this something that Google might be willing to bend somewhat? I.e., when you're on the CG you're a free-agent and not representing Google? Or, for the sake of politics, could it be worked around in that instead of joining the CG you keep track of things via the RSS feed (it is after all public) and post to the WHATWG mailing list with observations every once in a while - as long as core CG members know to keep an eye out that's not necessarily a huge problem. I dunno, politics complicates stuff. And patenting open-web stuff to me seems wrong on any number of levels.
Re: [whatwg] picture / img srcset not needed
As far as I'm aware SVG does not tackle the primary type of image an
img element diaplsys - photographic, non-vector images. SVG is not
applicable for enough uses.
-Matt
On 16 May 2012 07:17, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, May 15, 2012 at 6:23 PM, Aldrik Dunbar ald...@gmail.com wrote:
Hi there,
Adding a new *presentational* attribute/element for adaptive/responsive
images makes no sense and is not required. We already have a flexible
image format that can accomplish this — SVG, e.g.:
?xml version=1.0 encoding=UTF-8?
svg xmlns=http://www.w3.org/2000/svg; viewBox=0 0 900 1135
descA painting by Edvard Munch, commonly known as the
scream./desc
style type=text/css ![CDATA[
svg { background-size: 100% 100%; }
@media (min-width:477px) {
svg { background-image:
url(https://upload.wikimedia.org/wikipedia/en/f/f4/The_Scream.jpg;); }
}
@media (max-width:476px) {
svg { background-image:
url(https://upload.wikimedia.org/wikipedia/en/thumb/f/f4/The_Scream.jpg/476px-The_Scream.jpg;);
}
}
]]/style
/svg
This is *way* more verbose than either picture or img srcset,
doesn't interact with preloading, and doesn't do any kind of
negotiation resolution. There are good reasons for the designs that
have been discussed so far.
~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Am i right in believing that the srcset attribute are limited to pixels? A unit that's dying out in all responsive designs? Is it extensible to em, % etc? Because that's what's used. On 16 May 2012 08:39, Chris Heilmann code...@gmail.com wrote: On 16/05/2012 00:23, Kornel Lesiński wrote: On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote: The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code. There is significant difference in verbosity for a *very common case* of serving images for high-dpi (Retina) display (which I suspect is only going to get more common): img src=lowdpi srcset=hidpi 2x vs picture source media=(min-device-pixel-ratio: 2) src=hidpi img src=lowdpi /picture It will get tiring when it'll have to be used for every image on the page. Authors couldn't be bothered to type extra markup for all vendor's prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters. Now there is a massive list of assumptions. People were happy for YEARS to do a: object width=420 height=315param name=movie value=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;/paramparam name=allowFullScreen value=true/paramparam name=allowscriptaccess value=always/paramembed src=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0; type=application/x-shockwave-flash width=420 height=315 allowscriptaccess=always allowfullscreen=true/embed/object For a video. You know why? Because it worked! SVG didn't work inside HTML for a long time that's why these gradients didn't work - not because it was too long. HTML5 Doctype may be loved but people even forget using that one (case in point - codecademy HTML classes totally forget about it - WHEN teaching new people how to write code for the web). Tooling works around these issues, not making a language shorter. You learn that when you teach people to start using the web. Let's not get too excited about what the people writing specs use and like but see what makes a platform that is understandable and works.
Re: [whatwg] picture / img srcset not needed
So wrap an image in SVG? I don't see this as being very clean. On 16 May 2012 10:49, Aldrik Dunbar ald...@gmail.com wrote: As far as I'm aware SVG does not tackle the primary type of image an img element diaplsys - photographic, non-vector images. SVG has a number of ways to include raster graphics images, the previously included example does just this.
Re: [whatwg] Features for responsive Web design
Chalk me up as another making that mistake. Properties on elements usually describe a property of the element. Not a property of something else (like the viewport). I'm happier than I was about srcset - but why does the spec assume pixels? Or does it? Use case: design breakpoints can and often are based on non-pixel units. em's, for example. As far as I can tell, srcset does not work with units other than pixels, so how could it work reliably with designs done in non-pixel units? -Matt On 16 May 2012 13:38, PJ McCormick p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I also made the same mistake, and it took combing through all of yesterday's and this morning's discussions on the topic for me to finally understand it properly. And I consider myself to be a fairly competent developer, not someone just starting out with HTML. Now that I do understand I'm honestly happier with @srcset as a concept, but my problems with the syntax itself still remain. In fact, they might be amplified. Surely we can refine this into a better, more easily understood syntax. On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src= are appropriate for the pixel density case. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset= is bad for the art-direction case and picture is bad for the pixel density case. (I think the concept of dpi isn't appropriate for either case, FWIW. I think the number of horizontal and vertical bitmap samples doubled relative to the traditional src image works much better conceptually for Web authoring than making people do dpi math with an abstract baseline of 96 dpi. Anecdotal observation of trying to get family members to do dpi math for print publications suggests that it's hard to get educated people do dpi math right even when an inch is a real inch an not an abstraction.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Features for responsive Web design
Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). -Matt On 16 May 2012 13:55, Matthew Wilcox m...@matthewwilcox.com wrote: Chalk me up as another making that mistake. Properties on elements usually describe a property of the element. Not a property of something else (like the viewport). I'm happier than I was about srcset - but why does the spec assume pixels? Or does it? Use case: design breakpoints can and often are based on non-pixel units. em's, for example. As far as I can tell, srcset does not work with units other than pixels, so how could it work reliably with designs done in non-pixel units? -Matt On 16 May 2012 13:38, PJ McCormick p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I also made the same mistake, and it took combing through all of yesterday's and this morning's discussions on the topic for me to finally understand it properly. And I consider myself to be a fairly competent developer, not someone just starting out with HTML. Now that I do understand I'm honestly happier with @srcset as a concept, but my problems with the syntax itself still remain. In fact, they might be amplified. Surely we can refine this into a better, more easily understood syntax. On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src= are appropriate for the pixel density case. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset= is bad for the art-direction case and picture is bad for the pixel density case. (I think the concept of dpi isn't appropriate for either case, FWIW. I think the number of horizontal and vertical bitmap samples doubled relative to the traditional src image works much better conceptually for Web authoring than making people do dpi math with an abstract baseline of 96 dpi. Anecdotal observation of trying to get family members to do dpi math for print publications suggests that it's hard to get educated people do dpi math right even when an inch is a real inch an not an abstraction.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Features for responsive Web design
Note that this is also my major criticism of picture and the reason why I would not use it in the current CG state - and why I've been looking into meta variables as a method of abstracting the response points away from the responding element. I think this is a very important consideration. Anything baking response points directly into an element will be hell to work with in any re-design. -Matt On 16 May 2012 13:58, Matthew Wilcox m...@matthewwilcox.com wrote: Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). -Matt On 16 May 2012 13:55, Matthew Wilcox m...@matthewwilcox.com wrote: Chalk me up as another making that mistake. Properties on elements usually describe a property of the element. Not a property of something else (like the viewport). I'm happier than I was about srcset - but why does the spec assume pixels? Or does it? Use case: design breakpoints can and often are based on non-pixel units. em's, for example. As far as I can tell, srcset does not work with units other than pixels, so how could it work reliably with designs done in non-pixel units? -Matt On 16 May 2012 13:38, PJ McCormick p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I also made the same mistake, and it took combing through all of yesterday's and this morning's discussions on the topic for me to finally understand it properly. And I consider myself to be a fairly competent developer, not someone just starting out with HTML. Now that I do understand I'm honestly happier with @srcset as a concept, but my problems with the syntax itself still remain. In fact, they might be amplified. Surely we can refine this into a better, more easily understood syntax. On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com wrote: You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src= are appropriate for the pixel density case. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset= is bad for the art-direction case and picture is bad for the pixel density case. (I think the concept of dpi isn't appropriate for either case, FWIW. I think the number of horizontal and vertical bitmap samples doubled relative to the traditional src image works much better conceptually for Web authoring than making people do dpi math with an abstract baseline of 96 dpi. Anecdotal observation of trying to get family members to do dpi math for print publications suggests that it's hard to get educated people do dpi math right even when an inch is a real inch an not an abstraction.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 16 May 2012 14:30, Odin Hørthe Omdal odi...@opera.com wrote: Oh, please do quote what you are answering. It's very hard to follow such a conversation like this. OK, I am not sure what format to reply to emails with - some people complain when quotes are left out entirely, other people complain when replies are in-line in the style you request, other people complain unless the whole thread is included verbatim in any reply. What's the actual WHATWG proscribed format for conducting conversations in email format? Matthew Wilcox m...@matthewwilcox.com wrote: If there was a way to do this in JS, we'd have found it. Every time we run up against the pre-fetch problem. In fact, it is only the pre-fetch problem that causes responsive images to be an issue at all. It'd be trivial to fix with JS otherwise. I could be more clear. I believe this is what you are talking about: I said: media queries is doing model 2. I suggest we find a way to do that with javascript. Maybe some form of deferring image loading at all, saying that I will fetch image on my own. Then you can do the delayed image loading that would need to happen in a media query world. When I say find a way to defer it, I mean spec a way to do it, and implement that. Something like: img defer src=blabla.jpg I understand the problem :-) Cool - so you're saying we have the option of being able to instruct browsers *not* to perform prefetch in certain circumstances? Also, i don't think non-pixel based layouts can be easily dismissed. It's where the whole movement is going and already pixel based MQ are described as limited and not a best practice. ... But it doesn't work. Please read my emails, and come with constructive technical feedback on why you think it *can* in fact work. I can not see a method where that would work in an non-broken way. Technical problems won't just magically go away by not acknowlegding them. I am unable to give technical feedback of the required level; I'm here as an author to tell you this is how we build stuff and this is how we'd want to use images - just like we do with CSS. Just as technical problems won't go away, neither will authors use cases and requirements :) And, unfortunately, I am not skilled enough with the technical side to be able to give you answers to the problem. I'm just stating that the problem is not one that can be ignored lightly because it would mean that the proposed solution does not work with how websites are being built today. And I did find a way forward for the model 2, make a way to defer the image load and find a way to load it. Maybe picture element should always defer? It actually *has to* because it uses media queries, so in fact, picture might be a solution for model 2 in the future. But @srcset is solving the other part of the equation (model 1). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com I'm not entirely convinced about this abstraction of model 1 and model 2. picture is flawed anyway, and srcset in the same manner, by baking the response tests into the mark-up. When it comes time to re-design there will be new breakpoints and they are not likely to match the one's in the img / picture tags. It's the major hold-up I had with picture and why I suggested looking into abstracting breakpoint conditions away from the responding element and into the head.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Cheers :) On 16 May 2012 15:05, Mike Taylor mi...@opera.com wrote: On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox m...@matthewwilcox.com wrote: What's the actual WHATWG proscribed format for conducting conversations in email format? See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F -- Mike Taylor Opera Software
Re: [whatwg] Problems with width/height descriptors in srcset
I kinda like the syntax in the spec draft, it's short and sweet. And obvious when you know. Everything is obvious when you know. The challenge is making it obvious when you don't. Which is why using familiar patters is good. Which is why picture had a strong advantage in that regard. People will learn it from good documentation probable (heh) or hopefully quickly understand once they have browsers to test in. I would count on the majority getting this wrong time and again because the pattern is not a familiar one. And, as we all know, people don't read docs - isn't that the argument so often brought up against any advanced stuff in CSS and HTML? - Users Are Stupid? ;)
[whatwg] Bandwidth media queries
First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / This make an obvious kind of sense to an author. One of the issues I see people raise when they attempt to explain why this won't work is that bandwidth is variable, and hard to measure (and something about CSS being stateless I think). Here's why this confuses me... If you're a browser you are the software interpreting the instructions of a given language: CSS in this case. You're an interpreter. So, if CSS essentially asks you as a browser what's the available bandwidth - why can the browser not just supply a value back to the CSS? The next thing that comes to mind is: How do we get the value? Again, I hope I'm not being too ignorant but the process *feels* like it should go like this: All browsers have a Web Inspector and all Inspectors have a Network tab. That network tab tracks and logs everything we'd need to know to figure out a reasonable approximation of the bandwidth available to *that open tab*. This isn't an argument so much as a statement of fact: all browsers can currently do this - it's just not exposed to CSS to interrogate. Why can we not be smart about this and follow a procedure like this: As soon as a request is made for a web page, start tracking the network activity. The browser knows when it sent a request, how long it took to receive a response (thus the latency), the size of the response and how long it took to deliver. It can start doing this with the favicon. It can then analyse that favicon's data and come up with a ballpark bandwidth. Subsequently it can do the same thing for every single http request made to that domain. And it could average out the results to get a more accurate bandwidth and latency measure of what is currently available for the browser to use, re-adjusting the value sent to the CSS as it goes. No doubt that would have some wobbliness due to the low sample rate on an initial connection, so what is to the stop the browser being smarter and keeping a log of connection speeds as a good starting point for future requests - for example, what was the average speed to this domain for all responses in the previous 10sec of requests? Or even more generally; what was the average speed available for *any* domain in the last five minutes? Thanks for your time, Matt
Re: [whatwg] Features for responsive Web design
On 16 May 2012 19:47, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox m...@matthewwilcox.com wrote: Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). You're right that changing your breakpoints requires changing all the @srcset declarations. An unfortunate aspect of our inability to abstract away some of the functionality without breaking some of the features (like being preloader-friendly). I must admit, I am still confused about the pre-loader issue. I'm not sure whether the plan is that we'd be able to convince vendors to disable it on img/ elements containing srcset (or whatever solution ends up final) or whether this is something that has to be worked with now (in which case the meta variable idea seems to me the only one that could work). However, something similar to your idea certainly seems possible to use in an extention of the syntax. Rather than specifying a w/h component, give a 'case' component that refers to a breakpoint defined elsewhere. This could even potentially extend into url-templating. That's the conclusion that was come to at the RICG too, and why http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ was put forward. I haven't received promising feedback from the WHATWG about it though :s This seems like a good bit of complexity for now, though. I'd prefer to iterate on the current proposal, keeping this kind of thing in mind. In particular, adding something like url-templating would *massively* blow up the complexity of the feature, and delay its implementation. I'm happy with that too, any progress is good progress and it doesn't all have to come at once. That said I won't use any solution until it has this level of abstraction: that's a criticism I brought up with picture too (and why I wouldn't use that either in it's current RICG form). ~TJ
Re: [whatwg] Bandwidth media queries
Ok, so really it's an efficiency of authoring problem; before I just didn't get how it'd be any different to a viewport width from the perspective of an author. That said, when coupled with viewport responses... yeah, that could get complicated to author. Essentially each bandwidth bracket would be a multiplier for the number of cases you'd need to address. Cheers again. On 16 May 2012 20:00, Tab Atkins Jr. jackalm...@gmail.com wrote: It's not that bandwidth queries aren't possible, it's that they're not *useful* for the things you'd want to use them for, and they don't act like you'd want anyway. I explain much of the reasoning in http://www.xanthir.com/blog/b4Hv0 - while the blog post purports to be about resolution negotiation, it actually more generally covers why bandwidth queries are a bad idea. In short, bandwidth is often quite variable, particularly on the devices where you'd actually *want* to use this information. This means the instantaneous bandwidth (what MQ would be using) can easily be useless to you. It also means that you'll easily and commonly get into perverse situations where trying to be bandwidth-friendly ends up downloading *more* data than a naive page would. The author is just not in a good situation to be able to make sound decisions about how to react to bandwidth. You need a lot more information than a MQ can provide, and even if we provided it, the logic necessary to use that information *right* is fairly subtle and definitely not settled. This is why providing facilities for the author to just *tell* the browser about the relative filesizes of things, so it can make its own decisions about which resource to download. This keeps the language simpler, because we don't have to communicate as much information. It also centralizes the what to do logic into a small number of places (the browsers) where it has a better chance of being right, rather than hoping that thousands or milions of authors all stumble on the best solution together, and keep their pages updated as best-practices change. ~TJ
Re: [whatwg] Features for responsive Web design
On 16 May 2012 20:04, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 16 May 2012 19:47, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox m...@matthewwilcox.com wrote: Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). You're right that changing your breakpoints requires changing all the @srcset declarations. An unfortunate aspect of our inability to abstract away some of the functionality without breaking some of the features (like being preloader-friendly). I must admit, I am still confused about the pre-loader issue. I'm not sure whether the plan is that we'd be able to convince vendors to disable it on img/ elements containing srcset (or whatever solution ends up final) or whether this is something that has to be worked with now (in which case the meta variable idea seems to me the only one that could work). Given the current syntax, the idea is that browsers will be able to preload the *correct* image from @srcset. They have all the information necessary to make the decision at parse-time. I'm not entirely sure how accurate this is, though. Some better info one way or another would be useful. Cool. That makes sense but would require the browser to update it's pre-parser behaviour I imagine (i.e., scan the whole element rather than just try as soon as the src has been read - so it's not backward compatible right now) :) However, something similar to your idea certainly seems possible to use in an extention of the syntax. Rather than specifying a w/h component, give a 'case' component that refers to a breakpoint defined elsewhere. This could even potentially extend into url-templating. That's the conclusion that was come to at the RICG too, and why http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ was put forward. I haven't received promising feedback from the WHATWG about it though :s Yeah, I was purposely calling back to the post you linked above. I gave it some criticism here in WHATWG. Ah, I thought you were. I'll go have another look because I think I missed it - I'm only aware of one person feeding back - but then it's the end of the day and I'm not wholey convinced I won't see your reply and then remember reading it. It's been a busy day. Cheers Tab. ~TJ
Re: [whatwg] Bandwidth media queries
On 16 May 2012 20:10, James Graham jgra...@opera.com wrote: On Wed, 16 May 2012, Matthew Wilcox wrote: First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / Without going deeper into the specific points, implementation experience suggests that even implementing a binary low-bandwidth/high bandwidth detection is extremely difficult; Opera has one coupled to the UI for the turbo feature and it has been somewhat non-trivial to get acceptable quality. In general the problem with trying to measure something like bandwidth is that it is highly time-variable; it depends on a huge number of environmental factors like the other users/applications on the same connection, possible browser features like down-prioritising connections in background tabs, external environmental features like the train just went into a tunnel or I just went out of range of WiFi and switched to 3G and any number of other things. Some of those are temporary conditions, some are rapid changes to a new long-term state. Trying to present a single number representing this complexity in realtime just isn't going to work. Yeah, that's what I had figured the process I described would be able to work for - but I accept it must be more complicated than I have accounted for. Thanks for the feedback :)
Re: [whatwg] Features for responsive Web design
On 16 May 2012 20:12, Jacob Mather jmat...@itsmajax.com wrote: Maybe this is the better question: Why does the pre-loader matter so much? Basing the selected image off of browser width is inherently backwards. The content should be informed by the layout, not by the browser. I do agree with you (it's all about layout rather than screen width - it's the layout that dictates the content images and it's the screen width that dictates the layout - there's a clear stack of dependancies and at the moment that isn't reflected in the technology we use). However I think the problem right now is that at the time the browser see's the img / it is likely to not know the layout. The CSS hasn't loaded yet and the layout hasn't been applied - so the image can't know how big it needs to be. This is why I put forward the idea of setting breakpoints in the head as a meta tag. That is the one and only place that other technologies can be sure will have already been loaded.
Re: [whatwg] Features for responsive Web design
@Tab - yes I do remember, sorry. I'm being a bloody idiot.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
The solution I've seen proposed[1] only aliases media query content, and works only on a per-page basis, so it doesn't allow automatic addition of a new image size site-wide, since you have to insert new source into every picture anyway. That is not true. With that particular solution you would never alter any mark-up inside the body, you would only ever need to alter the meta variables in the head - which more often than not are in a single server-side template for a website. That solution makes it trivial to adjust, add, or subtract the breakpoints of a design, and therefor images, site-wide under normal website conditions (i.e., you're using a CMS to output the website). To me it looks like about the same amount of work as inserting new pixel size into every srcset. Completely not the case. What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? That following link does it: [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ -- regards, Kornel Lesiński
Re: [whatwg] An alternative to picture and srcset, is this realistic?
We're getting some good feedback over on the Community Group about this, people seem to like it. I'm still asking a few people to try and find holes in the proposal though, reasons why it wouldn't work. -Matt On 14 May 2012 17:59, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 9:31 AM, Matthew Wilcox m...@matthewwilcox.com wrote: All good points, thanks. Sorry I'd missed you saying style rather than link/, my bad! I had assumed that we would be able to take the logic for resolving media query applicability directly from that in CSS, which is why I have not given it any further thought. It seemed like a solved issue. Heh, it *is* solved by CSS, it's just that the solution is somewhere between none and all of them apply, which works for CSS but not for yours. ^_^ On Mon, May 14, 2012 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/14/12 11:55 AM, Tab Atkins Jr. wrote: That's why I mentioned an inlinestyle at the top of thebody - I'm not sure if browsers skip past that when building the tree or not, They certainly skip past such things when prefetching. Putting information that needs to affect prefetching in elements where the HTML tokenizer can extract it is vastly better than putting it into elements where it can't (like style). That's what I was afraid of. All right, then, ignore that part of the suggestion. This should live in HTML if it lives anywhere. ~TJ
Re: [whatwg] Features for responsive Web design
Please, have you taken a look at the latest idea?
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
It solves many issues:
1) works with pre-fetch
2) is not verbose
3) is backward compatible with current browsers
4) is aimed for future-proofing - a re-design later with new or
different breakpoints would result in no edits to the mark-up
5) Avoids repetition and excessive processing of multiple media tests
I'd greatly appreciate more feedback on this approach at the Community Group.
Kind regards,
Matt Wilcox
On 15 May 2012 08:28, Ian Hickson i...@hixie.ch wrote:
On Wed, 25 Jan 2012, Matthew Wilcox wrote:
On 24 January 2012 23:26, Ian Hickson i...@hixie.ch wrote:
On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
As we now have the possibility of creating fluid and responsive
layouts in several ways we have a problem with images.
There's currently no good feature to implement something like
responsive images which adapt to the different device-resolutions.
We only can implement one image with one resolution scaling-up and
down.
You can do adaptive sites using media queries.
!-- HTML --
h1My Site/h1
// CSS
@media (min-width: 320px and max-width: 640px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
}
@media (min-width: 640px and max-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
}
@media (min-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
}
This is of no use to content images - which are the real problem. CSS
supplied images are not an issue.
Fair enough.
Looking at the feedback on these threads over the past few months (I
didn't quote it all here, but 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), it seems there are three main
axes that control what image one might want to use on a page, assuming
that one is rendering to a graphical display:
- the size of the viewport into which the image is being rendered
- the pixel density of the display device
- the network bandwidth available to the page to obtain resources
Now I'm not sure what to do about the bandwidth one. It's very hard for a
user agent to estimate its bandwidth availability -- it depends on the
server, and the network location of the server, almost as much as on the
location of the client; it depends on the current network congestion, it
depends on the other things the browser is doing; it depends on whether
the user is about to go through a tunnel or is about to switch to wifi; it
depends on whether the user is roaming out of network or is on an OC48
network pipe. It's hugely variable. It's not clear to me how to
characterise it, either. It's also something that's changing very rapidly.
On the more modern mobile networks, the real problem seems to be latency,
not bandwidth; once you've actually kicked off a download, you can get the
data very fast, it just takes forever to kick it off. That kind of problem
is better solved by something like SPDY than by downloading smaller
images. Downloading smaller images also screws up zooming images, which
happens a lot more on mobile than on desktop.
A number of people proposed solutions that are variants on the
video/source mechanism, where you have an abundance of elements to
replace the lonely img. Looking at the examples of this, though, I could
not get over how verbose the result is. If we're expecting this to be
common -- which I think we are -- then really can't be asking authors to
be providing dense collections of media queries, switch-statement like
lists of URLs, and so forth, with each image.
Nor can we ask authors to provide a default and then have an external CSS
file give alternatives. The syntax is different (and in some proposals
actually already possible today), but the fundamental problem still
exists: it's way too much work for just inserting an image in a page.
Another proposal that various people advocated is a header that the
servers can use to determine what content to use. Besides a wide number of
problems that people pointed out with this on the thread (such as the
privacy issues due to fingerprinting, the many ways that such information
gets abused, the high aggregate bandwidth cost, the difficulties with
using headers in offline scenarios, etc), the biggest problem with this
idea, IMHO, is that authors have shown that HTTP headers are simply a
non-starter. Content-Type headers are perenially wrong, Accept headers are
mishandled all over the place, adding Origin headers has caused
compatibility issues... HTTP headers are a disaster. If there's ever an
option to solve a problem without HTTP headers, we should take it, IMHO.
On Tue, 7 Feb 2012
Re: [whatwg] Features for responsive Web design
Constraints on where assets are placed and named? I do not follow your
reasoning here: You put them in the folder that's used for that design
breakpoint:
/anything/{whatever}/this/can/be/anything.jpg
I've seen no objections about that aspect in the Community Group
thread, where a number of authors have given feedback.
It addresses pixel density because it uses media queries and they
address pixel density. Any media query should be valid, so it's not
just
meta name=case value=large media=min-width:900px; /
you could use
meta name=case value=very-large media=(device-pixel-ratio:2) and
(min-width:30em) /
for example. MQ are by far the most flexible way of dealing with
reacting to device constraints.
What is set is the path to look for the image. This is *exactly* how
this works in CSS already for background-images and all authors are
familiar with this - you don't set the pixel density of an image, you
detect the device pixel density and change the path of the image you
send over CSS. Have a look at how almost any site is built and you'll
see *paths* change, not *image names*. http://enochs.co.uk is one
example.
Requiring access to head is not much of an issue, and has not been
raised by anyone commenting on the CG thread. Web designs tend to be
3-7 breakpoints that are shared site-wide. The actual design of each
page may not be, but the breakpoints are. This is why site's with many
types of page can all share the same list of CSS assets to load:
!-- Styling for all devices --
link rel=stylesheet media=screen href=/assets/css/screen.core.css /
!-- Styling for progressively larger displays --
link rel=stylesheet media=only screen and (min-width: 320px)
href=/assets/css/screen.320.css /
link rel=stylesheet media=only screen and (min-width: 480px)
href=/assets/css/screen.480.css /
link rel=stylesheet media=only screen and (min-width: 750px)
href=/assets/css/screen.750.css /
link rel=stylesheet media=only screen and (min-width: 960px)
href=/assets/css/screen.960.css /
We are proposing nothing different than that, but to set variables
rather than to load a particular CSS file.
If it works for authors using CSS, why should it not also work for
setting image paths?
-Matt
On 15 May 2012 10:57, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox m...@matthewwilcox.com
wrote:
Please, have you taken a look at the latest idea?
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
It was quoted and replied to in the email you just replied to.
It has many problems. It adds a level of indirection, it imposes
constraints on where the resources are located and how they are named,
it requires access to the head element for adding an image in a blog
post, and it makes processing of URLs conditional on information
provided elsewhere. These are all significant issues.
I also do not see how it addresses the pixel density use case. You
cannot use a media query for that because a media query queries the
pixel density of the device, it does not *set* the pixel density of
the resource.
--
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Features for responsive Web design
I do not see much potential for srcset. The result of asking the
author community was overwhelmingly negative, indirection or no
indirection.
To be clear, I don't see how indirection of this level can be an
issue, under those terms anything you write in CSS to effect a HTML
element is already indirect - to the extent of being in a different
file entirely.
-Matt
On 15 May 2012 11:13, Matthew Wilcox m...@matthewwilcox.com wrote:
Constraints on where assets are placed and named? I do not follow your
reasoning here: You put them in the folder that's used for that design
breakpoint:
/anything/{whatever}/this/can/be/anything.jpg
I've seen no objections about that aspect in the Community Group
thread, where a number of authors have given feedback.
It addresses pixel density because it uses media queries and they
address pixel density. Any media query should be valid, so it's not
just
meta name=case value=large media=min-width:900px; /
you could use
meta name=case value=very-large media=(device-pixel-ratio:2) and
(min-width:30em) /
for example. MQ are by far the most flexible way of dealing with
reacting to device constraints.
What is set is the path to look for the image. This is *exactly* how
this works in CSS already for background-images and all authors are
familiar with this - you don't set the pixel density of an image, you
detect the device pixel density and change the path of the image you
send over CSS. Have a look at how almost any site is built and you'll
see *paths* change, not *image names*. http://enochs.co.uk is one
example.
Requiring access to head is not much of an issue, and has not been
raised by anyone commenting on the CG thread. Web designs tend to be
3-7 breakpoints that are shared site-wide. The actual design of each
page may not be, but the breakpoints are. This is why site's with many
types of page can all share the same list of CSS assets to load:
!-- Styling for all devices --
link rel=stylesheet media=screen href=/assets/css/screen.core.css /
!-- Styling for progressively larger displays --
link rel=stylesheet media=only screen and (min-width: 320px)
href=/assets/css/screen.320.css /
link rel=stylesheet media=only screen and (min-width: 480px)
href=/assets/css/screen.480.css /
link rel=stylesheet media=only screen and (min-width: 750px)
href=/assets/css/screen.750.css /
link rel=stylesheet media=only screen and (min-width: 960px)
href=/assets/css/screen.960.css /
We are proposing nothing different than that, but to set variables
rather than to load a particular CSS file.
If it works for authors using CSS, why should it not also work for
setting image paths?
-Matt
On 15 May 2012 10:57, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox m...@matthewwilcox.com
wrote:
Please, have you taken a look at the latest idea?
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
It was quoted and replied to in the email you just replied to.
It has many problems. It adds a level of indirection, it imposes
constraints on where the resources are located and how they are named,
it requires access to the head element for adding an image in a blog
post, and it makes processing of URLs conditional on information
provided elsewhere. These are all significant issues.
I also do not see how it addresses the pixel density use case. You
cannot use a media query for that because a media query queries the
pixel density of the device, it does not *set* the pixel density of
the resource.
--
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Features for responsive Web design
That's one of the major advantages of Adaptive Images (the PHP/JS
solution) and what people most like about it when they give me
feedback - it's all automatic with no custom HTML and it does all
image generation itself.
Yes, the vast majority of people who are going to put images into
websites are not web-developers but people using some CMS. The only
way these people are going to get multiple versions of the same image
is if the CMS can do it either automatically through re-sizing (as AI
does) or through providing upload fields for each breakpoint size.
The problem for end users (CMS users) is one of asset creation -
that's not a problem which can be solved by us in the scope of this
work - but we *do* need to consider this with whatever we end up
implementing. It is *highly* likely that the majority of use cases any
adaptive HTML mechanism will be applied to will have assets reference
through some automated image creation facility - as opposed to
hand-created.
That's why setting path variables is good. It's very likely that any
CMS is going to dump images into folders based on their fitting into a
design breakpoint: exactly as Adaptive Images does now. The number of
uses where people will manually create images at all sizes to
non-predictable paths are competitively tiny.
One-off responsiveness (one image element on a page, which is unique
in terms of adaption points) is where picture may be useful. For
general responsiveness, the meta variable method is much more
appropriate and efficient.
-Matt
On 15 May 2012 12:51, Shane Hudson sh...@shanehudson.net wrote:
I agree Matt. I have gone back to basics to define exactly what we are all
needing and look to see if there are any ways we have not yet thought of.
Ian's explaination of srcset makes me feel more comfortable with it than the
original draft did, however I do believe it is the wrong way to go. There is
a lot of repetition and very little room for expansion, the syntax also
means that every img tag will look horrendous as more sizes develop.
As I say, I am going to be writing a detailed reply shortly.
I do have one question though… since the majority of images on the web are
uploaded by general users (through the use of a CMS or image uploader such
as flickr or Facebook), does anyone yet have a solution in which the user
does not have to manually create the separate files? I may be missing
something very simple here, but we do not want to be changing the user
experience, a script will need to be able to convert a single image into the
different sizes. I might be wrong in thinking a general image resizer would
not work for this?
Shane Hudson (Website Developer - www.ShaneHudson.net)
07794746595
@ShaneHudson / +Shane Hudson
On Tuesday, 15 May 2012 at 11:22, Matthew Wilcox wrote:
I do not see much potential for srcset. The result of asking the
author community was overwhelmingly negative, indirection or no
indirection.
To be clear, I don't see how indirection of this level can be an
issue, under those terms anything you write in CSS to effect a HTML
element is already indirect - to the extent of being in a different
file entirely.
-Matt
On 15 May 2012 11:13, Matthew Wilcox m...@matthewwilcox.com wrote:
Constraints on where assets are placed and named? I do not follow your
reasoning here: You put them in the folder that's used for that design
breakpoint:
/anything/{whatever}/this/can/be/anything.jpg
I've seen no objections about that aspect in the Community Group
thread, where a number of authors have given feedback.
It addresses pixel density because it uses media queries and they
address pixel density. Any media query should be valid, so it's not
just
meta name=case value=large media=min-width:900px; /
you could use
meta name=case value=very-large media=(device-pixel-ratio:2) and
(min-width:30em) /
for example. MQ are by far the most flexible way of dealing with
reacting to device constraints.
What is set is the path to look for the image. This is *exactly* how
this works in CSS already for background-images and all authors are
familiar with this - you don't set the pixel density of an image, you
detect the device pixel density and change the path of the image you
send over CSS. Have a look at how almost any site is built and you'll
see *paths* change, not *image names*. http://enochs.co.uk is one
example.
Requiring access to head is not much of an issue, and has not been
raised by anyone commenting on the CG thread. Web designs tend to be
3-7 breakpoints that are shared site-wide. The actual design of each
page may not be, but the breakpoints are. This is why site's with many
types of page can all share the same list of CSS assets to load:
!-- Styling for all devices --
link rel=stylesheet media=screen href=/assets/css/screen.core.css /
!-- Styling for progressively larger displays --
link rel=stylesheet media=only screen
Re: [whatwg] Features for responsive Web design
Um, the fact of the matter is we don't want to ensure they have the same ratio. It is exactly why we want to swap images sometimes - the aspect ratio no longer fits the design being applied at the given breakpoint. On 15 May 2012 18:48, Jason Grigsby ja...@cloudfour.com wrote: On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote: On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby ja...@cloudfour.com wrote: Are you saying that all of the image source listed in srcset would have the same aspect ratio? In the example Hixie provided, face-icon.png is a different ratio. Another way to read this could be that you’re fine so long as your sources with different densities (e.g., 1x, 2x, etc) always have the same ratio. If so, I’m unclear on how that solves the problem when you have images that need different cropping like the Nokia example which is vertical in one case and horizontal in another. That's what I'm saying. Authors *can* ensure that, within a particular breakpoint, their multi-res images all have the same ratio. It's a good idea, since the *intention* is that the multi-res versions are all exact same image, just at different resolutions. If you don't do that, you get unpredictable results, but you asked for that. If you *do* do that, then you know what your aspect ratio will be, and you can predict which breakpoint will be chosen and pair that with MQs to adjust the rest of your layout. Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do it”? Or am I missing something? BTW, I know things are a little heated on irc right now so please read my questions as sincere attempts to understand how this would work and not as attempts to be obstinate. :-) -Jason
Re: [whatwg] Features for responsive Web design
I think there's a fundamental mis-match in the mental model of how authors work and what they want. I'm pretty sure we're all shooting for the same be more efficient goal, but I think that here on the mailing list that's being approached from an angle that has not considered how authors actually want to do this. We work with designs that re-arrange content and sometimes call for different images of the same semantic meaning. That is *not* the same use case as simply sending a different version of the same image. Srcset only addresses that one type of use, and that is why authors feel it's flawed. It doesn't do what we need, and never can because srcset is based on the assumptin that a UA can somehow pick an appropriate resource to load - when it can't possibly know about the authors use of that resource at that time. -Matt On 15 May 2012 19:19, Matthew Wilcox m...@matthewwilcox.com wrote: Um, the fact of the matter is we don't want to ensure they have the same ratio. It is exactly why we want to swap images sometimes - the aspect ratio no longer fits the design being applied at the given breakpoint. On 15 May 2012 18:48, Jason Grigsby ja...@cloudfour.com wrote: On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote: On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby ja...@cloudfour.com wrote: Are you saying that all of the image source listed in srcset would have the same aspect ratio? In the example Hixie provided, face-icon.png is a different ratio. Another way to read this could be that you’re fine so long as your sources with different densities (e.g., 1x, 2x, etc) always have the same ratio. If so, I’m unclear on how that solves the problem when you have images that need different cropping like the Nokia example which is vertical in one case and horizontal in another. That's what I'm saying. Authors *can* ensure that, within a particular breakpoint, their multi-res images all have the same ratio. It's a good idea, since the *intention* is that the multi-res versions are all exact same image, just at different resolutions. If you don't do that, you get unpredictable results, but you asked for that. If you *do* do that, then you know what your aspect ratio will be, and you can predict which breakpoint will be chosen and pair that with MQs to adjust the rest of your layout. Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do it”? Or am I missing something? BTW, I know things are a little heated on irc right now so please read my questions as sincere attempts to understand how this would work and not as attempts to be obstinate. :-) -Jason
[whatwg] An alternative to picture and srcset, is this realistic?
Hi all, have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Cheers, Matt
Re: [whatwg] An alternative to picture and srcset, is this realistic?
I'd contest that it is no harder to understand than it is to understand why your CSS behaves differently when a JS element acts on the mark-up. We are used to one stack defining how another acts. We do it all the time. Adding classes to mark-up to control display, or just the cascade on its own does this. Is this harder to understand than picture or srcset is what really matters. Anything we do to resolve this resource adaption problem will by necessity complicate things. Is this better than the alternatives? Remember too that this idea can be mixed with existing techniques, it is not a replacement for other ways of dealing with stuff. You'd be free to bake your media-queries into CSS in exactly the same way as you do now, if a sub-module didn't want to respond to a generic breakpoint, for example. -Matt On 14 May 2012 11:01, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Adding a level of indirection is actually not that great as it makes it harder to understand what is going on. Also if you work on sites in teams it's not always a given access to head is equal to the templates that are being authored. Let alone full control over how resources are stored. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] An alternative to picture and srcset, is this realistic?
Thanks for the feedback. Please also forgive me not being too technically aware of things at a browser level; so I'm not really sure how valid my feedback can be: The URI thing is actually using URI Templates, which are already pretty far along? http://code.google.com/p/uri-templates/ I thought this was a strong advantage of the idea. Putting the variables into the CSS would break the advantage of them being available to the browser *before* the browser starts trying to pre-fetch images, right? Any solution has to avoid the prefetch behaviour or else it fails; so I don't understand how they could be moved. I am of the opinion that media queries actually belong in the head more often than they do elsewhere, both from a practical and semantic standpoint (see http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752 ) I had presumed that should multiple cases match the browser would simply uses the last matching one. There's already a polyfil in JS that does exactly that: http://jsbin.com/3/ecifaf/latest/ On 14 May 2012 15:50, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: Hi all, have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Several critiques, in more or less random order: I'm not sure why it's billed as an alternative to @srcset as well - it has nothing to do with that functionality. It's purely a way to stuff your media queries (which, as already established, can't be used to serve different resolutions well) into a variable, and then abstract your url-rewriting into a single place. I do like the idea of abstracting your MQs - the post makes a good point that between CSS and JS you're already duplicating your breakpoints, and if picture or a similar solution is adopted, you'll be doing it a lot more. Unfortunately, Media Queries aren't immediately amenable to CSS Variables (moving from global vars to tree-scoped vars means that things that aren't part of the element tree can no longer see the vars), so we either need something like this, or I need to add to Variables so that they're friendly to this use-case (and can interact with the URL-rewriting mechanism proposed). I share Anne's concern that the contents of head are often not trivially authorable. This isn't killer, but it's something to keep in mind. Moving the definition to CSS might help here, as it could be put in an inline CSS block at the top of body then. This approach implies that all of your images (at least, all of them with [case] in their URL) must respond to *all* of your breakpoints. If an image doesn't change between certain breakpoints, it still needs to exist in two places on your server (or you need to manually alias a single file) and the browser will make an extra useless request if you cross those breakpoints. From a technical purity standpoint, this introduces a new URL-rewriting mechanism, but specialized for only a single purpose. I suspect there are other uses that URL-rewriting could potentially be put to; we should think about this and make sure that this approach doesn't close the door to future uses. (It doesn't need to be magically infinitely extensible - that way lies madness - but making reasonably sure that it doesn't close the door to other URL-rewriting use-cases is just good sense.) I mentioned above that this solution has nothing to do with @srcset. It's actually slightly worse - this ends up being *hostile* to @srcset, such that you can't combine the two. At least, not without reworking @srcset into a parallel URL-rewriter. The proposal doesn't explain what to do when multiple MQs match. Normally, the CSS cascade takes care of this - if you apply the same property under multiple MQs that all match, specificity determines the winner. It wouldn't be difficult to define how this worked - last-wins is probably the sanest - but still, it's a detail to be specified. Note, though, that if we want this to hook into a more generic variables-in-MQ sort of thing, one may indeed want multiple axises of variables that can match together. I suspect this is especially useful with the new media queries that will show up in MQ4 to help target different kinds of devices. So, it may be good to look into widening this to accomodate different variable names, where within a variable only a single case can win at a time. Related - it would probably be good to be able to define a default case to fall back to when none of the others match. ~TJ
Re: [whatwg] An alternative to picture and srcset, is this realistic?
All good points, thanks. Sorry I'd missed you saying style rather than link/, my bad! I had assumed that we would be able to take the logic for resolving media query applicability directly from that in CSS, which is why I have not given it any further thought. It seemed like a solved issue. I ought to point out I've been updating the main post today, and have also added a prior art thing about how this works for JavaScript - the Conditional CSS technique is already doing what I am proposing here, but using pesudo content rather than a meta tag. :) On 14 May 2012 16:55, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 5:34 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for the feedback. Please also forgive me not being too technically aware of things at a browser level; so I'm not really sure how valid my feedback can be: The URI thing is actually using URI Templates, which are already pretty far along? http://code.google.com/p/uri-templates/ I thought this was a strong advantage of the idea. I don't know of this having any traction within actual browsers. It might be a good idea, I dunno. Putting the variables into the CSS would break the advantage of them being available to the browser *before* the browser starts trying to pre-fetch images, right? Any solution has to avoid the prefetch behaviour or else it fails; so I don't understand how they could be moved. That's why I mentioned an inline style at the top of the body - I'm not sure if browsers skip past that when building the tree or not, but it's *potentially* available. I am of the opinion that media queries actually belong in the head more often than they do elsewhere, both from a practical and semantic standpoint (see http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752 ) I don't necessarily disagree. I wasn't arguing from a theoretical standpoint, just supporting Anne's point that, from a practical standpoint, putting things into head isn't always easy for authors. I had presumed that should multiple cases match the browser would simply uses the last matching one. There's already a polyfil in JS that does exactly that: http://jsbin.com/3/ecifaf/latest/ Yeah, you can't assume that. They're conditions, and a page can potentially match multiple of them at once. For example, if your MQs are min-width: 1000px and min-width: 300px, a 1200px wide screen will match both of them. You can *make* them exclusive by adding a max-width declaration as well, but we can't depend on that happening, so the behavior has to be specified somewhere. Similarly, we can't depend on *any* of them matching, so there should be a default case that is used when nothing else matches. ~TJ
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 6 February 2012 19:24, Irakli Nadareishvili ira...@gmail.com wrote: Boris, if you don't mind me saying it, I am afraid you may be missing the point of this request. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. I'm afraid you have missed the point, not Boris. We do not care about device classes at all, those are a temporary and limited idea. We care about device capability. Right now we have to use screen-size as a clunky proxy for processor speed, gpu acceleration capabilties, bandwidth, latency, etc. The device class idea is no better than this already demonstrably ridiculous and inaccurate assumption that screen size correlates conclusivly with any of those values. There is *nothing* that states that a small screen means a mobile device. Or that a large screen means a desktop device. A phone today is much more powerful than a 8yr old desktop. A tiny screen device can be attached to a fast WIFI and a 27 iMac could be out in the sticks on a rubbish ISDN connection. This situation does not chance when a device reports some marketing-made-up class name. What's to stop a mobile class device having a quad core CPU and 100Mbps WIFI and a retina screen some 900px wide? What's to stop a desktop class device being hooked up to a 800x600 projector in farm country with poor connectivity? If you based your supplied assets on device class then you'd be doing both those users the wrong way around. Device class tells us *nothing* for certain. We are not interested in some temporary and imagined classing system; what we want are the device capabilities. Not assumptions of them based on other aspects (like screen size or this class idea). Such ideas do not hold up.
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
+1 to everything Jason Grigsby just said. If not here, where? If not with you, with who? We've been doing this publicly for months and months...
Re: [whatwg] RWD Heaven and responsive-images
Nice work Victor, I'm all for that but I am hesitant as to how effective it will be. The thing is, we need the feedback from the people in this list to notice stumbling blocks. The CG could spend weeks honing a solution only to have it presented here and blown away because someone for here knows something intricate that the CG community didn't. That's a worry. -Matt On 9 February 2012 14:00, Ronjec Viktor ronjec.vik...@gmail.com wrote: On Thu, Feb 9, 2012 at 2:19 AM, Jason Grigsby ja...@cloudfour.com wrote: On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote: People, this is really getting out of hand... 1. WHATWG is a standards body, meaning it _standardizes_ solutions. Everyone who followed the discussion up until now can easily tell that currently there is no unified, or even close to common approach to this topic yet. Someone says the solution is on server-side, the other one says it's on the client-side, the third one says network protocol, the forth says headers... This is not the place for such a discussion IMHO. As a newcomer to the list, I’ve tried to wade in lightly because I’m not certain how these things work. So I’m pleased you wrote that. My question would be where should the conversation happen then? It seems that within the authoring community finding a solution to handling images has been a hot topic for months. But my experience has been that whenever I see attempts to bring the conversation to people deeply involved in the standards process, the problems are often dismissed or many objections are raised the proposed solution. Two weeks ago I was talking with Ernesto Jiménez about how the W3C and WhatWG efforts needed feedback and participation from authors. But it is unclear to me how that should happen. To wit, we have a problem that many of us have being trying to solve. I for one don’t have confidence that those of us who are commonly outside the standards-setting process have the correct answer. I’d be happy for someone smarter than me to propose solutions that move things forward. To make that happen, it seems necessary to convince people that an actual issue exists and to discuss potential solutions somewhere. So an honest and humble question, if that doesn’t happen here, where does it happen? -Jason On Thu, Feb 9, 2012 at 11:36 AM, Matthew Wilcox m...@matthewwilcox.com wrote: +1 to everything Jason Grigsby just said. If not here, where? If not with you, with who? We've been doing this publicly for months and months... To prevent being labelled as a troll for questioning the merit of such ambiguous discussion on WHATWG, I have contacted people for help. Dominique Hazaël-Massieux, who himself has made proposals on solutions concerning the topic to the W3C HTML Working Group (http://lists.w3.org/Archives/Public/public-html/2011May/0386.html) has recommended to me that maybe creating a Community Group at W3C would be in order. Community Groups differ from Working Groups in that participants of the discussion are trying to find a common ground for consensus on what a solution should be to a given problem, before proposing it for standardization to a standards body. In my opinion, until everyone is proposing something else (e.g. HTTP headers, SPDY protocol, device classes, new markup with new alt tags, etc) we create the following CG and move the discussion there: Proposed name: Adaptive Media Community Group Proposed group description: The Adaptive Media Community Group is a community of web developers seeking a solution so that embedded media in HTML (e.g. images and videos using the img and video), and their properties (e.g. dimension, compression ratio) are optimum to given factors, such as device screen resolution or available network bandwidth. Proposed shortname for CG: adaptmedia Of course, creating a CG would be completely meaningless if there is no interest and support for it from the community. I believe there is interest for it, but the question is, is there support for it? The above is just a my proposal in advancing this discussion, and until there is no feedback about this from people on the RWD Heaven: if browsers reported device capabilities in a request header and the add html-attribute for responsive images threads, and other developers concerned in Responsive Web Design, I don't think I should just create the group and hope that the discussion will just move and concentrate there on its own. So open for feedback on this! Kind regards to all, Viktor
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Can I suggest you read http://24ways.org/2011/adaptive-images-for-responsive-designs-again then please? It does not work fine at all. Cheers, -Matt On 6 February 2012 20:23, Charles Pritchard ch...@jumis.com wrote: Scripting on the client side works just fine. It's pure markup situations where you run into problems. I'm well aware that Image nodes are alive. I'm keeping an eye out on the DOMParser method to see if they're alive when it parses as text/html. I recently wrapped some noscript tags around HTML image nodes to prevent them from blocking my onload. Works fine. -Charles On Feb 6, 2012, at 12:16 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Scripting on the client side for the purposes of content negotiation *does not work* Please, understand this. Because browsers pre-fetch as soon as a node is created there can be no client-side solution to this issue with the current HTML/JS specifications and browser behaviour. The image linked in the HTML is *always* requested, and it is requested before the client can do a damned thing about it. On 6 Feb 2012, at 20:03, Charles Pritchard wrote: On Feb 6, 2012, at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky bzbar...@mit.edu wrote: That really depends on what the application is doing. Depending on input capabilities, you may want to have multiple pages instead of a single page for some sort of configuration setup, for example. Whether to use monolithic forms or paginated wizards is a presentation thing Not on the HTML level. Not if you want to allow useful non-scripted semantic submission of partially-filled-in info in the paginated case. that need not even have anything to do with HTTP. You can fetch half the monolithic form and fetch the rest when the user has filled in most of former half. Not without script. I really didn't like the consequences of server-side scripting to manage dependencies. It was always more work than simply doing the scripting in the client side. It was more prone to error. It let our coders get away with less rugged design. I'm in the responsive and universal design camp. I'm in the accessibility camp. At present, it does require scripting. I'm building web apps, so, scripting comes with that territory. It seems to me like these folk are looking for iframe defer and style defer and some sort of media selector for the network information API, to minimize bandwidth on metered connections without needing to use scripting to do that work. I'm interested in seeing a solution here. I do not think server-side management is the right one. -Charles
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On 7 February 2012 00:12, Jason Grigsby ja...@cloudfour.com wrote: I agree that this is a problem. I’ve spent far too much time trying to find solutions for images in responsive designs and none that I reviewed work. (research at http://cloudfour.com/responsive-imgs-part-2). Seconded, my work has been http://adaptive-images.com But I find the arguments that Henri Sivonen made against putting the information in the header to be compelling: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034642.html FWIW, there was an RFC back in 1996 describing a similar request: http://tools.ietf.org/html/draft-mutz-http-attributes-01 Personally, I’d rather see a new element or a new image format a la the add html-attribute for 'responsive images' thread going on right now. Or if it is headers, I’d like to see something that is more inclusive and could be used for servers requesting different information instead of codifying something only for screen size. Absolutely agree that we should not be concentrating on one specific thing. What I want is the ability to have the server ask for whatever info it needs about the client device/environment, and have that sent as a header. And only sent if the server has asked. I don't mean we want screen size alone, that is but one example of something the server might care about. Bandwidth is another, as is viewport size, and I am sure there are a lot more. I want to see a *communication method* defined here, not a one-issue semi-solution to an overly specific example of what is in reality a much broader problem (the server not having reliable information about the client). -Jason Also, as I've mentioned whenever I talk about this stuff: server side is ONE half of the solution. The other is new HTML. They do two different things, and they appear superficially similar when they aren't. Server side adaptation is about the times when it's right for the server to take automated action based on the client's capabilties: e.g., sending lower quality graphics when it detects the bandwidth is low. Mark-up solution is about sending actual different URLs. e.g., an about page mug-shot. At high device sizes this may be a full-length body shot. At smaller sizes it's not practical to simly shrink it as you no longer recognise what's important, so you substitute a head and shoulders shot for lower screen sizes. Different content that's doing the same semantic job.
Re: [whatwg] add html-attribute for responsive images
@Mathew Marquis - that was a good article, I was so pleased to see the thinking behind it getting some attention at last! I've been trying to push this idea since launching adaptive-images.com , and a number of people have come up with the same client-side quasi-solution independently. Bruce Lawson's mark-up suggestion was the first example I'm aware of and I've linked to it on the list before. 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side)
Re: [whatwg] add html-attribute for responsive images
Can you clarify why the image would be loaded twice? Can we not, as part of the logic for the picture element, say that img is ignored in supporting browsers? Thus, never called by a supporting browser. Non supporting browsers wouldn't load the src elements and would only load the img Right? On 7 February 2012 10:31, Anselm Hannemann ans...@novolo.de wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
I don't have the expertise on exactly how these things function, but from my common sense approach to it surely the browser has to have encountered the picture opening tag before it can encounter the img tag in order to read the source URL for that image. At which point, would the browser not know to apply the don't load an img if it's in a picture behaviour? And if that's not the case, can we not argue the case to vendors that the pre-fetch behaviour needs to take this into account because it's the pre-fetch behaviour that is causing the harm here? On 7 February 2012 10:37, Anselm Hannemann ans...@novolo.de wrote: As far as I understand browsers like Chrome preparse sites where they don't actually get the DOM but load resources they find in code. So it would be impossible to say it shouldn't be loaded. See this comment about it: http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41 Am 07.02.2012 um 11:34 schrieb Matthew Wilcox: Can you clarify why the image would be loaded twice? Can we not, as part of the logic for the picture element, say that img is ignored in supporting browsers? Thus, never called by a supporting browser. Non supporting browsers wouldn't load the src elements and would only load the img Right? On 7 February 2012 10:31, Anselm Hannemann ans...@novolo.de wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
I'm glad this is making a reasonable amount of sense to people :) Please note however that this isn't just a case of the image is cropped. It could be an entirely different image *as long as* it still carries the same semantic message. In that, the image in the About example is merely to give a visual representation of someone. As long as all of the scaled images do that, they do not need to be *the same image* re-cropped. In fact, it would be better in this case to have different images. Hence why it makes sense to have the ability to over-ride the alt attribute on each source. There's nothing to stop us saying that an alt attribute can be declared on the default image, and is only over-written if the src contains a new alt attribute? -Matt On 7 February 2012 13:42, Mathew Marquis m...@matmarquis.com wrote: On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice. Would it? I think Matthew's example implies that a supporting browser *wouldn't* load the src from the img unless none of the sources got a media match. Right? I’m not sure how it’s intended to work with video currently, but I believe the fallback is only loaded if video is unsupported—if none of the sources match, I believe nothing is displayed. I may be wrong, but that seems to be the most predictable behavior. The way I proposed it would have the same behaviour but have the img as the first child element of picture, making it more apparent that it's the default content as well as the fallback content. Also, it would contain important attributes like alt. So: picture img src=default.jpg alt=A photo of Bob Flemming / source href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / source href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / source href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture And: - unsupporting browsers would get default.jpg (but the author could implement some JS to run the source media queries and swap in the most appropriate image if desired) - supporting browsers narrower than 320px would also get default.jpg, because none of the sources would get a media match - supporting browsers 320px or wider would get the image from the last source to get a media match (because a 800px wide screen would match all 3 in this example) I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, though, as it wouldn’t be strictly required—the fallback content could be, say, descriptive text instead (Granted I wouldn’t do it, but just trying to keep things as flexible as possible). I do think all sources should be described by a single alt tag, though, possibly on picture itself? FWIW, whatever becomes of the discussion about sending media-query-like data in headers to the server (RWD Heaven: if browsers reported device capabilities in a request header), we need this responsive image markup regardless. Hear hear! Thanks David
Re: [whatwg] add html-attribute for responsive images
PS: I am a strong believer that we need both a server-side and client-side solution to this problem of adaptive media. They solve different aspects of what seem superficially the same things :)
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws inflicted by the dated mechanics of HTTP. Is it really different semantics though? I don't see how it's harmful to enable resource adaption over SPDY just because browser vendors have decided that HTTP is too expensive to do it? To be clear: this is a case of browser vendors deciding it's too expensive and therefor not allowing it to be implemented, when it should be authors in the position to know whether it's too expensive given their specific use case. I'm sensing the SPDY/HTTP identical-semantics standpoint may be a philosophical thing rather than technical? No offense taken btw. Things have to prove themselves. The danger is the standards process is too slow to react well, and some even more hacky solution turning into a de-facto standard. Personally, I think the issue of adapting resources to client capabilities is here to stay. Devices of significantly varied size and performance are here to stay, and adapting images to suit is only one example of smart resource adaption - it doesn't seem like it would become irrelevant until all devices are memory and processor monsters over high speed connections. Which is going to take decades, if it ever happens. I'm glad the discussion is going on though, and there are as always points to be considered that are not obvious at first. It just seems like SPDY as a technology is in a great position to do this. It's the choice of restricting SPDY to HTTP's viable capabilities which is the cause of a potential veto of this. :) On 7 February 2012 13:34, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Also, as indicated, with SPDY this is much much less of a problem than for HTTP. SPDY transfers the HTTP semantics more efficiently when supported. You aren't supposed to communicate different semantics depending on whether SPDY is enabled. That would be a layering violation. That is, SPDY is supposed to work as a drop-in replacement for the old way of putting HTTP semantics over IP. You aren't supposed to send different headers depending on whether SPDY is there or not. And the old HTTP is going to be around for a *long* time, so even if a bunch of important sites start supporting SPDY, if browsers send the same headers in all cases to avoid the layering violation, the long tail of plain old HTTP sites would be harmed by request size bloat. So I think SPDY will fix it is not a persuasive argument for allowing HTTP request bloat to cater to the bandwagon of the day. (Sorry if that seems offensive. You've worked on responsive images, so they evidently seem important to you, but in the long-term big picture, it's nowhere near proven that they aren't a fad of interest to a relative small number of Web developers.) If there is evidence that responsive images aren't just a fad bandwagon and there's a long-term need to support them in the platform, I think supporting something like picture source src=something.jpg media=... source src=other.jpg media=... img src=fallback.jpg /picture would make more sense, since the added to transfer this markup would affect sites that use this stuff instead of affecting each request to all sites that don't use this stuff. This would be more intermediary-friendly, too, by not involving the Vary header. The points Boris made about the device pixel size of the image changing after the page load still apply, though. But still, engineering for sites varying the number of pixels they send for photos seems a bit premature when sites haven't yet adopted SVG for illustrations, diagrams, logos, icons, etc. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] add html-attribute for responsive images
That's a fair enough point. I'd /like/ to be able to over-ride the alt with something even more specific, but I do agree the core semantics should be the same - so a 'generalised' alt would work too, just be a little less informative than it could be. I could see the advantage of not allowing alt over-riding in that it forces the alt to be applicable to all sources which then strengthens the vibe that the images, although different, should have the same semantics. On 7 February 2012 14:59, David Goss dvdg...@gmail.com wrote: On 7 February 2012 14:00, Matthew Wilcox m...@matthewwilcox.com wrote: I'm glad this is making a reasonable amount of sense to people :) Please note however that this isn't just a case of the image is cropped. It could be an entirely different image *as long as* it still carries the same semantic message. In that, the image in the About example is merely to give a visual representation of someone. As long as all of the scaled images do that, they do not need to be *the same image* re-cropped. In fact, it would be better in this case to have different images. Hence why it makes sense to have the ability to over-ride the alt attribute on each source. There's nothing to stop us saying that an alt attribute can be declared on the default image, and is only over-written if the src contains a new alt attribute? -Matt On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. My point is that if the two images are supposed to have the same semantic message, then you should be able to describe them both with the same alt text (even if the differences between those images make the alt text a little more vague than it might be). So, as you say, you could have two different photos of the same person for different media, but the alt text photo of Matthew Wilcox would be applicable for both, so that's fine. I'm with you in that I want the flexibility (e.g. the sources shouldn't all have to be literally the same image just resized), I just think saying all sources must correspond with same alt text gives a nice clear definition of what's okay for authors.
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
I don't agree that it's a good idea to have to have the server query some massive device database in order to find out what the requesting device does and does not support. Device databases are, by their nature, going to be hard to maintain, hard to support, and not tell us all we need to know. How is a device database going to tell us the current connection speed, or the user's zoom level, or device orientation, or anything else dynamic that may be relevant to know on the server? The database route is merely an extension of UA sniffing, which was about detecting devices and assuming capabilities and settings. The problem with that was inaccuracy, and ongoing laboured maintenance. I want us to detect the actual capabilities directly - exactly how CSS works. Detect what's there. Skip the middle-man. How does it make sense to resort to siloing this information in a database, when we're the body that makes the standards that would allow direct knowledge? I'm less interested in current work-arounds (and that's what those are, workarounds and best guesses destined to fail at some point) and more interested in getting accurate, reliable, future-proof data exposed. On 7 February 2012 16:46, Charles McCathieNevile cha...@opera.com wrote: On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: Personally, I think the issue of adapting resources to client capabilities is here to stay. For sure, although the mechanisms might evolve. Devices of significantly varied size and performance are here to stay, Yes... and adapting images to suit is only one example of smart resource adaption - it doesn't seem like it would become irrelevant until all devices are memory and processor monsters over high speed connections. Actually I suspect the end condition is until memory and processing and bandwidth are all free which is slightly different. Which is going to take decades, if it ever happens. I will be surprised if I see it. Anyway, I would really encourage you to look at http://en.wikipedia.org/wiki/**Device_Description_Repositoryhttp://en.wikipedia.org/wiki/Device_Description_Repositoryandperhaps something like http://www.openddr.org/ or the commercial solutions that deal with this area. cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Thanks for the feedback :) I've replied inline, but please be aware that I don't have a browser-vendor hat to put on so some of my questions may well be a bit naive (for which I apologise in advance) On 7 February 2012 17:11, Boris Zbarsky bzbar...@mit.edu wrote: On 2/7/12 9:13 AM, Matthew Wilcox wrote: To be clear: this is a case of browser vendors deciding it's too expensive and therefor not allowing it to be implemented This is a case of browser vendors (or at least me with my browser implementor had on) thinking that sending this sort of information will hurt their users' privacy Can you clarify how this hurts privacy? I'm not sure how reporting back things like connection speed or screen size constitutes a genuine privacy issue? , will cause their users to get more broken pages (which is what happens in many cases with browser sniffing right now), will lock new devices out of the market (which is what happens with new UA strings right now). And hence that the proposal is bad for the web in various ways. I'm not sure what your grounds are for thinking this. Would it not be sensible for the server to have to serve some default if the headers aren't there anyway, the assumption must be that the device can't send these headers. In what circumstances might this cause breakages? And how could it possibly lock out any devices? This is a progressive-enhancement type tech, not a if you don't have the ability to notify the server you can't get any info type tech. Surely? Now obviously it's also good for the web in various ways, if people use the information correctly and such. My faith in this is somewhat tarnished by the fact that every concrete proposal for using it that I've seen seems to be broken by design, which means that chances of anyone using it correctly are vanishingly small. Can you tell us how they're broken so we can fix it? We should strive to provide information that will enable the server to better serve the user without it being rocket science to do so without breaking other users. Absolutely agree, but I don't see how a server requesting and then getting a header is rocket sceince. Especially if the current solution is to connect to some massive device database to query potential points of reference and then act accordingly. when it should be authors in the position to know whether it's too expensive given their specific use case. This is privileging authors over users. I understand the author perspective on this, but in general I care about users more than we do about authors I don't think I'm the only one. I can see your point, but there isn't any impact for users unless the author has opted in and requested headers. Right? The defaults are server gets no headers. Put it another way - how can an author tailor things for a user if the user isn't able to report anything to the server? Not allowing this process is a disservice to the user *and* the author. It's basically saying no, you can't drive the car because you may end up on a busy road which will be even slower than walking. No offense taken btw. Things have to prove themselves. The danger is the standards process is too slow to react well, and some even more hacky solution turning into a de-facto standard. Yes, this is a problem. Devices of significantly varied size and performance are here to stay Yes, but size and performance are not necessarily a function of the actual device. They can be a function of the device, the network, the currently attached peripherals, etc. Importantly, they are not time-invariant. The question is what we can do about that... Agreed - which is *exactly* why I think headers are the only viable solution. The other solutions operate by detecting the device and making assumptions about those variables based on the device specifications. Only the device you're talking with right then can possibly have that information. (Simple example: the performance of my laptop will vary by easily a factor of close to 1.5 just depending on whether it's plugged in and what sort of surface it's resting on. I expect this trend to continue unless we get some sort of revolutionary improvements in battery and cooling technology.) Exactly! Hence the need for the browser to report *as a header* with each request what the current values are for those variables. -Boris
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Well given that the point you raise is about opting in and out, not about the capability of fingerprinting itself. Which as you say, already exists. Can we not turn this into an option in the same way browsers handle requests to get the users location? With configuration too? Allow browsers to see my: screen size connection speed … On 7 February 2012 22:45, Mike Taylor mi...@opera.com wrote: On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox m...@matthewwilcox.com wrote: , will cause their users to get more broken pages (which is what happens in many cases with browser sniffing right now), will lock new devices out of the market (which is what happens with new UA strings right now). And hence that the proposal is bad for the web in various ways. I'm not sure what your grounds are for thinking this. Would it not be sensible for the server to have to serve some default if the headers aren't there anyway, the assumption must be that the device can't send these headers. In what circumstances might this cause breakages? And how could it possibly lock out any devices? This is a progressive-enhancement type tech, not a if you don't have the ability to notify the server you can't get any info type tech. Surely? Progressive-enhancement type tech gets abused as well. Take the video element, with its lovely source elements for codecs and fallback content for non-supporting UAs. No hacks necessary. Then throw laziness and javascript at it and you've got a mess. An example, visit http://www.maerskfleet.com/ with an empty UA string (or use Opera). In a browser that should be able to support video, you'll get a JS error and the page is blank. Even after including Modernizr and using HTML5 which is designed to gracefully degrade for older UAs, developers do the same old UA sniffing trick: https://gist.github.com/**1761168https://gist.github.com/1761168 I would love to believe that all developers would use this proposal for good, as it were. Experience leads me to believe it will be just another technique sniffed and served to the regular suspects. -- Mike Taylor Opera Software
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Thanks again, you make some good points :) More responses inline... On 7 February 2012 17:59, Boris Zbarsky bzbar...@mit.edu wrote: On 2/7/12 12:32 PM, Matthew Wilcox wrote: This is a case of browser vendors (or at least me with my browser implementor had on) thinking that sending this sort of information will hurt their users' privacy Can you clarify how this hurts privacy? I'm not sure how reporting back things like connection speed or screen size constitutes a genuine privacy issue? Reporting more information about the user's hardware and software to the server allows better fingerprinting and hence tracking. See https://www.eff.org/deeplinks/**2010/01/primer-information-** theory-and-privacyhttps://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacyand similar resources for details. Agreed. But this already happens. Your point is the user must be able to opt in and out, as they might be turning off JS (which, frankly, how many non-webnerd people do?). So you're saying the problem isn't the tech but the user control? Can we not give that to them? , will cause their users to get more broken pages (which is what happens in many cases with browser sniffing right now), will lock new devices out of the market (which is what happens with new UA strings right now). And hence that the proposal is bad for the web in various ways. I'm not sure what your grounds are for thinking this. Would it not be sensible for the server to have to serve some default if the headers aren't there anyway Maybe it would be _sensible_, but would people do it? I suggest trying to browse the web with an empty UA string and seeing what fraction of servers serve some default for that as opposed to the fraction that completely break and return error pages for everything or return severely malformed pages... Last I tried this, double-digit percentages of the sites I visited broke. Point taken. Though it irks me no end that various technologies get canned because of how inept people can mis-use them. I'd rather see those inept people shoot themselves in the foot and pay the price. Personal philosophy there. In what circumstances might this cause breakages? Whenever the server developer makes dumb assumptions. Which they do all the time. _All_ the time. And how could it possibly lock out any devices? See my earlier example of a desktop-class touchscreen system that's shipping right now. Every single concrete proposal I've seen so far in this thread would lock it out of actually using its touch capabilities on sites that would support such capabilities fine on other devices. I don't think I have enough knowledge of the case in point to argue either way, but I'm confused how this would be the case at the moment. This is a progressive-enhancement type tech, not a if you don't have the ability to notify the server you can't get any info type tech. Surely? Surely not, in my experience with other things servers look for. Fair enough :s Now obviously it's also good for the web in various ways, if people use the information correctly and such. My faith in this is somewhat tarnished by the fact that every concrete proposal for using it that I've seen seems to be broken by design, which means that chances of anyone using it correctly are vanishingly small. Can you tell us how they're broken so we can fix it? Did you read my earlier mails with examples of devices that are shipping right now that violate the various assumptions people trying to create these device class bins are making? I don't believe we should ever use classes of device. We've been down that route, it's a fail in and of itself. We should be using actual data, not assumed data based on some other data. Absolutely agree, but I don't see how a server requesting and then getting a header is rocket sceince The rocket science lies in deciding what to do with the information. Ugh, I wrote 'rocket science'. Sorry. Especially if the current solution is to connect to some massive device database to query potential points of reference and then act accordingly. Which is just as broken, yes. We've run into problems with the breakage of this database a good bit at Mozilla. Cool so we agree databases are a bad solution and we should aim for better :) I can see your point, but there isn't any impact for users unless the author has opted in and requested headers. Right? The defaults are server gets no headers. Put it another way - how can an author tailor things for a user if the user isn't able to report anything to the server? I didn't say the user shouldn't report anything. I said that the particular things people have asked to be reported so far (screen size, device class) are broken by design. Absolutely agree on device class. I don't understand why screen-size is broken. Report back the maximum
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On 7 Feb 2012, at 20:19, Boris Zbarsky wrote: On 2/7/12 2:52 PM, Matthew Wilcox wrote: Reporting more information about the user's hardware and software to the server allows better fingerprinting and hence tracking. See https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy and similar resources for details. Agreed. But this already happens. And browsers are working on mitigating the ways it already happens. Which means they're reluctant to add new fingerprinting surface. Fair enough. This then becomes a cost/benefit issue. But there's nothing to stop this working if the user's default is an opt out and a prompt is given to allow. In exactly the same way that things currently work for geo-location data. Right? Your point is the user must be able to opt in and out, as they might be turning off JS (which, frankly, how many non-webnerd people do?) Just wait until UAs start shipping with JS disabled for certain domains by default, just like they're already shipping with other capabilities turned on or off with certain domains by default. I browse with NoScript and regularly come across people that haven't coded site's responsibly (it drives me nuts). While I applaud this notion because it'll bring more attention to the issue - i highly doubt it'll have any impact on the larger spectrum of sites. JS is now relied on and if certain UA's deliver a broken web-page to users, the users are just going to blame the software, not the website. Why? Because the site works in every *other* browser, including their old ones... So you're saying the problem isn't the tech but the user control? Can we not give that to them? I'm saying that the _default_ behavior should ideally be as user-friendly as possible. That includes user privacy concerns. Absolutely agree. I'm all for this being disabled by default and opted-in as servers request. Or opted in via a user setting in the UA. There can be additional knobs to enable more privacy features, of course, but a lot of what goes on in the privacy space on the web right now basically depends on user ignorance about the information websites are getting out of them. When I actually describe the underlying technology to non-technical users, they're almost uniformly horrified… They should be. But at the same time a hell of a lot of people have read that FaceBook watches their every move, and yet happily continue to use it. Users don't weigh the issue in the same way we do. Point taken. Though it irks me no end that various technologies get canned because of how inept people can mis-use them. I'd rather see those inept people shoot themselves in the foot and pay the price. The problem is that the price ends up being paid by someone else. Classic example of externalities... If we could make people fully internalize the consequences of their own incompetence, a lot of things would ure be easier! Agreed! It's still my inclination to default to more permissive things though. If people build poor sites, users stop going, the site fails, and either the author learns (I hope) or switches to a job with less requirement on skill level. It's like in business - if you're not providing a decent product, you don't survive. The government doesn't just disallow people from making rubbish with the resources they have. Did you read my earlier mails with examples of devices that are shipping right now that violate the various assumptions people trying to create these device class bins are making? I don't believe we should ever use classes of device. We've been down that route, it's a fail in and of itself. We should be using actual data, not assumed data based on some other data. OK, good. We agree on that. :) Absolutely agree on device class. I don't understand why screen-size is broken. Because half the people asking for it explicitly say they plan to use it as a proxy for other device characteristics. It's not broken per se, of course, just the way people plan to use it. In that case I completely agree. But the answer is educate them to test the right thing. The *only* reason they say that they'll use it that way right now is because that's what they *have* to do to guess the information. Classic case being CSS media queries, where screen size is a proxy for bandwidth and device processing power. It's a mentality they're in because there is no other solution. Let's provide one. My point is that we should perhaps be thinking about how to make things work when these device characteristics change while a page is loaded. Headers do NOT allow you to handle that, for obvious reasons. Ah, loaded as in mid-stream? That's a problem too, but a small one as you note. I was thinking as in between when onload fires and when onunload fires. For some web pages, this time is typically measured in weeks for me (my web-based RSS reader, for example
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On 7 February 2012 20:05, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Matthew Wilcox m...@matthewwilcox.com schrieb am Tue, 7 Feb 2012 19:38:31 +: Can we not turn this into an option in the same way browsers handle requests to get the users location? With configuration too? Allow browsers to see my: screen size That would be yet another way to push “This web site was designed for 800x600, 16 colors, IE 5.5 or later.” – only with the added “feature” of “sucks to be you, get a bigger screen, this content will not display”. UA sniffing, now even worse! Oh, I would certainly be mad. I tire of this viewpoint. Of course it can be used that way. There isn't a technology in existance that can't be mis-used. Does that mean it's a bad idea to try to solve problems with new technology? connection speed This is an interesting case – but today well handled by minimal sites. OkCupid, Twitter, Wikipedia all have well-known minimal alternatives that can be used when on a bandwith-constrained connection. Often, they are arguably better (not full of ads etc.). Handled how? By minimal sites is not an answer, that's a design approach consisting of bring everything down to the lowest common denominator if you use it for one site, or an extension of just throw up a plain-text version if you supply it as a separate URL. The point of responsive designs is to allow one URL to work well on multiple un-known devices whose characteristics vary enormously. The screen can have a ten fold difference in width and a greater difference in processing power and network connectivity. One of the main issue in this arena is how to adapt images, because you don't want to send big images to small devices. So, how do you see this particular problem as already solved? Please - myself and a few dozen other people who've been at this for the last year would like to know - how do we serve a small image to small devices and a big one to large devices? Reliably? Without the flaws of all the existing attempted solutions, which are well documented elsewhere? http://adaptive-images.com http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/ http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ etc PS: UA sniffing and dedicated 'mobile' site's are expressly not the answer. Since that type of request is not narrowly constrained to specific circumstances (e.g. location-based services), there is a possibility for this to become very annoying. Externalizing the inability to provide content that works across multiple devices is a very easy cop-out for developers. I for one advocate control at the UA level (like with CSS media queries) so there won't be yet another UA string nightmare. I would hate another UA string nightmare too. Hence why I want headers. Explicit, direct, non-assumed reporting of actual, current properties. Without guessing. Also, I am writing this on a laptop via a throttled mobile connection. It'd be nice if sites had the capability to adapt to that throttle then wouldn't it... -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
I think somehow lines are getting crossed and misunderstandings are happening. For what it's worth, everyone seems to be getting hung up on screen size. It's only an example. My point is that the server ought to be able to ask the client for data about *any given property* and if the client is capable it should send a header back. Which allows the server to then do whatever it needs with the information. Screen size is one example. Bandwidth is another. It's the *communication of capabilities* that interests me at this point, The allowing of an interrogation of possibliities and adaptive responses. Whether screen-size is a good idea or not comes after. And, screen size is useful when understood to mean CSS Pixels. Because that's what a browser renders. If a device has a screen 1900px CSS px wide, you know you never need send anything larger. On 7 February 2012 20:24, Charles Pritchard ch...@jumis.com wrote: On 2/7/2012 11:52 AM, Matthew Wilcox wrote: On 7 February 2012 17:59, Boris Zbarskybzbar...@mit.edu wrote: On 2/7/12 12:32 PM, Matthew Wilcox wrote: In what circumstances might this cause breakages? Whenever the server developer makes dumb assumptions. Which they do all the time. _All_ the time. And how could it possibly lock out any devices? See my earlier example of a desktop-class touchscreen system that's shipping right now. Every single concrete proposal I've seen so far in this thread would lock it out of actually using its touch capabilities on sites that would support such capabilities fine on other devices. I don't think I have enough knowledge of the case in point to argue either way, but I'm confused how this would be the case at the moment. We already see some frustrating lockout with websites that detect mobile user agents. They forward the agent to their special mobile website, where they will often popup an alert (Please download our APP!!!) every single time you visit the page. Their mobile site is frequently crippled, limited to only a few options, and the mobile browser is often capable of viewing the full desktop site at a reasonable screen width. Now, as sites mature, they have figured out to include a Desktop Version toggle, which is a big help. It's still frustrating that there are a few steps in between. These sites make an assumption, that the screen size has something to do with device capability. The screen size has to do with how much information the viewer has decided to consume at one time. I'm frequently using browser zoom (though I use OS zoom as well), and I don't need to be forwarded to the mobile site while I'm browsing on my desktop just because I'm not wearing my glasses. That said, I do try to work with my applications so that the mobile interface is an interface that I would like to use on my desktop when I'm zoomed in. That middle ground works well for me. Now obviously it's also good for the web in various ways, if people use the information correctly and such. My faith in this is somewhat tarnished by the fact that every concrete proposal for using it that I've seen seems to be broken by design, which means that chances of anyone using it correctly are vanishingly small. Can you tell us how they're broken so we can fix it? Did you read my earlier mails with examples of devices that are shipping right now that violate the various assumptions people trying to create these device class bins are making? I don't believe we should ever use classes of device. We've been down that route, it's a fail in and of itself. We should be using actual data, not assumed data based on some other data. We have abstract means of accessibility. WCAG2 explores that. We have classes of how data is accessed. It should be accessible from a keyboard only device. With touch screens, the world has been exploring more, the concept of accessible via pointer only (though virtual keyboards help). Keep in mind that keyboard and pointer are also two abstractions, not physical objects. There's a third class of accessibility, and that's programmatic access. Ensuring that the DOM has sufficient information that third-party software can use. This is frequently used for eyes-free interfaces, but it's handy for many other targets. There's no assumption of a screen being in place, nor an assumption of any particular physical interface. Especially if the current solution is to connect to some massive device database to query potential points of reference and then act accordingly. Which is just as broken, yes. We've run into problems with the breakage of this database a good bit at Mozilla. Cool so we agree databases are a bad solution and we should aim for better :) Databases are a practical solution for special situations, such as Boris brought up, targeting old and somewhat broken browser implementations. This part of the thread reminds me of the other thing we did
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Yes, you're getting the point I'm trying to make :D However, there most certainly IS a use case for screen size. The designers would kill me if I served up images that had to be up-sampled to fit the device width. And I'd kill them if I had to send an image 6 times larger than needed just to cater for a possibliity that the browser may end up six times larger than it is now. It's not purely about information adaption, there is visual design consideration that is as paramount as any other argument. If a website looks janky, the client (as in the web development agency's client) isn't going to pay for it. On 7 February 2012 21:19, Charles Pritchard ch...@jumis.com wrote: On 2/7/2012 1:14 PM, Matthew Wilcox wrote: Also, I am writing this on a laptop via a throttled mobile connection. It'd be nice if sites had the capability to adapt to that throttle then wouldn't it... As I read through this thread -- all of these use cases are about bandwidth. a) Images are too big. b) Too many javascript files. c) Too much html content. The proposed fix: a) Send a display size header, have the server do magick. That doesn't seem to be the right approach. Let me know if I've got that right / wrong. I'm fine with sending a bandwidth-request header. Something to say: hey you, I'm on a metered connection, don't waste my time. Or just, hey, this connection is slow, give me a hand here. That one directly addresses the issue. On the server-side, I can decide if I want to serve downsampled images, lesser content or otherwise repackage my javascript. Nothing to do with viewport sizes. -Charles
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
The server can not rely on client side *anything* with resource negotiation. This is because clients now pre-fetch resources; as soon as the node exists the resource is requested - before any script has had a chance to run or cookies have been set. It's a tripping point that Filament Group have written about as well as myself. I agree that headers are expensive. But are they expensive compared to a few hundred kilobytes of saved bandwidth because we were able to successfully negotiate content? That's the thing people keep seeming to miss. Also, as indicated, with SPDY this is much much less of a problem than for HTTP. More to the point I thin it is clear that developers want to know how to adapt their content to the user's device Absolutely, which is what this is about. There are two use cases - one is client side and one is server side. They seem to answer the same equation but they do not. We need both, and we can't do *reliable* sever adaption without *reliable* client feature-set reporting. Which we can't get any way we try right now, and there are many approaches tried - JS, cookies, and UA sniffing. None are bullet-proof, and all are merely ways of attempting to *Guess* what a browser header could explicitly tell us. Which is why headers are wanted. To be honest I think this is more a browser thing than anything. I don't see any problem with browsers behaving exactly as they do now, but listening out for a server response header that in turn requests the browser to append certain headers with all requests to the domain. I.e., 1) client asks for spdy://website.com 2) server responds with content and adds a request bandwidth device screen size header 3) client then appends these headers to all future requests on the domain. 4) server can push any amended content from 2) over SPDY without another request (because SPDY can). This way there are no additional overheads unless the server has requested them specifically. -Matt On 6 February 2012 15:38, Charles McCathieNevile cha...@opera.com wrote: On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: I've asked Bruce Lawson (one of the Opera boys) about this, and it's not likely to happen with HTTP. However, SPDY compresses headers as well as multiplexes, and it's a much more realistic request to get useful headers sent over a SPDY connection than it is over HTTP. As for how useful it is - it's very very useful. Traditionally I don't think the requirement to adapt content assets to device capability has been that important, because other methods were available (including the god-awful mess of the UA string). That's going to be less and less useful as the variety of devices continues to balloon and the UA string becomes less and less sane. We need the server to know about the device. We need headers. I'm pretty sensitive to Henri's argument that it's easy to add headers we think will be useful, when they really won't. They are still a pretty expensive part of the transaction, especially for mobiles. If you want them anyway, you might like to look at the Device Description Repository work W3C did, building on the lessons learned from doing CC/PP, UAProf, WURFL, because the mobile web [had/was about to] reached the point where this capability was really important. More to the point I thin it is clear that developers want to know how to adapt their content to the user's device (rather than trying to adapt the user to buy the device they coded for which I think many people here would agree is a really bad thing to encourage). There is also the approach of knowing what capabilities you have from within the page itself. Again there is a long history of this, including media queries, the generally loathed hasFeature in DOM and the more common if (navigator.something) approach that is widely used instead, and so on. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
I disagree. Screen size is at times *exactly* what is needed, as it *is* constant throughout the experience. *Viewport* size is what we shouldn't be using. I've ran up against this with Adaptive Images ( http://adaptive-images.com ) - which is all about the use case of supplying appropriate images to given devices. The problem with using viewport instead of device size is client-side caching. It completely breaks things. As follows: 1) The user requests the site with a viewport at less than the device screen size. 2) The user browses around for a bit on a few pages. 3) The user maximises their browser. 4) All of the images now in the browser cache are too small. How does the client know to re-request all those pre-cached images, without making an arduous manual JS-reliant cache manifest? Or without turning off caching entirely? The solution is to send an image that is as large as the device will ever need, not for the current viewport. Yes, this isn't ideal, but it solves the problem and it solves it very well for small devices whilst maintaining client-side caching. There's very little difference in file weight between an image 320px wide and one 480px wide, so the overhead of supporting landscape even if you're currently only at portrait isn't anywhere near as great as un-negotiated content. Nor does it require new HTTP requests on orientation change, which would be a terrible experience whereby the page that WAS readable suddenly ends up re-flowing and re-loading assets just because you've increased the window size. On 6 February 2012 16:00, Boris Zbarsky bzbar...@mit.edu wrote: On 2/6/12 10:52 AM, Matthew Wilcox wrote: 1) client asks for spdy://website.com 2) server responds with content and adds a request bandwidth device screen size header Again, the screen size is not invariant during the lifetime of a page. We should not be encouraging people to think that it is -Boris
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Scripting on the client side for the purposes of content negotiation *does not work* Please, understand this. Because browsers pre-fetch as soon as a node is created there can be no client-side solution to this issue with the current HTML/JS specifications and browser behaviour. The image linked in the HTML is *always* requested, and it is requested before the client can do a damned thing about it. On 6 Feb 2012, at 20:03, Charles Pritchard wrote: On Feb 6, 2012, at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky bzbar...@mit.edu wrote: That really depends on what the application is doing. Depending on input capabilities, you may want to have multiple pages instead of a single page for some sort of configuration setup, for example. Whether to use monolithic forms or paginated wizards is a presentation thing Not on the HTML level. Not if you want to allow useful non-scripted semantic submission of partially-filled-in info in the paginated case. that need not even have anything to do with HTTP. You can fetch half the monolithic form and fetch the rest when the user has filled in most of former half. Not without script. I really didn't like the consequences of server-side scripting to manage dependencies. It was always more work than simply doing the scripting in the client side. It was more prone to error. It let our coders get away with less rugged design. I'm in the responsive and universal design camp. I'm in the accessibility camp. At present, it does require scripting. I'm building web apps, so, scripting comes with that territory. It seems to me like these folk are looking for iframe defer and style defer and some sort of media selector for the network information API, to minimize bandwidth on metered connections without needing to use scripting to do that work. I'm interested in seeing a solution here. I do not think server-side management is the right one. -Charles
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On 2/6/12 1:55 PM, Irakli Nadareishvili wrote: Many thanks to everybody who has responded and for a lively and a productive discussion! Quick clarification: the proposal is to include *device* capabilities in the HTTP headers, so when we say screen width and height we mean device screen width and height which is constant Again, it's not constant in the terms that the page sees, which are CSS pixels, not device pixels. Media queries and explicit widths make this statement false, in a practical way. We adjust for physical pixels quite happily by specifying a width on the image. This is done routinely in all responsive designs simply by virtu of the images having a width of 100%. They're then down sampled into physical pixels even though CSS is using CSS pixels.
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky bzbar...@mit.edu wrote: Again, it's not constant in the terms that the page sees, which are CSS pixels, not device pixels. We're discussing HTTP here, so the content might just as well be raster bitmaps. Are we? Why, what makes HTTP the relevant factor? SPDY is the future and already supported in two major browsers., As it compresses headers and multiplexes, I don't see the issue. Multiple and variable screen dimensions are quite common (in special for projection). That means a request for every screen the resource may be. For legacy HTTP servers that don't support the new and complicated If-Different-For-Device header that would have to be added would serve the same content once for every screen. No, it means we as a standards body define which gets sent. The sensible thing is to send the maximum screen size in use on the device. So you have UAs sending extra headers with every request, making extra requests with even more extra headers in the fairly common case of variable screen dimensions (multiple screens) and either extra response headers for servers that use the feature (perfectly acceptable) and double round-trip lag (probably terrible) while the UA waits for the extra response header to check if there are alternative versions of the resource for differently sized screens and fetches the alternative version if there is one, or redundant fetching of *all* resources in proportion to the number of possible screen dimensions (assuming the best case of screen dimension being the only variable). Again, read the proposition I mentioned and you'll find non of this is true. Extra headers would only be sent by the browser if the browser received a request for the client to send those headers.
Re: [whatwg] Requests for new elements for comments
What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? On 26 January 2012 13:57, Bjartur Thorlacius svartma...@gmail.com wrote: On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson i...@hixie.ch wrote: Actually, they are remarkably similar. I think it's anachronistic to consider that the utterances of the site owner are in some way distinct from the utterances of the site readers. While I do agree with you (for a change), identifying authors of articles is undeniably useful. First-posters in a thread or syndication may be styled differently from other posters, articles by authors of outer articles may be emphasized in some way, articles by certain authors may be omit, etc. I find no algorithm for identifying authors of articles in the spec. Should the value of the first href attribute in a footer be assumed to identify the author? That seems bound to break, early and often. -- -,Bjartur
Re: [whatwg] Requests for new elements for comments
Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Any time you do this the information will have been pulled through a CMS, so it's trivial to have a class appended to the article. When would you want this as pure HTML that's not been parsed by some form of CMS? On 26 January 2012 21:43, Matthew Wilcox elven...@gmail.com wrote: On 26 Jan 2012, at 20:47, Bjartur Thorlacius wrote: Þann fim 26.jan 2012 14:48, skrifaði Matthew Wilcox: What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? As in article class=asdf lolcats author-bjar...@spam.la? Because then the class would contain content. Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Any time you do this the information will have been pulled through a CMS, so it's trivial to have a class appended to the article. When would you want this as pure HTML that's not been parsed by some form of CMS? That would depend on a stylesheet containing the identifier of every poster on every page. Generating such stylesheets from content already marked up in a page in a nonstandard fashion seems hackish at best, and harmful to usability at worst. The situation only gets worse when you consider the different stylistic needs of various media. I might want the whole footer rendered to the relatively large desktop screen of mine, but omit everything but authors' name or identity on my handheld screen. Address, for example, should be hidden behind a menu button and the authors name displayed tersely. The best solution I can think of is stating normatively that hCard footers describe authors of the respected article or document. hCard does not, AFAIK, provide means to state URIs of authors, but indirect identification using email addresses should suffice. !DOCTYPE html titleExample of Semantically Marking up Authors of Documents/title article h1An Article Written by Bjartur/h1 pThis article was written to demonstrate how authorship might be marked up. I sure hope it's valid!/p footer class=hcard a class=fn email href=mailto:bjar...@spam.la;Bjartur Thorlacius/a /footer /article
Re: [whatwg] add html-attribute for responsive images
Please see responses inline:
On 24 January 2012 23:26, Ian Hickson i...@hixie.ch wrote:
On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
As we now have the possibility of creating fluid and responsive layouts
in several ways we have a problem with images.
There's currently no good feature to implement something like responsive
images which adapt to the different device-resolutions. We only can
implement one image with one resolution scaling-up and down.
You can do adaptive sites using media queries.
!-- HTML --
h1My Site/h1
// CSS
@media (min-width: 320px and max-width: 640px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
}
@media (min-width: 640px and max-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
}
@media (min-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
}
This is of no use to content images - which are the real problem. CSS
supplied images are not an issue.
On Tue, 30 Aug 2011, Karl Dubost wrote:
It is easy to do right now with background images, but not at all for
images in img/ element.
What's the use case for doing it for images in img elements? Typically
img elements are for content images, where you don't usually want to
adapt anything.
Sorry, you couldn't be more wrong. Content images need to adapt because of
the performance problems with mobile. Huge effort has been expended in the
community to answer this problem - mobiles should not be delivered the same
sized images as desktop, even though the semantic value of the images are
the same. What we are talking here is device-appropriate re-scaled versions
of the same image. This saves bandwidth and allows phones with weak
hardware to perform acceptably. For more on the issue please read
http://adaptive-images.com,
http://24ways.org/2011/adaptive-images-for-responsive-designs,
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/, or
http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/to
name but a few recent in-depth articles on exactly this requirement.
Or to look at the extreme hoops we have to jump through for a client-side
solution read
http://24ways.org/2011/adaptive-images-for-responsive-designs-again - it is
not pretty.
On Tue, 30 Aug 2011, Karl Dubost wrote:
And as I explained elsewhere it is not a question of high/low-resolution
only, but about interaction contexts. Different images for different
surface sizes.
Desktop: Show a full photo of Anne van Kesteren riding on a plane
1024*250 px
Tablet: Show the photo a closer shot of the plane (cowboy frame)
400*150 px
Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
I don't understand the use case. For something like a user profile icon
surely it would be rather bad UI to use a different icon on different
devices. I presume you don't mean a profile icon though, since 1024x250 is
a bit excessive for an icon these days, and I'm not aware of any site that
lets users pick different icons for different size contexts.
With retina displays, don't be surprised to see icons around this size very
soon.
On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles (Click here to go to the next
page / page 4) and long search results show clear demand.
I don't think that really works. You wouldn't want to get different
results if I started with a small window vs starting with a big window and
narrowing it. It should adapt in realtime.
By re-requesting image resources after re-scale? That's not performant. But
I do agree that it'd be nicer to getreal-time resource re-requests, if only
the penalty didn't involve page layout jumps. The fact os, it's rare anyone
resizes the browser. The adaptive image agenda is mostly about supporting
massively differing viewport sizes and device configurations. Dynamic
rescaling is a side-agenda.
On Tue, 6 Sep 2011, Ashley Sheridan wrote:
Yes, but the point is, the alternative images you may want to display
for visitors on a smaller screen/resolution could be completely
different from the original image (cropped shot not showing all the
detail, etc).
Note that resolution and number of pixels on the screen are orthogonal
issues. Also, note that the number of pixels on the screen is irrelevant,
it's the number of pixels on the viewport that matters.
Yes and no. It depends on how the image request happens. For example, AI
(linked above) cares only about the number of pixels on the screen. Why?
Because given HTML at the moment you can't re-request an image when you
grow the window - meaning if you start
Re: [whatwg] add html-attribute for responsive images
Ugh, my Gmail keeps sending mail from the wrong address, let me try again: ... In fact, please just read the blog post Bruce Lawson (Opera Software) made summarising the last few months of effort on this, and his proposal for a mark-up level solution (which I'm in broad support of, though there are a lot of knotty issues with any potential solution - as can be seen by the volume of blog-posts, comments, and articles on the topic): http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/ ... I should add that relying on mobile-networks compressing images is not a good enough solution either. Firstly, they don't always. Secondly, this is about performance and device capability not mobile network behaviour. Personally I think media should respond to detected connection speed and/or device capabilities. That involves equipping HTML with the ability to detect those things which is a big ask. But, I feel, very worth while in terms of future-proofing. I'm all for headers being sent with all HTTP requests to inform the server of device details - allowing the server to choose appropriately. But, we also need a mark-up level solution. They're not the same problem though superficially they appear similar. On 25 January 2012 13:42, David Goss dvdg...@gmail.com wrote: On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images in img elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them. On Wed, 31 Aug 2011, Bjartur Thorlacius wrote: Bottom (top?) line: User agents should negotiate an appropriate message-body size using HTTP. Sending an accept-size (or some such) could solve both the problem of high resolution photography and lengthy documents. The amount of split articles (Click here to go to the next page / page 4) and long search results show clear demand. I don't think that really works. You wouldn't want to get different results if I started with a small window vs starting with a big window and narrowing it. It should adapt in realtime. I agree: this needs to be done in markup, not on the server with headers. Not that users resize their browsers all that much (except orientation changes on phones and tablets). But, yeah. Note that resolution and number of pixels on the screen are orthogonal issues. Also, note that the number of pixels on the screen is irrelevant, it's the number of pixels on the viewport that matters. My phone has a far higher resolution than my TV, but has the same number of pixels. My phone also has a higher resolution than my desktop, but windows on my desktop typically have far more pixels. You're right - all pixels are not equal. The solution I'm going to propose involves media queries, so things like device-pixel-ratio can be used to address that issue. I'm proposing this (adapted from Bruce Lawson's picture idea, and similar to how the video element works): adaptiveimg img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool source src=sweater-medium.jpg media=(min-width: 300px) and (max-width: 450px) source src=sweater-large.jpg media=(min-width: 451px) and (max-width: 600px) source src=sweater-huge.jpg media=(min-width: 601px) /adaptiveimg Yep, another new element: adaptiveimg. It doesn't have any attributes of its own (except the standard ones). It must contain one img element, which the author will furnish with an alt attribute and whatever else as
Re: [whatwg] add html-attribute for responsive images
It's also worth noting another use case for this being in mark-up and not
just server-negotiated rescaling of a single image:
Imagine a profile photo on an About page. At large sizes you want to use a
full body shot, at smaller sizes you need to retain what's important but no
longer clear at small scales: a recognisable face - so you substiture a
head and shoulders shot.
That's a strong use case where the semantic meaning of the content is the
same but requires a different resource to be properly conveyed at differing
scales.
On 25 January 2012 15:27, Markus Ernst derer...@gmx.ch wrote:
Am 25.01.2012 15:07 schrieb Matthew Wilcox:
In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):
http://www.brucelawson.co.uk/**2011/notes-on-adaptive-images-**yet-again/http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/
I would like to propose a use case different from the ones in this
blog-post: Scaled images.
The more physical screen densities improve, the less image pixels actually
correspond to device pixels, and thus scaling images will be less a
problem. E.g., designers might want to define an image size in em units
rather than in px, so it keeps its relation to the text size.
This use case requires a negotiation based on the dimensions of the image
element rather than the dimensions of the media. It would be nice if a
solution to the responsive images problem would address this use case, too.
AFAICS this would require a more general syntax for the conditions.
On 25 January 2012 13:42, David Gossdvdg...@gmail.com wrote:
I'm proposing this (adapted from Bruce Lawson'spicture idea, and
similar
to how thevideo element works):
adaptiveimg
img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool
source src=sweater-medium.jpg media=(min-width: 300px) and
(max-width: 450px)
source src=sweater-large.jpg media=(min-width: 451px) and
(max-width: 600px)
source src=sweater-huge.jpg media=(min-width: 601px)
/adaptiveimg
If the introduction of a new element is an option, it could also be the
other way around, as image maps work:
img src=default.gif srclist=mySrcList id=myImg alt=My responsive
image style=width:5em;height:auto
srclist id=mySrcList
source src=low.gif cond=[condition]
source src=high.gif cond=[condition]
/srclist
To address my above use case, I replaced the media attribute with a more
general cond attibute, which can take a condition with a selector and a
rule. The selector can be the keyword media or a CSS selector, and the
rule either a min-width and/or max-width declaration, or some statement
about network speed or whatever, such as:
source src=small.gif cond=#myImg{max-width:49px}
source src=medium.gif cond=#myImg{min-width:50px;**max-width:99px}
or:
source src=small.gif cond=#wrapper{max-width:**320px}
or:
source src=small.gif cond=media{max-width:320px}
or:
source src=slow.gif cond=media{network-speed:[**some slow value]}
