Re: [whatwg] Throwing in my support for picture into the mix
2012-05-16 18:01 Europe/Helsinki: Julian Reschke: On 2012-05-16 16:36, Glenn Maynard wrote: On Wed, May 16, 2012 at 9:16 AM, Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de wrote: Actually, the key point is that this is non-conforming to start with: image candidate strings must have at least one descriptor (http://www.whatwg.org/specs/web-apps/current-work/#image-candidate-string). ... My point being that the syntax is fragile unless implementations follow the spec word by word. I know they are supposed to, but the way it's introduced *will* make people split the attribute value by ,. HTML5 parser is also fragile unless implementations follow the spec. It doesn't make much sense to spec anything in HTML5 if you cannot trust the browser vendors to read it. In addition, if some vendor does not follow the spec, it's *very* easy to point that out. This situation is very unlike the old HTML versions that left way too much unspecified and almost any behavior was acceptable by the spec for many corner cases. The spec is pretty clear for the implementors so the only issue should be if content authors can deal with the syntax. Also remember that the current spec tries to make it very clear that the UA is free to choose any of the available images as used no matter what the content author says (however, it does recommend the spec to be followed). -- Mikko
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. It appears not. I tried to join the responsive images CG as just me as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden.
Re: [whatwg] Problems with width/height descriptors in srcset
On 17 May 2012 18:59, Jeremy Keith jer...@adactio.com wrote: I much prefer Tab's suggestion: I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width I'd like to add my support for this - by using a subset of media-queries the UA can still choose the best image, whilst ambiguity is decreased (now is 600w a max or min?) and it has the upshot of being easier for developers to pick up, use and debug. Seems better for pretty much everyone!
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, May 18, 2012 at 6:01 PM, Bruce Lawson bru...@opera.com wrote: On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. It appears not. I tried to join the responsive images CG as just me as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden. I believe that is the case for all participation in the W3C. Unfortunately, I was not able to join a WG as a private invited expert and a different one as a Google representative (in my role as a Google contractor). I think that is a problem at the W3C that they don't allow you to have multiple different forms of representation per person. I even tried with different email addresses and that wasn't allowed either. Silvia.
Re: [whatwg] Problems with width/height descriptors in srcset
Am 17.05.2012 19:48 schrieb Tab Atkins Jr.: On Thu, May 17, 2012 at 10:27 AM, Jeremy Keithjer...@adactio.com wrote: Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Yes, you got it. Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. 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). No, if we're aping the CSS syntax more closely, we should just use CSS units. h1img src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/h1 pimg src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/p Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature?
Re: [whatwg] Features for responsive Web design
Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset.
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 3:16 AM, Markus Ernst derer...@gmx.ch wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). Cheers, Maciej
Re: [whatwg] Bandwidth media queries
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. It's not enough to say it's a hard problem. It's not going to solve itself. If you say media queries can be useful for bandwidth/quality use-cases, you need to actually specify how can they work. I'm trying to show here that MQ model is very problematic, and won't work well *even if UA has perfectly accurate bandwidth information at all times*! MQs are stateless and expected to match the same way globally, and that clashes with stateful and non-uniform nature of caches that should be taken into account. So please specifically address cases I've listed in my previous email. -- regards, Kornel On 18 maj 2012, at 10:52, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for all the feedback everyone. I don't think it's going to stop people trying to do this though; there are already write-ups for doing bandwidth detection in JS to manipulate img assets: http://www.csskarma.com/blog/detecting-for-bandwidth/ Tricky problem. I'm not sure if that was intended to be an answer to my message: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036005.html I don't think that's at decision stage, because nobody has defined what options are there to decide. The options I see are not compelling: 1. let it match actual bandwidth and apply rules according to standard media query logic. This will suck, as the page design will flip and reload whenever wind blows, and cache will be wasted. 2. let it match some average or sticky value of bandwidth according to standard MQ logic. This will suck less, but still it won't make optimal use of cache OR bandwidth, and page may get stuck in suboptimal bandwidth (e.g. you catch WiFi only momentarily and get 3G browser stuck with peak value or vice versa). 3. Violate MQ logic and allow mixed queries on the page (e.g. if browser has cached image while it had high bandwidth, use the image, even if bandwidth has dropped since). That will allow UAs to use best quality images it can and eliminate redundant requests, but will create unpredictable, inconsistent nightmare for designers. That's why I think there needs to be alternative solution parallel to MQs. It's a shame that Respimg mailinglist is dead: http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html -- regards, Kornel Lesi��ski
Re: [whatwg] Features for responsive Web design
On 2012-05-18 12:30, Maciej Stachowiak wrote: On May 18, 2012, at 3:16 AM, Markus Ernstderer...@gmx.ch wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed frompicture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). ...which of course means that it stops being simpler. I think it would be worthwhile to combine elements form both proposals; in particular to avoid the microsyntax and use proper markup instead. Best regards, Julian
Re: [whatwg] Features for responsive Web design
On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account.
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
Am 18.05.2012 13:09 schrieb James Graham: On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account. One use case is manipulating content in a contenteditable area, e.g. in a Rich text editor. A JS-based online editor such as TinyMCE or KTML may want to offer some kind of GUI for alternative sources. I am not sure whether this is a very important use case, as authors of online editors are usually JS experts and capable of writing complex string operations, too; but I assume the use case is at least valid.
Re: [whatwg] Features for responsive Web design
On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If one really wanted to, this could be handled by having .srcset be a list object, etc. Might still be a bit of a pain, of course. -Boris
Re: [whatwg] Problems with width/height descriptors in srcset
On Fri, May 18, 2012 at 2:17 AM, Markus Ernst derer...@gmx.ch wrote: h1img src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/h1 pimg src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/p Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature? It's the same in those two, but it's not really rem - it's the initial font size, just like in Media Queries. (rem is the size of an em on the root element, which depends on style data.) Not really a feature or a bug, just a necessity. ~TJ
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 5:51 AM, Julian Reschke julian.resc...@gmx.dewrote: ...which of course means that it stops being simpler. No, it means nothing of the sort. An API to access this would introduce none of the problems with the multi-element approach; it would be simple and straightforward to do. I think it would be worthwhile to combine elements form both proposals; in particular to avoid the microsyntax and use proper markup instead. 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...) -- Glenn Maynard
[whatwg] Canvas: imageSmoothingEnabled not part of the state stack?
Looking into some of the features recently added to the canvas spec, I noticed that imageSmoothingEnabled wasn't added to the list of attributes saved and restored in the canvas state (in sec. 4.8.11.1.1). This also seems to be the case for the new line dash parameters. Intentional, or oversight? Stephen
Re: [whatwg] Features for responsive Web design
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
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
On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. HTML4's @profile is a whitespace-separated URI list: http://www.w3.org/TR/html4/struct/global.html#adef-profile RDFa's @property and @typeof are whitespace-separated lists of CURIEs: http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax http://www.w3.org/TR/rdfa-core/#s_syntax -- Benjamin Hawkes-Lewis
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 1:54 PM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. HTML4's @profile is a whitespace-separated URI list: http://www.w3.org/TR/html4/struct/global.html#adef-profile RDFa's @property and @typeof are whitespace-separated lists of CURIEs: not only CURIEs, they can also be full URIs. Steph. http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax http://www.w3.org/TR/rdfa-core/#s_syntax -- Benjamin Hawkes-Lewis
Re: [whatwg] Features for responsive Web design
On 18 May 2012 17:29, Matthew Wilcox m...@matthewwilcox.com wrote: 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. 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. There are proposals to deal with the media-query only once to activate a specific page-global profile. It could support both ways: via media attribute in picture or source elements or via a detection made on the head. Anyway, I'll have to re-read the archive of past conversations to be able to formulate a complete proposal. But those efforts anyone of us might take need to be respectfully considered just as srcset has. And not discarded straight away. -- André Luís
Re: [whatwg] Features for responsive Web design
On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: 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 (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. IMHO those are pretty serious drawbacks that limit its functionality, which is much worse than ugly, but gets job done state of srcset. 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. 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. Lamenting picture and accusing WHATWG of wrongdoing is not productive. If you'd like to see picture proposal succeed, then please help fixing its drawbacks. 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. -- regards, Kornel Lesiński
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] Features for responsive Web design
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.
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.
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).
(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.
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.
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.
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.)
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.
I've explained it in more detail previously (using srcset as an example,
but it all applies to min-device-pixel-ratio: MQ as well)
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036051.html
--
regards, Kornel Lesiński
