[whatwg] Features for responsive Web design
Ian Hickson
ian at hixie.ch
Tue Aug 7 12:09:08 PDT 2012
On Tue, 15 May 2012, Matthew Wilcox 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/
The solution described there seems somewhat overly complicated, but the
implicit problem described there is an interesting one: how to avoid
having to give media queries over and over again.
I don't think this is necessarily an issue for responsive images, per se,
since with images there's the extra problem of declaring the pixel density
of the images, and you have to give the max device height and width for
the images, not so much a media query. But it may be worth looking at
whether something along these lines could be done with an extension to CSS
variables.
On Tue, 15 May 2012, Matthew Wilcox wrote:
>
> It addresses pixel density because it uses media queries and they
> address pixel density.
Media queries are a condition on the display, not metadata for the image,
which is what we need here.
> 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.
I looked around, but couldn't find where you set high-density images on
that page. Can you elaborate?
> <!-- 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?
I don't really understand how this would result in different CSS. Surely
you need to change more than just the images used in the various CSS
sheets, so just having a variable for URLs isn't sufficient.
On Tue, 15 May 2012, 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.
I'm happy to consider specific feedback, but at the time in this thread
where this e-mail was sent, We had yet to receive any negative commentary
at all on the mailing list, so this seems a bit vague. :-)
> 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.
Yes, CSS causes many authors great trouble.
On Tue, 15 May 2012, Shane Hudson wrote:
>
> 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?
If the user is providing a single image, it seems like the simplest
solution is to have the user upload a high-res image and have the CMS
down-convert it as appropriate. That's essentially what Google Plus does,
for example, when you provide your profile image: the image is resized for
all the various places where it is used.
A single image isn't enough for most advanced uses though (where different
sizes get subtly, or not so subtly, different images).
On Tue, 15 May 2012, Matthew Wilcox wrote:
>
> 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.
For the presentational aspects, the problem seems like it would be best
kept to the CSS file, and not kept in the HTML file at all. After all, the
whole point of CSS is that you can apply it to an HTML file that doesn't
know about it, and change the look entirely. This is why I think it would
make sense to look into recasting your idea into a CSS-variables-style
mechanism, rather than an HTML one.
On Tue, 15 May 2012, Jason Grigsby wrote:
> On May 15, 2012, at 12:28 AM, Ian Hickson wrote:
> >>
> >> * Example 2: On the Nokia Browser site where it describes the Meego
> >> browser, the Nokia Lumia is show horizontally on wide screens. As the
> >> screen narrows, the Nokia Lumia is then shown vertically and cropped.
> >> Bryan and Stephanie Rieger, the designers of the site, have talked
> >> about how on a wide screen, showing the full phone horizontally
> >> showed the browser best, but on small screens, changing the img to
> >> vertical made more sense because it allowed the reader to still make
> >> out the features of the browser in the image.
> >
> > <img alt="The Nokia Browser for MeeGo can display the BBC site well."
> > src="landscape.png"
> > srcset="vertical-cropped.png 500w">
>
> I don't think srcset adequately addresses this use case. One thing to
> notice about the Nokia site is that the placement of text around the
> image is also changing as the image changes. Decisions are being made
> about whether to float text to the right or have it inline below the
> image.
>
> This is consistent with the idea of content first or content out
> responsive design. Breakpoints aren't determined by device widths, but
> instead by where the layout--which in this case means the image and
> text--start looking awkward. (http://adactio.com/journal/5425/)
>
> The challenge for srcset in this use case is that if the UA selects the
> image automatically, the author will not be able to judge when the
> layout looks awkward because there will be no way to anticipate which
> image the UA will select.
The UA picks the landscape.png image unless the viewport width is 500
pixels or less. This works the same as media queries, which are presumably
what the author is using to change the layout. Why is this a problem?
On Tue, 15 May 2012, Matthew Wilcox wrote:
>
> 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.
As far as I can tell, srcset="" handles both cases. Which case do you
think it doesn't handle?
> 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.
What is it in the spec that leads you to conclude that the user agent can
pick an arbitrary resource? The spec is supposed to be written so as to
make sure the browser picks a predictable image in any particular case,
using an algorithm very similar to media queries.
On Wed, 16 May 2012, Kornel LesiÅ~Dski wrote:
>
> There's very good article about the two cases:
>
> http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/
>
> srcset is not very good for "art-directed" case
Can you elaborate on why? How is it insufficient for that case? The Obama
example in the article above is very much one that I considered
indesigning srcset="", and it seems to work fine.
On Tue, 15 May 2012, Jason Grigsby wrote:
>
> I understand that @srcset is intended to also address art direction. I
> fear that my attempts to explain the art direction need haven't been
> sufficient and thus it seems like @srcset supports it, but really
> doesn't. BUT because I find @srcset confusing, I can't tell if my
> impression is correct or if I just don't get @srcset.
I can believe that the spec is confusing, certainly. If it would help to
have some more examples in the spec of how to use srcset="", I would be
happy to add some -- probably the best way to do that is if you suggested
some real-world cases that you are not sure how to reimplement with
srcset="", and I just went ahead and wrote a section that explained how to
do those cases.
> The key thing I'm trying to wrap my mind around is that I will want to
> make a layout change at a certain viewport width. Say that layout change
> also means that I'm going to go from images that are rectangular to
> thumbnails that are square.
>
> That layout change may happen at 600px. The thumbnails are 100x100. The
> images used above the 600px breakpoint are 300x150.
>
> In the @srcset syntax, I *think* I would end up with something like
> this:
>
> <img src="a.png"
> srcset="a-rectangle.png 300w 150h 1x,
> a-square.png 100w 100h 1x">
You would do:
<img id=a src="a-rectangle.png" srcset="a-square.png 600w" alt=...>
If you wanted to control the img element's dimensions, e.g. to make sure
you didn't have reflow when the image was loaded, you could also add this
bit of CSS:
img#a { width: 300px; height: 150px; }
@media all and (max-width: 600px) {
img#a { width: 100px; height: 100px; }
}
On Tue, 15 May 2012, Tab Atkins Jr. wrote:
>
> Nope, what you want is this:
>
> <img src="a-square.png" srcset="a-rectangle.png 600w">
>
> Use "a-square.png" by default, and "a-rectangle.png" only if the
> window is at least 600px wide.
>
> I agree that the syntax doesn't make this obvious - it's *too* compact,
> so there's no redundant indicators of what the "w" number means.
Other way around; the biggest image goes in src="", and the *w descriptor
gives the maximum width.
On Wed, 16 May 2012, Mikko Rantalainen wrote:
>
> I think that the correct syntax would be
>
> <img src="a-square.png" srcset="a-rectangle.png 2x 600w">
>
> because the author assumes that the image will be rendered as 300x150.
I think the image in this example is supposed to be half the width of the
viewport (that is, the images are all 1x resolution).
> I agree that the @srcset can handle the "art-directed" use case as well,
> but one needs to specify media-query-like value for the "w" parameter
> and then compute the "x" parameter to match the expected size of the
> image. In many cases, the "x" parameter will have a non-integer value.
> Not as simple as most authors would want but I think that's acceptable.
I'm not sure I follow here.
> I think that the "k" parameter for the size in kilobytes should be
> included in the spec. Even if it weren't used for bandwidth responsive
> use by UAs, it could be used for other stuff (for example, computing the
> amount of bytes that the full page still requires and as a result, being
> able to display accurate progress bar for page loading).
The problem is that this kind of metadata gets out of date _really_
quickly, and nobody notices.
On Wed, 16 May 2012, Mikko Rantalainen wrote:
>
> So we have following (if I've understood correctly):
>
> "w": minimum viewport width in CSS pixels for this image
> "h": minimum viewport width in CSS pixels for this image
> "x": the scaling value from CSS pixels to image data pixels
Right.
> I think that's fine. Perhaps allow "ppi" or "dpi" instead of x, too?
What's the use case?
On Wed, 16 May 2012, Jeremy Keith 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.
>
> 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.
I've tried to add this a-rectangle/a-square example to the spec, hopefully
that will help.
On Wed, 16 May 2012, Henri Sivonen wrote:
>
> 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 don't really understand why.
However, once image-set() is more widely used, it may be that this problem
goes away, because srcset="" is basically the same concept.
> (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.)
Yeah.
On Wed, 16 May 2012, PJ McCormick wrote:
>
> 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.
Well, one day to learn a new feature that was only specified the day
before isn't that bad. :-) Hopefully as tutorials come out and explain
things to authors, it'll become easier. I'm sorry I did a bad job making
the spec clear. :-(
> 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.
This is not very actionable feedback, unfortunately. If you have any
concrete suggestions, that would be more helpful. :-)
On Wed, 16 May 2012, Matthew Wilcox wrote:
>
> I'm happier than I was about srcset - but why does the spec assume
> pixels? Or does it?
Viewport dimensions are in CSS pixels, so that's what the spec uses.
> Use case: design breakpoints can and often are based on non-pixel units.
> em's, for example.
'em', when the style sheets aren't loaded (as they are not when the
srcset="" is first being evaluated, typically), is just the same as 16px.
> 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?
Well, pretty much all the other units (except ex) are a direct fixed
multiple of CSS pixels. 1em = 16px, 1in = 96px, etc.
On Wed, 16 May 2012, Matthew Wilcox 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).
Well if you're changing the widths at which the layout significantly
changes, presumably you're also going to need to change the images for
those different layouts as well. So I'm not sure that's really an issue.
Having said that, I wouldn't object to integrating srcset="" with a
mechanism for pre-declared layout switch dimensions if such a mechanism
were to be adopted. It would be relatively easy to add.
Let's start small, though.
On Wed, 16 May 2012, Matthew Wilcox wrote:
>
> 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).
The way srcset="" is designed, it works fine with preloaders.
On Wed, 16 May 2012, Jacob Mather wrote:
>
> Why does the pre-loader matter so much?
On Wed, 16 May 2012, Tab Atkins Jr. wrote:
>
> Because it lets pages load faster.
On Wed, 16 May 2012, Matthew Wilcox wrote:
>
> 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.
Right. It can see the <img> elements before it has fetched any other
resources, including style sheets or scripts.
And bluntly, because user agent implementors have said they won't
implement something that doesn't support preloading (or rather, loading
during look-ahead parsing).
On Wed, 16 May 2012, Jacob Mather wrote:
>
> Basing the selected image off of browser width is inherently backwards.
> The content should be informed by the layout, not by the browser.
I don't disagree, but at the end of the day, if the browser vendors won't
implement something, it doesn't matter how good it is, it's just fiction.
On Wed, 16 May 2012, Jacob Mather wrote:
>
> Consider WordPress Guy who has all of this code embedded, and has to go
> back and update every post in order to change.
Yeah, if you're changing your site's layout such that the main body part
of your page is changing width, then all your <img srcset="">s are going
to need changing... but so will all your images, for that matter -- e.g.
if you're changing your layout from a 400px column to a 600px column,
you'll need to go back to the masters and regenerate new "full-bleed"
images at 600px instead of 400px. It's a lot of work, but I'm not sure
really that the srcset="" part of the work is the big part.
> Consider Left Bar Girl who actually sets the same image on two different
> break points (i.e. big image, small image, and then big image again)
> because after she un-floats the left bar, the larger image is the best
> fit again.
>
> Perhaps that's a use case to put up on the wiki, the whole left bar
> deal.
>
> Why not adopt a better standard that is forward looking to SPDY?
If you can convince the browser vendors to do it, I'm all for it.
On Wed, 16 May 2012, Jacob Mather wrote:
> On Wed, May 16, 2012 at 5:22 PM, Kornel Lesiński wrote:
> > On Wed, 16 May 2012 20:12:19 +0100, Jacob Mather wrote:
> >
> > [...] And finally corner cases can lead to loops:
> >
> > <div style="float:left">
> > <picture>
> > <source media="max-container-width:100px" src="200px-wide-image.png">
> > <source media="min-container-width:100px" src="50px-wide-image.png">
> > </picture>
> > </div>
>
> As I said, I understand that it is a hard problem, but the question is,
> is it the correct problem.
>
> There are plenty of reasons not to do it, but is there any actual reason
> that the approach is less correct than the current proposals?
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
>
> Yes, trading off latency to save bandwidth is definitely an incorrect
> approach. Bandwidth will keep increasing much faster than latency
> decreases (and there are hard physical limits to decreasing latency,
> while bandwidth could go up to infinity).
This is a valid point.
> On high-latency high-bandwidth connections (satellite, 3G/4G) it may
> already be cheaper to download all versions of all images than to wait
> for CSS to be able to select the right ones to load. Solution that
> requires page layout for image loading is a step backwards for
> performance.
That's pretty much why the browser vendors won't implement a solution that
increases latency, yes.
On Fri, 18 May 2012, Silvia Pfeiffer wrote:
>
> Maybe the metrics that we are suggesting for resources can help:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17896
> When measuring bytesReceived, downloadTime, and networkWaitTime for
> resources loaded, it is possible to track available bandwidth and
> latency and thus find out what type of network connection one is on.
> This may help with making decisions?
Can you elaborate on how you would see this working?
On Thu, 17 May 2012, Silvia Pfeiffer wrote:
>
> If it does indeed rely on a rendering issue (like the size of the
> viewport), wouldn't it make more sense to make it a CSS feature? I think
> that would be less confusing and follow better the established
> separation of layout in html, styling(/rendering) in CSS.
I don't really see how this could be made into a CSS feature, but I'm
certainly happy to consider any concrete proposals if you have any.
On Tue, 15 May 2012, Glenn Maynard wrote:
> On Tue, May 15, 2012 at 2:28 AM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > 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 ...
>
> It's tricky, but not necessarily impossible. Brainstorming a bit, it
> could be useful to specify the file size, eg.
>
> <img srcset="
> face-1900-1200 at HQ.jpeg 1900w 1200h 2500000b,
> face-1900-1200 at MQ.jpeg 1900w 1200h 1500000b,
> face-1900-1200 at LQ.jpeg 1900w 1200h 500000b,
> ">
>
> where the images are, say, JPEG q12, q10 and q4. This allows the
> browser to save bandwidth with a much lower quality loss than you'd see
> by using a lower-resolution image.
The problem isn't telling the browser the size, which as you say is
trivial; the problem is defining how the browser is to do anything with
that information.
> The heuristics for figuring out which size to use would be up to
> implementations.
That's a cop-out. We can certainly allow browsers to do whatever they
want, but if we can't give at least give a reasonabel default behaviour,
then the feature is pointless.
> For example, if historical network statistics tell you your connection
> is at best 100k/sec, you probably don't want the HQ image; if you're at
> 3 MB/sec, the HQ one is probably fine.
I don't think _any_ of the networks I use on a regular basis have
characteristics that are that stable. The wifi at home varies from nice
and fast to ridiculously slow based on whether I'm the only one there, or
whether one of my neighbours is trying to use bittorrent to download the
latest version of Ubuntu, or whether someone is using a microwave. My
phone's network bandwidth varies hugely from minute to minute when I am on
a cross-country trip, and even when I am walking around my garden going in
and out of areas where nearby buildings block the 3G coverage.
> It might be that this is too hard a problem to ever work well enough to
> be useful--that is, if you think the QoI will never actually be good
> enough.
Right.
On Wed, 16 May 2012, Daniel Glazman wrote:
> >
> > [srcset]
>
> 1. from the point of view of an editor (I mean a wysiwyg application),
> this is far too complex and painful. With my BlueGriffon hat on,
> please trust me on that. Where is the harmony, the consistency with
> the multi-source video and audio elements? Why should browsers and
> editing tools have to deal with a different mechanism?
Could you elaborate on what it is that is complex and painful? Is it the
data structure, the serialisation, the input UI? Why would media queries
and <source> elements by easier? Is it just that there are different
mechanisms?
> 2. the %w and %h syntax above will clash with the necessary escaping of
> non-URL compliant characters and I think this is a _very_ bad idea.
> All examples I saw include filenames only but these are really URIs !
I encourage you to read the entirety of the e-mail to which you are
responding, and also the spec. The % stuff about which you are commenting
was a strawman proposal that I explained was a bad idea _within the very
e-mail_ to which you are responding.
> 3. for the same reason, because some filesystems allow whitespaces and
> commas and more in filenames, the latter seems to me dangerous and
> certainly a bad idea. I know whitespaces in URIs will be encoded but
> decoding srcset will then imply parsing it to extract URIs before
> unescaping or whitespaces will become a problem. That's really too
> expensive.
The precise parsing rules are mandated by the spec, so I don't think
there's any way for this to be a problem.
> It's much more subjective but I have an extra comment: the proposed
> srcset attribute is absolutely ugly. I think the srcset approach is
> wrong.
It seems pretty neat to me. :-) It's an HTML version of what CSS is doing
with image-set().
On Fri, 18 May 2012, Markus Ernst wrote:
>
> 1. Are there other cases in HTML where an attribute value contains more
> than one URI?
ping="", itemprop="", itemtype="", style="".
> 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.
Could you elaborate on the use case you have in mind here?
On Fri, 18 May 2012, Markus Ernst wrote:
>
> 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.
If there are editor implementors who would benefit from an API to parse
srcset="" for you and expose it in the DOM, please let me know. It would
be relatively easy to add, but I'd rather not add something like that if
there's no concrete need with people who are actually going to use it.
On Fri, 18 May 2012, Andy Davies wrote:
>
> 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 wrote a really long e-mail explaining how I took into account the
hundreds of e-mails in the subject and reached the srcset="" design:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035855.html
> 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 it comes to developing features in a WHATWG spec, I think it's
reasonable that editors of these specs primarily take as input the e-mail
sent to the WHATWG mailing list...
> 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?"
Making a proposal and discussing it on this list is _exactly_ saying "this
is our proposal, this is how we think it solves your problem, what do you
think?". That's exactly what happened.
On Sat, 19 May 2012, Kornel Lesi¨½ski wrote:
>
> Just throwing an idea here:
>
> <img srcset="gravatar?s={grsize}">
>
> <style>
> @breakpoint "grsize":"80";
>
> @media (max-width:320px) {
> @breakpoint "grsize":"40";
> }
> </style>
>
> I'm not sure about using <style>, as it cannot work in external CSS (we
> can't ask UAs to wait). However declaration may need more syntax than
> just <meta> to allow separate groups of breakpoints.
I would be happy to add support for something like this to srcset="" if
this is something that is added to CSS.
[At this point in the threads, there was a lot of meta-discussion about
what various proposals did or did not do. I don't have anything in
particular to say to those e-mails, as they did not include actionable
feedback. In general it is not especially useful to discuss how an idea
came to be or which solution one should have loyalty to; the main things
that will lead to changes in teh specification are discussion of concrete
use cases, and discussions of concrete problems with specific proposals,
especially specific features already in the specification.]
On Tue, 22 May 2012, Markus Ernst wrote:
> Am 18.05.2012 23:19 schrieb Kornel Lesiński:
> > 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.
>
> Maybe the use cases should be solved independent from each other:
> - Use <picture> for the art direction use case.
> - Remove the MQ except the pixel density from @srcset, and make @srcset
> available in both <img> and <source>:
>
> <img src="normal.jpg" alt="" srcset="high.jpg 2x, normal.jpg 1x">
>
> <picture alt="">
> <source src="mobile.jpg"
> srcset="low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x">
> <source src="large.jpg" media="min-width: 600px"
> srcset="large.jpg 1x, large-high.jpg 2x">
> <img src="mobile.jpg">
> </picture>
I don't understand why this is better than:
<img src="large.jpg" alt=""
srcset="low.jpg 600w 0.5x, mobile.jpg 600w 1x, mobile-hd.jpg 600w 2x,
large-high.jpg 2x">
It seems to me that srcset as specified does exactly the same thing, but
more succintly.
On Tue, 15 May 2012, Andy Davies wrote:
>
> Looking at the srcset proposal it appears to be recreating aspects of
> media-queries in a terse less obvious form...
>
> <img src="face-600-200 at 1.jpeg" alt=""
> srcset="face-600-200 at 1.jpeg 600w 200h 1x,
> face-600-200 at 2.jpeg 600w 200h 2x,
> face-icon.png 200w 200h">
>
> We've already got media queries so surelt we should be using them to
> determine which image should be used and if media-queries don't have
> features we need then we should be extending them...
>
> I'd like to see media-queries extended to support bandwidth, svg etc.,
> then we give developers the option to detected features and choose media
> types appropriately.
On Tue, 15 May 2012, Tab Atkins Jr. wrote:
>
> The "600w 200h" bit can be directly translated into a media query - it's
> equivalent to "(max-width: 600px) and (max-height: 200px)". It's
> collapsed into a custom syntax for terseness.
Yeah, it's not really intended to be a reinvention so much as a terse
recasting of the MQ feature.
On Tue, 15 May 2012, Bruce Lawson wrote:
>
> 1) the 600w 200h bit replicates the functionality of the familiar Media
> Queries syntax but in a new unfamiliar microsyntax which many have
> argued is ugly, unintuitive and prone to error
> (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal)
Well I can't speak to "ugly" (it doesn't seem particularly ugly to me),
but I'm happy to consider specific examples of how it is unintuitive and
prone to error. It's hard to fix these problems without knowing exactly
how it is unintuitive.
> 2) The new bit is the descriptors of pixel density (1x 2x etc). This
> isn't "media queried" because the precise mechanism by which one image
> is chosen over the other is left to the UA to decide based upon
> heuristics. Those heuristics may be secret sauces that give a browser a
> competitive advantage over another; they may be based on data the
> browser has accumulated over time (On my current "Bruce's bedroom WiFi"
> I know I have medium network speed but very low latency so I will tend
> to favour images with characteristic X) and so which aren't available to
> query with MQs because MQs are stateless; they may be based upon certain
> characteristics that could conceivably be available to MQs in the future
> (Do I support JS? Am I touch enabled?) but aren't yet.
I expect most UAs will not do any magic here and will just use the density
of the display at the current zoom level.
On Tue, 15 May 2012, Tab Atkins Jr. wrote:
>
> I think this is too much, personally. I'd prefer more verbosity here,
> like:
>
> <img src=foo.jpg srcset="foo-big.jpg min-width:1000px, foo-big at 2.jpg
> min-width:1000px 2x">
>
> Importantly, I think I'd like to be able to use either min or max, but
> @srcset's microsyntax only talks about min sizes. (I got it wrong in my
> previous email.)
I'm not sure I understand how you would order the images if you had a
combination of min and maxes. Do you have a concrete proposal for how it
would work? What problem would it solve that the simpler system doesn't?
On Wed, 16 May 2012, Anselm Hannemann Web Development wrote:
>
> Tab, maybe you think this is a good type to write the syntax but the
> majority of normal web developers are used to use common HTML syntax.
> This is why we proposed the picture element and normal attributes using
> media queries. Of course this means we have lot more to write but at
> least this is intuitive and totally clear as it uses common structure of
> HTML. Do you agree with this? I think it is more important that everyone
> understands the syntax and actually will use it instead of having a
> shorthand code that no one will use...?
Media queries were a new syntax when we came up with it a decade ago. I
don't see why it would be magically better than the more terse syntax
here.
I definitely don't think it's better to ask people to write more verbose
markup than terser markup, if they do the same thing.
On Tue, 15 May 2012, Chris Heilmann wrote:
>
> The fetish for brevity is something I never understood. More
> understandable code is faster to write than cryptic short code.
Short and long is quite orthogonal to clarity, IMHO.
On Wed, 16 May 2012, Kornel LesiÅ~Dski wrote:
>
> 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>
Indeed. It's not at all clear to me that the second is in any way clearer,
either. Or more understandable or intuitive.
(Also, the second doesn't set the right intrinsic dimensions.)
> 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.
Indeed.
On Tue, 15 May 2012, D. Pitchford wrote:
>
> - Build out either proposals to include more sources so each are maxed
> out for all breakpoints, resolutions, etc. which have propagated
> throughout a large website.
>
> - The time has come for a redesign, and based on the new design, all
> breakpoints have changed from 768px to 800px, a 3x resolution has been
> introduced by 'X Company' and add in "X" as an additional workflow
> variable.
>
> As an author, am I to assume that I now need to manually update each and
> every <srcset> or <picture> to align with the new design?
Yes. You'll also have to create new assets (which is a far more difficult
task -- updating the srcset="" attribute can probably be done using a
script that just goes through all the content).
> I dread the day when I have to dig through, possibly hundreds of pages,
> with multiple images per, to update the breakpoints and resolutions.
Well, most images are going to be decorative and thus done in CSS, so I
don't think it'd be that many. I mean, <img> is only really intended for
images that are unique to a page or form part of the actual content,
whereas most images are just the theme, the presentation.
Looking at the example you quoted, but simplifying it to show what it
would look like without the hacks needed just for the transition period:
> <picture alt="...">
> <source src="photo-s.jpg"/>
> <source src="photo-s at 2x.jpg" media="min-device-pixel-ratio:2"/>
> <source src="photo-m.jpg" media="min-width:321px"/>
> <source src="photo-m at 2x.jpg" media="min-width:321px and min-device-pixel-ratio:2"/>
> <source src="photo-l.jpg" media="min-width:641px"/>
> <source src="photo-l at 2x.jpg" media="min-width:641px and min-device-pixel-ratio:2"/>
> <source src="photo-xl.jpg" media="min-width:1281px" />
> <source src="photo-xl at 2x.jpg" media="min-width:1281px and min-device-pixel-ratio:2" />
> <noscript><img src="photo-s.jpg" /></noscript>
> </picture>
This is what this looks like with srcset="":
<img alt="..." src="photo-s.jpg"
srcset="photo-s.jpg 320w, photo-s at 2x.jpg 320w 2x,
photo-m.jpg 640w, photo-m at 2x.jpg 640w 2x,
photo-l.jpg 1280w, photo-l at 2x.jpg 1280w 2x,
photo-xl.jpg 1x, photo-xl at 2x.jpg 2x">
I really don't see in what way srcset="" is less intuitive or more
error-prone. It seems like a significant win to me. (The way you have to
say "1x" for the photo-xl.jpg in this example is a result of trying to
have the <img> fallback to photo-s.jpg rather than photo-xl.jpg; if it was
the latter, you could just omit the latter altogether in the srcset="". In
practice I imagine that's what would be more common since that's what you
would want for fallback in legacy desktop browsers.)
On Wed, 16 May 2012, Chris Heilmann wrote:
> On 16/05/2012 00:23, Kornel Lesiński wrote:
> >
> > 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="315"><param name="movie"
> value="http://www.youtube.com/v/oHg5SJYRHA0?version=3&hl=en_US&rel=0"></param><param
> name="allowFullScreen" value="true"></param><param name="allowscriptaccess"
> value="always"></param><embed
> src="http://www.youtube.com/v/oHg5SJYRHA0?version=3&hl=en_US&rel=0"
> type="application/x-shockwave-flash" width="420" height="315"
> allowscriptaccess="always" allowfullscreen="true"></embed></object>
I don't know that I would use the word "happy".
On Wed, 16 May 2012, Matthew Wilcox wrote:
>
> 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.
1em = 16px before layout. Unfortunately we can't depend on layout, but it
does mean that providing other units doesn't actually provide anything
other than syntactic sugar.
On Wed, 16 May 2012, Tim Kadlec wrote:
>
> The lack of em support is a concern though I understand the
> complications you have brought up.
>
> Using ems for media queries (which in turn dictate layout which in turn
> dictates the image I want to load) is increasingly looking like a much
> wiser decision than using pixels. A perfect example are devices such as
> the Kindle Touch which have a much higher default font size. A real
> world example, and case study, can be found here:
> http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
In practice, the default font size on the Web has to be 16px, or sites
break. I understand that some browsers (fewer and fewer over time) let you
change that or have different defaults, but fundamentally IMHO they're
just broken.
On Wed, 16 May 2012, Odin Hørthe Omdal wrote (in two e-mails):
>
> 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 :-)
Why can't you just do:
<span class="img" data-src="blabla.jpg"></span>
...and then do whatever magic you want from script?
(It's not clear to me what the use case is here, so it's hard to evaluate
these various suggestions against each other.)
On Wed, 16 May 2012, D. Pitchford wrote:
>
> What standards does not do in this situation is remove the actual work
> effort in having to physically update each and every img's 'srcset'
> string with new breakpoints during a redesign, no matter how terse the
> 'srcset' string is.
>
> You can have all the stanadrds in place you can muster to write, but the
> physical work effort is not negated because of a list of guidelines that
> lives in a document that rarely gets followed.
Nah, if you're consistent then it becomes really quite easy to write
scripts to do this. If you're particularly consistent, it can be as easy
as a multifile search-and-replace.
(See also the earlier points in this e-mail about how we can add features
to srcset="" in the future, once we have experience with it being
deployed, and/or once there is a mechanism in place for page-wide media
query variables.)
On Tue, 15 May 2012, Chris Heilmann wrote:
>
> I also wonder what we do with videos? Surely they have the same issues
> and there is no proposal for changing the syntax there.
Videos have different use cases. Different use cases often mean different
solutions.
(Also, honestly, we learnt a lot from <video> and <source>, in particular
that it was possibly a mistake. Just take a look at how complicated the
relevant algorithms are in the spec.)
> I do not like the syntax of this. Yes it is more terse but it smacks of
> the horrible syntax of window.open properties and other comma separated
> visual attributes.
I don't understand what's horrible about comma separated lists. We use
commas to separate things all over the place.
> From a semantic point of view this is a terrible mix of everything -
> something that the picture proposal with multiple sources was not.
I don't understand how the semantics are particularly different. Can you
elaborate on how the difference is more than syntax?
> Let's not forget that this is a new use case - one that might get more
> complex with more UA changes in the future. Maybe we have holographic
> images soon with a X Y and Z position. Shoehorning this into the IMG
> element doesn't make much sense to me.
Why not?
(Also, generally I strongly recommend only fixing problems once they're
real problems, not trying to fix them before they exist.)
[I've skipped a number of e-mails at this point in the thread that just
repeated earlier arguments. If you think I skipped your e-mail and you
don't think your point was answered here, please don't hesitate to e-mail
it again, letting me know that you would definitely like an explicit
reply because you think the point is new.]
On Wed, 16 May 2012, Silvia Pfeiffer wrote:
>
> If that's the case, would it make sense to get rid of the @media
> attribute on <source> elements in <video> and replace it with @srcset?
I think it might make sense to drop media="" (nobody seems to have really
cared much about it), but I don't think it is necessary to replace it with
anything, to be honest. But it's probably not yet time either awy.
On Wed, 16 May 2012, Anselm Hannemann Web Development wrote:
>
> You might remember about my proposal 9 months ago. If not you can see it here: https://gist.github.com/1158855
>
> <img src="http://cdn.url.com/img/myimage_xs.jpg"
> media-xs="(min-device-width:320px and max-device-width:640px)"
> media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"
> media-m="(min-device-width:640px and max-device-width:1024px)"
> media-m-src="http://cdn.url.com/img/myimage_m.jpg"
> media-xl="(min-device-width:1024px)"
> media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg"
> >
>
> <img src="http://cdn.url.com/img/myimage_xs.jpg"
> media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"
> media-m-src="http://cdn.url.com/img/myimage_m.jpg"
> media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg"
> >
>
> This is between the @srclist and the picture-element. It has MQ (which
> are optional imo, of course the browser should have a standard "MQ" (how
> ever this can look like and might feature bandwidth also)) and a
> sourcelist. And it features a html-common usage while being shorthand.
>
> I also believe that if the developers should ever be provided with a
> bandwidth API this could be handled via media-queries.
>
> The first example shows that a developer wants to specifically target
> specific screen sizes with a MQ while in the second it is up to the
> browser which one is used.
>
> At least the normal src="" is thought as fallback behavior for older
> browsers.
I don't understand what problem this solves that srcset="" doesn't solve,
or what problem with srcset="" it solves. It seems to be at most
equivalent (possibly less so; I don't see how it would work with intrinsic
sizing of high-density images), while being more verbose.
On Wed, 16 May 2012, Kornel LesiÅ~Dski wrote:
>
> <picture>
> <source scale="1" src="low-narrow" media="(orientation:portrait)">
> <source scale="2" src="high-narrow" media="(orientation:portrait)">
> <source scale="1" src="low-wide" media="(orientation:landscape)">
> <source scale="2" src="high-wide" media="(orientation:landscape)">
> </picture>
Can you elaborate on the concrete use case for orientation? When would you
want to use a different image if you are on a 640x480 display than a
640x1280 display, say?
I can see wanting to do scrolling in a different direction (e.g. the way
the Google+ tablet app does) but it's not clear to me when this would
affect content images (as opposed to presentation images in CSS).
On Wed, 16 May 2012, Jeremy Keith wrote:
> >
> > 1. How do we enable authors so that they can display different images
> > under different conditions based on art direction?
> >
> > 2. Enabling authors to provide different resolutions of images based
> > on a variety of conditions.
>
> The srcset proposal that has been thrown into the spec looks like a good
> answer for that second use-case but it doesn't attempt to tackle the
> first use-case.
On Tue, 15 May 2012, Tab Atkins Jr. wrote:
>
> Hm, I'm confused. The "NNNw" and "NNNh" parts of the microsyntax are
> precisely intending to solve the (1) case. They're more-or-less
> equivalent to using min-width and min-height Media Queries.
Indeed.
On Wed, 16 May 2012, Aldrik Dunbar wrote:
>
> 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">
> <desc>A 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>
It's not clear to me why that is better than this:
<img title='A painting by Edvard Munch, commonly known as "the scream".'
src="https://upload.wikimedia.org/wikipedia/en/f/f4/The_Scream.jpg"
src-set=="https://upload.wikimedia.org/wikipedia/en/thumb/f/f4/The_Scream.jpg/476px-The_Scream.jpg 476w">
On Wed, 16 May 2012, Anselm Hannemann Web Development wrote:
>
> The good thing on the picture element is that we have the possibility to
> serve other image-crops and with that the meaning could change so we
> could update the alt-attribute in the tag for every source-element. I do
> know this is a very special case but valid: An image displayed for a
> desktop while a monochrome display will get an drawing / shape-image
> instead. This has the very much same meaning but a different content and
> has to have a different description in alt-attribute IMO.
No, quite the contrary. The alt="" attribute is about the image's
_meaning_, so if all the alternative pictures have the same meaning,
they'd all have the same alternative text.
There's a long section on this in the spec that I recommend reading.
On Thu, 17 May 2012, Scott González wrote:
>
> I don't think this should just be about device capability. Users with
> vision problems may opt-in to high contrast mode and you may need to
> load different resources based on this.
This is certainly an interesting use case. This is the first time I've
heard someone suggest that we should give user agents the ability to
switch in different images based on the user's need for higher contrast.
Before we specify such a feature, there are two big questions that need
answering, though:
1. Are any browser vendors interested in implementing such a feature?
2. Have any authors provided such features on their sites today, and
would they want to rely on browsers to do it instead?
On Wed, 16 May 2012, Anselm Hannemann wrote:
>
> I think the WHATWG should respect the W3C with its community groups
> more. Or what are they for?
What do you mean by "respect", in this context?
As far as the HTML spec goes, I take input from anywhere I can find it. I
guarantee a reply to any new actionable feedback regarding HTML sent to
the WHATWG list (and, in fact, usually give a reply even if the feedback
isn't actionable or isn't new). Community Groups (and W3C or IETF working
groups) don't have a special status as far as this work goes.
> I mean we invested many hours of work into the topics and now we have to
> explain and discuss all again (sure with new valid arguments).
A number of people have simply posted links to previous discussions where
topics were discussed or explained, and I read those in their entirety. (I
don't necessarily give direct responses here, because it's rather awkward
to respond to blog posts, forum comments, etc, in an e-mail reply, but if
anyone wants a specific response to anything specific, it's as simple as
asking me to respond or just copying and pasting the relevant passage into
an e-mail to this list.)
> Surely it does. But I think the biggest problem is that the micro-syntax
> is not developer-friendly (for the masses). At least this is my only
> problem with the solution.
I don't really understand what is unfriendly about it. Can you elaborate?
On Wed, 16 May 2012, Jonas Sicking wrote:
>
> However, it seems to me that if a lot of discussion had happened in the
> CG, especially with a lot of expertize there around what authors want,
> then why put a proposal that goes against theirs into the HTML spec and
> announce this on the whatwg list?
Discussions happened in many places. The srcset="" proposal was actually
the result of replying to several dozen e-mails in the WHATWG mailing list.
(I wasn't aware, and indeed am still not aware, of a specific concrete
formal proposal that was rejected; ideas from many proposals on this list,
and proposals cited on this list, were considered and synthesised to form
the srcset="" proposal in the spec.)
> If their proposal wasn't deemed good enough, then the most appropriate
> action would seem to be engage in discussion in that CG and point out
> why their proposal is problematic! Simply reading their input and
> putting a different proposal into the spec is remeniscent of how various
> W3C groups work where they take input on their public list, then discuss
> amongst themselves on a private list and put what they thought was the
> best solution into the spec. That behavior has led to plenty of bad
> specifications and is something we've campaigned heavily against.
> Instead we've requested that all discussions happen on the same list so
> that everyone can participate.
Right, that list is this list. :-)
On Wed, 16 May 2012, Jonas Sicking wrote:
>
> I'm not sure what you think it's a bad suggestion? I would say that the
> CG was more successful in attracting author feedback than WhatWG
> currently is.
Given that I'm currently replying to a thread with over 300 messages on
this single topic, and that's not even the bulk of the e-mails on this
topic (those having received replies over the past few years in earlier
messages), I don't think we've had any difficulty attracting feedback...
(Incidentally, one problem with the CG in this case was that its proposals
were incompatible with requirements from browser vendors. I assume, as a
browser vendor, that you agree that it's pointless for me to spec things
that you're not going to implement. :-) )
On Thu, 17 May 2012, Matthew Wilcox wrote:
>
> 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
Personally I would recomment just collecting use cases and posting them on
this list, that's the simplest way to ensure that I consider all the use
cases when updating the spec.
> 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.
A CG is just a mailing list and a blog, as far as I can tell, same as the
WHATWG. :-) In fact, the WHATWG also has a forum (forums.whatwg.org),
feedback from which gets forwarded to this list. Anyone can post on the
blog, they need but ask (blog.whatwg.org). People can also send feedback
on our Google+ page. If it would help if we posted regular invitations to
discuss specific topics, we could do that -- someone needs to tell us what
topics they want to talk about, though. We deal with thousands of topics
each year, and each discussion spans many months, so it's not clear to me
what topics we should post about. (The topic of responsive images, for
example, started being discussed in earnest a year or two ago -- the most
recent discussions cover only a small part of the whole timeline.)
On Thu, 17 May 2012, Matthew Wilcox wrote:
>
> First off many members of the CG have been working on the adaptive
> images problem for close to a year at this point.
The topic is much older than that. :-)
> 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).
It's not that I wasn't aware that there was a problem, it's that the
problem was still being fully defined.
> The problem of miscommunication and poorly documented
> newcomer-unfriendly channels is not new.
If anyone can help me understand what needs to be said that isn't said:
http://wiki.whatwg.org/wiki/FAQ
...then that would be fantastic. Please e-mail me privately or catch me on
IRC (Hixie on Freenode in #whatwg).
On Thu, 17 May 2012, Matthew Wilcox wrote:
>
> 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?
Assuming you mean this:
http://www.w3.org/community/respimg/common-questions-and-concerns/
...then all the points made on that page were things I considered when
writing the long e-mail on this issue:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035855.html
If there are any specific points there that you think were overlooked,
please do let me know. (As noted earlier, I don't generally give explicit
point/counter-point arguments for things not given on the mailing list,
but that doesn't mean I don't take it into account.)
> 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
There is _always_ doubt. It's not like Web authors are a monolithic
entity with a single opinion. :-) Indeed on the contrary, for any
particular topic there are going to be opinions all over the spectrum.
> 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.
If anyone would like to work with us to get more input from authors in
that way, I'd be happy to work with them to set something up. We haven't
historically had anyone who has wanted to proactively solicit opinions
from Web developers, so this would be great. Please contact me directly if
you'd like to do that.
On Thu, 17 May 2012, Ben Schwarz wrote:
>
> Non announcement _here_ is one thing, sure; but as those aiming to plan,
> test and measure different approaches, it's your role to research other
> developments out side of the WHATWG bubble.
I personally do do that, and was both aware of the respimg CG, and read
much of the respimg materials, and took it into account.
On Mon, 21 May 2012, brenton strine wrote:
>
> However, it still looks like the most upsetting implication of his
> timeline, namely that the WHATWG is prioritizing implementors over
> authors, remains unclarified.
We try to prioritise the needs of users over authors, authors over
implementors, implementors over editors (me), and editors over theory.
However, as a practical matter, implementors have the ultimate veto since
if they don't implement something, neither users nor authors get it.
> 7. Authors react negatively to the addition of 'srcset' in the draft.
> 8. The 'living' draft is not changed and the authors' anger eventually
> fades into hopeless acceptance because once something goes in to the
> draft, it is set in stone forever and for all time.
>
> Ok, so 8 is both hyperbolic and in the future, but a lot of people seem
> to think that this is where we are headed. Personally, I'm not angry
> about this and I'm willing to calmly listen to corrections, I'm just
> trying to wade through all the misinformation here.
Whether something changes in the spec is based entirely on what technical
feedback we receive, primarily driven by use cases and by reports of what
problems a solution has. So far in this thread there has been very little
technical feedback pointing to any specific problems with srcset="", so so
far I haven't removed it (though I have added some non-normative material
as others have suggested; see earlier in this e-mail).
Certainly nothing is set in stone; that's the whole point of a living
standard. However, we do try to minimise churn, so changes generally only
happen when new information comes to light.
On Mon, 21 May 2012, Mathew Marquis wrote:
>
> `srcset` went from an initial proposal to addition to the draft within a
> handful of days, during which time we were told that we hadn't followed
> the proper processes for proposing `picture`, and were lacking for
> proof, citations, and documentation. We were asked to furnish use cases,
> polyfills, a more formal proposal, and proof of developer sentiment on
> their preferred markup pattern. While we we working to provide these,
> `srcset` went from http://junkyard.damowmow.com/507 to a draft based
> largely on conversation in the IRC channel. Speaking for myself, one
> can't help but feel as though we were given a separate set of rules and
> a process of our own.
The IRC discussion (and the URL you cite above) are the symptoms of my
"thinking out loud" while going through all the feedback we've received on
a topic, in this case the hundreds of e-mails over at least four months of
feedback, which itself led directly from the previous time I dealt with
feedback on the topic, which was a reply to a dozen e-mails or so in
January, dealing with feedback going back to August 2011. It's the same
process: people send e-mails to the list with use cases, I read them all
then either respond with requests for more information, or, if there is
enough information, update the spec to handle the use cases. With
complicated topics I do "think out loud" on IRC, but that's not the start
of the process, it's just my sanity-checking things. With high-profile
topics like this where there's a lot of e-mail, it tends to spill over
several days just because there's a lot of e-mail to reply to; when I
reply to just a single short e-mail, it looks more like the IRC discussion
is happening in realtime, but really it's the same thing.
I welcome any input by IRC, of course, but you shouldn't confuse this with
"the process". Insofar as we have any process at all, it's just posting to
the mailing list. This is detailed here in the FAQ:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
On Mon, 21 May 2012, Tab Atkins Jr. wrote:
>
> What happened here is simply that Hixie thought that one syntax (which
> happened to be close to one suggested by someone on the Safari team) was
> better than another syntax (which happened to be suggested by the CG).
A bit of a simplification, but yet, in part that is one of the factors
that contribute to the current design. More importantly, though, srcset
has some technical advantages over a multiple-element solution:
- it's closer to the solution to the similar problem that is being
resolved for CSS, namely image-set().
- it doesn't involve multiple elements. Generally, processing models for
multi-element structures in the DOM are a disproportionate source of
trouble in a wide variety of areas:
- they introduce the need for much more elaborate error handling,
since they have multiple failure modes (what happens if one or
another element is found in another, or if the outer element has an
unexpected inner element?)
- the processing model has to deal with changes more complicated than
just "change" (what if an element is added or removed, or moved?)
- it introduces all kinds of complicated questions once you introduce
shadow trees (what if you bind something with a special child? what
if the shadow tree contains such a child?)
- it introduces complexities in the algorithms to deal with unexpected
text nodes, comment nodes, PIs, etc.
- it introduces some complexity in the parser, because you have to
handle the case where you're only half-way through parsing the
"parent" element when you return to the event loop, with more
children elements to process (when does the processing model
start? what do you expose in the DOM API half-way through? etc).
- it resolves the intrinsic sizing for high-res images issue discussed
earlier in this e-mail.
- it's a lot less verbose.
The lesson we learnt from <video>/<source> isn't that the pattern is an
easy choice. It's that we should avoid it if at all possible. :-)
On Wed, 16 May 2012, Julian Reschke wrote:
>
> - "comma separated" implies you'll need to escape a comma when it
> appears in a URI; this may be a problem when the URI scheme assigns a
> special meaning to the comma (so it doesn't affect HTTP but still...)
This is not an issue with srcset="" as commas cannot appear in URLs in the
way the syntax is designed (every URL is required to be followed by a
space, and the parser does not just do a naive "split on commas").
> - separating URIs from parameters with whitespace implies that the URIs
> are valid (in that they do not contain whitespace themselves); I
> personally have no problem with that, but it should be kept in mind
I don't understand why this would be a problem.
On Thu, 17 May 2012, Ungureanu Dumitru wrote:
>
> Having multiple src's for an image is similar to AJAX for content. Why
> is it a good idea to have a default AJAX for images but not for content,
> beats me.
I don't follow. Can you elaborate?
On Wed, 16 May 2012, Paul Court wrote:
>
> I have joined this list after reading @wilto's a list apart article
> (http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point/)
> and realised it was about time I stopped sitting on the sideline and get
> involved in the debate.
Welcome! (And welcome to anyone else in a similar situation!)
> First, I would like to suggest throwing <img srcset> out the window and
> into a landfill somewhere (It's not even fit for recycling!). This
> reminds me if the recent semi-colon in JavaScript "debate" that erupted
> as a result of @fat's code in the Twitter Bootstrap project - To one or
> two people who are very specialised in their particular area, it seems
> like a non issue - and I think that is the case with the <img srcset>
> syntax. From a browser developer point of view it might be easier to
> implement, but from a "I'm just learning to code" point of view, that
> syntax is bat-shit crazy!
I'm not sure I understand precisely what it is you are criticising here.
Could you elaborate more on what precisely is the problem with srcset=""?
> Second, I'll add my support for the proposed <picture> + <source> tag
> version, as a much more readable implementation, and also shows
> similarity with the <video> tag already in use, so it should be easier
> to pick up.
As I described above, there are unfortunately more concerns here than the
mere aesthetic. :-(
> Finally, wouldn't it be more productive in the long run to define a
> "template" if you will for situations where alternate versions of the
> same "element" are required. Obviously, we already have <video> +
> <source>, perhaps before long <picture> + <source>, and I am sure there
> are others.
We try to address each use case with a dedicated solution that directly
addresses the important problems for that case, rather than have more
generic solutions that solve more cases overall, but each less well.
> (What was the reason for ditching the <object> + <param> tags again?
> because we just seem to be re-implementing them with different names!)
They are still present in HTML, but they handle a different problem. The
closer parallel would be the nesting of <object> elements, which suffers
from its own set of problems and wouldn't really be a good fit here.
On Wed, 16 May 2012, Julian Reschke wrote:
>
> Quick check, do
>
> srcset="a,b"
>
> and
>
> srcset="a, b"
>
> mean the same thing?
The former is equivalent to src="a%2Cb", the second equivalent to
src="a%2C".
> And what about
>
> srcset="a ,b"
>
> ?
This is equivalent to src="a".
On Wed, 16 May 2012, Julian Reschke wrote:
>
> 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 ",".
If implementors are going to ignore the spec, it doesn't matter what the
spec says.
On Fri, 18 May 2012, Mikko Rantalainen wrote:
>
> 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).
Indeed.
On Wed, 16 May 2012, Simon Pieters wrote:
>
> The width/height descriptors in srcset seem to be difficult for people
> to get right, even people who read the spec.
>
> * It's not clear from the syntax that it refers to the viewport size
> rather than the image size.
>
> * It's not clear if it's min-width or max-width.
Short of making the syntax more verbose by explicitly including the words
"max" and "viewport" (and hoping every author speaks English), I don't see
any way to really solve that.
> Also, since the fallback image participates as a candidate, but you
> cannot change its descriptors, you are not free to use any of the images
> as the fallback image. You might either want the narrowest image to be
> the fallback, or the widest image, or one in between, but the syntax
> doesn't allow choice, AFAICT.
That's only a problem if you want to avoid duplicating the name of the
fallback image (in which case it defaults to the image for an
infinite-large viewport at 1x). If you don't mind giving the image for an
infinite viewport at 1x (by just giving the descriptor "1x"), then you
don't have to worry about src="" at all when dealing with srcset="".
> Even the spec seems confused about min-width vs max-width:
>
> "The attribute essentially takes a comma-separated list of URLs each
> with one or more descriptors giving the maximum viewport dimensions and
> pixel density allowed to use the image."
>
> Later:
>
> "If there are any entries in candidates that have an associated width
> that is greater than max width, then remove them,"
>
> The first quote should say "minimum viewport dimensions" to match the
> algorithm. Or vice versa, if the algorithm is wrong.
I had to read that algorithm like three times before I agreed with you. If
anyone has a concrete suggestion for how to rephrase it that is as precise
but less confusing, please let me know.
(Fixed.)
On Wed, 16 May 2012, Jeremy Keith wrote:
>
> If I'm taking a "Mobile First" approach to development, then srcset will
> meet my needs *if* Nw and Nh refer to min-width and min-height.
>
> In this example, I'll just use Nw to keep things simple:
>
> <img src="small.png" srcset="medium.png 600w, large.png 800w">
>
> (Expected behaviour: use small.png unless the viewport is wider than 600
> pixels, in which case use medium.png unless the viewport is wider than
> 800 pixels, in which case use large.png).
To do this you should say:
<img src="small.png" alt="..."
srcset="small.png 600w 1x, medium.png 800w 1x, large.png 1x">
> If, on the other hand, Nw and Nh refer to max-width and max-height, I
> *have to* take a "Desktop First" approach:
>
> <img src="large.png" srcset="medium.png 800w, small.png 600w">
>
> (Expected behaviour: use large.png unless the viewport is narrower than
> 800 pixels, in which case use narrow.png unless the viewport is narrower
> than 600 pixels, in which case use small.png).
Strictly speaking, "narrower-than-or-equal-to", but yes.
> One of the advantages of media queries is that, because they support
> both min- and max- width, they can be used in either use-case: "Mobile
> First" or "Desktop First".
>
> Because the srcset syntax will support *either* min- or max- width (but
> not both), it will therefore favour one case at the expense of the
> either.
I think asymmetry here isn't a big deal, because the axis is itself
asymmetric. The minimum width is 0, the maximum width is infinite. So the
bottom end is bounded bu the top end is not. IMHO this encourages a
processing model that puts the fallback at the top end.
Note that all of this is merely a transitory issue. On the long term, I
expect all UAs will support srcset="" (or its equivalent, if we change to
something else), and we'll be able to make src="" optional.
On Wed, 16 May 2012, Odin Hørthe Omdal wrote:
>
> But making them bigger and more verbose will make them that for every
> single element you're adding in @srcset. Hardly something to sing about.
>
> <img src="a.jpg"
> srcset="abc.png max-width:800,
> bcd.png max-width:200 max-height:200,
> bcd at 2.png max-width:200 max-height:200 density:2">
>
> vs
>
> <img src="a.jpg"
> srcset="abc.png 800w,
> bcd.png 200w 200h,
> bcd at 2.png 200w 200h x2">
Right, this is the tradeoff I'm trying to avoid.
(Also, people seem to like spaces around colons -- see bugs filed on
WebVTT's options, for example -- and then you end up with a parsing
nightmare, where things like "a.png max-width: 200 min-width :100" are
value yet look nothing like what they mean.)
To be fair, I'm not too worried about the syntax being non-obvious at
first blush, because so long as the syntax is mnemonic, it will be pretty
easy to learn. This isn't something like microdata where you're likely to
not have any good way to test it easily, it's more like CSS where you can
test it immediately just by loading your page and resizing your window.
On Mon, 21 May 2012, Simon Pieters wrote:
>
> I propose that we allow the src URL to be specified in srcset, and when
> it is, don't add src as a candidate.
That's essentially what the spec does already, since it drops later
duplicates and adds the src="" last.
> It would be good with a keyword "inf" or "infinity" as a width
> descriptor in this case so you don't need to specify "1x" when you want
> infinity.
A keyword to mean "infinite w, infinite h, 1x" would make sense if it's
going to be common for the src="" to not be that value, but that seems
like a surprising case to me. Why would we have a different default for
modern desktop UAs that support srcset="" than for legacy UAs that don't?
On Wed, 16 May 2012, Markus Ernst wrote:
>
> I read the current spec and huge parts of today's discussions to find
> out how images with multiple sources are intended to behave when
> printed, or when the page is zoomed, but I found no hints. I think some
> words on this might be useful in the spec, regardless of what the final
> syntax will be.
It's essentially up to the browser. The spec says "The user agent may at
any time run the following algorithm to update an img element's image in
order to react to changes in the environment. (User agents are not
required to ever run this algorithm.)".
> When a page is printed (or also converted to PDF or whatever), both "viewport"
> width and pixel ratio change. Are UAs expected to load the appropriate sources
> then? This could result in increased bandwidth, delayed printing, and IMHO a
> disturbed user experience, as the image may differ from the one seen on
> screen. Thus, I suggest to always use the resource actually shown on screen
> for printing.
UAs are already able to massively change the rendering when printing, e.g.
in response to @media print { } rules. So I don't see this as a
particularly new thing.
> On mobile devices, web pages are often zoomed out to fit the viewport width by
> default, the user is supposed to manually zoom in and scroll in order to read
> parts of pages. I understand that the whole thing about responsive design is
> to make this kind of zooming unnecessary, but in practice there will be all
> kinds of partly responsive designs using responsive images.
> Specially in cases where separate sources are given to match device pixel
> densities, zooming might matter, as for a zoomed-out page the low res image
> might be more than sufficient, but after zooming in the higher resolution
> might be appropriate. Which OTOH can disturb the user experience, when the
> images differ.
There's plenty of ways to confuse the user experience, e.g. by having the
<img> change randomly every few seconds. :-)
I think this is something best left up to the browser, personally.
On Wed, 16 May 2012, Matthew Wilcox wrote:
>
> [bandwidth negotiation]
> 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.
Search for "Now I'm not sure what to do about the bandwidth one" in:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035855.html
> 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.
How would you handle:
- The user picks up his laptop and moves it further away from the wifi
hotspot, to somewhere with a lot of packet loss.
- The user goes through a tunnel and his phone has to switch from 4G to
EDGE for a few minutes.
- The user opens the page on day 1, and on day 5 reaches his bandwidth
cap and gets throttled to a tenth of the bandwidth.
- While the page is loading, the user's roommate starts watching an
HD show on Hulu while his neighbour, also using the wife, starts
downloading a 4GB file on Bittorrent.
- The user loads the page, and while he's using it the server gets
DDOSed and its ability to serve data is impaired.
- Due to a network link router issue, half-way through the page load,
half the packets on the pipelined TCP stream end up routed around a
path that is twice as long as the rest of the packets.
- The user has a high-bandwidth link to intranet sites hosted on the same
yacht, but a satellite uplink for the rest of the network. A page on
the intranet has four images, three of which are given for
"high-bandwidth" connections and one for "low-bandwidth" connections.
The first two are hosted on the intranet, the latter two are hosted on
a host on the Internet. All four are on different subdomains of the
same domain (so their network position is indistinguishable).
In short, bandwidth is not constant, past performance is no guarantee of
future results, it can change dramatically without notice, there's no way
to determine the current available bandwidth, it's path-dependent, and
it's host-dependent.
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
>
> My suggestion is that the srcset (or <picture>) should assume that
> images are "2x" scale by default.
That's an interesting idea.
> My reasoning behind is:
>
> - we have <img> for easy embedding of 1x images today, but we don't have
> 2x <img> for the future. Having to specify width/height in <img> all the
> time is annoying.
>
> - highdpi displays will become dominant at some point, it's only a
> matter of time (they pretty much are already in high-end smartphones,
> and are going to appear in laptops next). Bandwidth is also going to be
> less of a concern, so it'll be rational and desirable to serve images
> for the 2x resolution only (and just rely on 96dpi displays scaling them
> down).
>
> Necessity to specify 2x scaling all the time will become a bad default
> and a historical quirk (like the DOCTYPE), and a source of annoyance
> where accidentally omitted "2x" syntax makes images large and pixelated.
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
> On Thu, 17 May 2012 12:52:47 +0100, Andy Davies <dajdavies at gmail.com>
> wrote:
> >
> > Doesn't this makes the assumption that pixel density is the most
> > likely reason for needing the alternative image rather than viewport /
> > image dimensions?
>
> Those two cases are orthogonal — one doesn't exclude the other, and
> I'm not claiming that it solves the "art-directed" case.
>
> In fact, even if you have adaptive cropping of the image, you'd still
> want image resolution to match display's DPI, e.g.
>
> obama-face at 2x.jpg vs obama-with-audience at 2x.jpg
>
> and possibly negotiate on both axes at the same time:
>
> obama-face at 2x.jpg vs obama-with-audience at 2x.jpg vs
> obama-face at 1x.jpg vs obama-with-audience at 1x.jpg
On Thu, 17 May 2012, Andy Davies wrote:
>
> srcset can be used to offer alternatives for higher or lower DPI,
> and/or larger or smaller viewports [...].
On Thu, 17 May 2012, Andy Davies wrote:
> On 17 May 2012 14:19, Kornel Lesiński <kornel at geekhood.net> wrote:
> >
> > Let me reiterate: it doesn't matter. Those are *separate* issues.
> > "Responsive image" is a bad term as it conflates two distinct problems
> > (screen density adaptation and physical screen size adaptation) into
> > one. It's not either-or choice. Both have valid use-cases.
> >
> > Support for high DPI displays is an absolute necessity.
> >
> > Don't look at current or past. Think how web development is going to
> > look like in 5, 10 or 20 years.
> >
> > There will be no low-res displays in the future. Everybody is going to
> > have "Retina" displays and everybody will hate that <img> or <picture>
> > inserts crappy pixelated images.
> >
> > Try browsing the web on the new iPad today. That's how every display
> > is going to look like in 10, maybe 20 years. Then DPI negotiation will
> > not be an option, it'll be absolute requirement for *every* *single*
> > image.
> >
> > HTML5 is designed for the next 50-100 years.
>
> The last line is exactly why baking in an assumption on the defaults
> isn't the right way to go.
>
> I don't disagree that higher DPI resolutions will become the norm but
> then what are we going to do about lower DPI devices, serve them a
> higher DPI than needed image and let them work it out rather than serve
> them appropriate images?
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
>
> Yes. You do the same for 256-color and monochrome displays today,
> because potential bandwidth savings are small and popularity/quality of
> those screens is not significant enough to care.
These are certainly somewhat compelling arguments. It would change this:
<img src="photo-xl.jpg" alt="..."
srcset="photo-s.jpg 320w, photo-s at 2x.jpg 320w 2x,
photo-m.jpg 640w, photo-m at 2x.jpg 640w 2x,
photo-l.jpg 1280w, photo-l at 2x.jpg 1280w 2x,
photo-xl at 2x.jpg 2x">
...to this:
<img src="photo-xl.jpg" alt="..."
srcset="photo-s.jpg 320w 1x, photo-s at 2x.jpg 320w,
photo-m.jpg 640w 1x, photo-m at 2x.jpg 640w,
photo-l.jpg 1280w 1x, photo-l at 2x.jpg 1280w,
photo-xl at 2x.jpg 2x">
...or, if we introduce the "inf" keyword:
<img src="photo-xl.jpg" alt="..."
srcset="photo-s.jpg 320w 1x, photo-s at 2x.jpg 320w,
photo-m.jpg 640w 1x, photo-m at 2x.jpg 640w,
photo-l.jpg 1280w 1x, photo-l at 2x.jpg 1280w,
photo-xl at 2x.jpg inf">
It's not clear to me that this is that great a win.
On Thu, 17 May 2012, Julian Reschke wrote:
>
> (Please read this as argument for making the syntax less brittle)
I read arguments for what they are, not what you want them to be. :-) If
you have concrete proposals, though, please don't hesitate to let us know.
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
> On Thu, 17 May 2012, Julian Reschke wrote:
> >
> > As far as I can tell, making descriptors optional breaks the syntax
> > (it allows comma both in the URI and as a separator between image
> > candidates).
>
> Indeed. I'm not sure which solution is the best:
>
> - make descriptors optional only for the last URL (which will work fine
> for the case where only the 2x image is supplied)
>
> srcset="a,b" is a single URL
>
> srcset="a, b" is an invalid descriptor for a single URL
>
> srcset="a 1x, b" is two URLs @1x and @2x
I think the inconsistency there is likely to trip people up. I agree that
it's a bit annoying that the 2x has to be given, though.
> - parse trailing comma in URL as a separator and hope no URL scheme
> needs it :)
Having "a,a, b" mean something different than "a, a, b" seems even more
confusing than allowing commas in URLs in teh first place!
> - introduce some kind of escaping for commas in the URL part:
>
> srcset="a,b" two URLs
>
> srcset="a\,b" one URL "a,b"
>
> srcset="a\\\, , \,b" two URLs "a\," and ",b"
Introducing new syntaxes for things like URLs seems like asking for
trouble. Nobody's going to be able to remember that in this one place in
HTML, cocommas have to be escaped.
On Thu, 17 May 2012, Julian Reschke wrote:
>
> - delimit URIs in text content with "<" and ">" as suggested by RFC 3986
> (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.C>).
Given the special meaning of < and > in HTML, that seems like asking for
trouble also (even though in attributes they technically don't have to be
escaped).
> - don't use a microsyntax
That has the problems I listed earlier.
The solution the spec uses doesn't seem so bad, in the end:
- always have a token after the URL, so that the URL always is followed
by a space
On Fri, 1 Jun 2012, Julian Reschke wrote:
>
> An alternative is to pick different delimiters.
Which delimiter did you have in mind? Pipe "|"? That would be pretty ugly
and highly unusual for HTML:
srcset="a.jpg 400w | b.jpg 500w | c.jpg 1x"
On Mon, 4 Jun 2012, Anselm Hannemann Web Development wrote:
>
> I also would like to see another delimiting syntax which is clearer.
> What about JSON-syntax or just " | "? I mean a backslash is not that
> common in a URL but commas are more and more and you all know that
> escaping is no fun. So we should really try to avoid this.
We're actually using spaces to delimit, as recommended by the relevant
RFCs. There's no ambiguity here.
On Thu, 17 May 2012, Tab Atkins Jr. wrote:
>
> I think this will be a confusing change that will hurt more than it
> helps. URLs in @srcset should act exactly like URLs in @src, except
> where modified by the descriptors.
There certainly is logic to that too.
> I think that 2x only looks like a good default now. I would bet that in
> less than 10 years 3x or higher will look like a good default. I'd
> rather not bake in a confusing change that doesn't actually future-proof
> anything.
That's possible. After all, printers are commonly as high as 600dpi, many
go even higher. (Of course, printers have much lower colour depths, which
is part of the reason why they need the higher resolution.)
Also, browsers support page zoom, which artificially changes the pixel
density by changing the definition of CSS pixel on the fly. If you want to
provide images suitable for people who use page zoom, then you're going to
need zoom levels above 2x.
On Thu, 17 May 2012, Tab Atkins Jr. wrote:
> On Thu, May 17, 2012 at 11:23 AM, Kornel Lesiński <kornel at geekhood.net> wrote:
> >>
> >> I think that 2x only looks like a good default now. I would bet that
> >> in less than 10 years 3x or higher will look like a good default.
> >
> > So why is 1x the default when it's obvious that it is not going to be
> > a good default?
>
> Because it's simple (1 image pixel = 1 CSS pixel), and it was the
> historical default.
Having it be consistent with src="" certainly seems less confusing on the
short and medium term. On the long term I agree that we're just adding
boilerplate, though... once everyone uses 4x displays, in 500 years or
whatever, it'll be a lot of extra typing:
<img srcset="handheld.sfi 200w 4x,
desktop.sfi 2000w 4x,
billboard.sfi 20000w 4x" alt="...">
Having said that, if it becomes a problem, we could always introduce a new
attribute once things have settled on a single resolution, so it's not
like it's the end of the world. For example, in the far future we could
add a "srcs" attribute:
<img srcs="handheld.sfi 200w,
desktop.sfi 2000w,
billboard.sfi 20000w" alt="...">
...which acts like srcset="" but defaults to 4x instead. Or maybe by then
we'll have figured out an image format that magically does the right thing
for any particular render width, and we can just do:
<img src="jupiter-holiday-home.smf">
...and not have to worry about any of this.
On Thu, 17 May 2012, Kornel LesiÅ~Dski wrote:
>
> Keep in mind that scaling factor is not tied too much to actual display
> DPI/perceived pixel size. When new denser displays come along, we won't
> jump from 2x to 3x, rather the 2x will change its meaning.
I doubt this is the case. When we have four device pixels per CSS pixel,
we'll need 4x to describe the images to use then. We can't exactly just
use the 2x images at half the dimensions... that wouldn't be backwards-
compatible.
> But let's say I'm wrong and 3x will end up being the ultimate scaling
> factor:
>
> - when authors specify the 3x scaling factor explicitly, it'll all work
> fine regardless of the default.
>
> - if the we don't change the default, then failing to specify the 3x
> scale factor will give very wrong result — a 1x image.
>
> - if we change the default to 2x, then failing to specify the 3x scale
> factor will give less wrong result — a 2x image.
It's not like people will give the wrong value -- it's immediately obvious
that the value is wrong.
On Thu, 17 May 2012, Jeremy Keith wrote:
>
> The x value describes the pixel density of the device/screen, not the
> image, right?
Both, really. A 100x100 image-pixel 1x image will be drawn using 100x100
CSS pixels, which on a 2x display is 200x200 device pixels. A 100x100
image-pixel 2x image will be drawn using 50x50 CSS pixels, which on a 2x
display is 100x100 device pixels.
On Sun, 20 May 2012, Kornel LesiÅ~Dski wrote:
>
> I've proposed moving the default to CSS:
>
> http://lists.w3.org/Archives/Public/www-style/2012May/0693.html
HTML can't depend on CSS, CSS is an optional layer.
On Mon, 21 May 2012, David Clements wrote:
>
> Just to let you all know, I've written a javascript implementation of
> srcset using a framework for responsive images (which I also wrote)
> called Respondu (I'm open to new name suggestions), I'd love it if
> someone could check that I've implemented srcset right.
Assuming you just followed the spec, make sure to fix the greater/lesser
problem mentioned earlier!
On Mon, 21 May 2012, Julian Reschke wrote:
> >
> > https://github.com/davidmarkclements/Respondu ...
>
> <https://github.com/davidmarkclements/Respondu/blob/master/R.js#L243>
>
> This looks like you are splitting the attribute value by ","?
This does indeed seem to be using a proprietary algorithm to parse
srcset="" that has a number of bugs. For example, it's not properly
dropping erroneous values, it's not properly handling "-" characters in
the floating point numbers, and it doesn't seem to allow 1.01x as a value.
On Mon, 21 May 2012, huperekchuno at googlemail.com wrote:
>
> I believe the attribute sets are delimited by comma, whereas each
> attribute itself is separated by space?
The spec has a specific algorithm you are supposed to follow to parse
srcset="":
http://www.whatwg.org/specs/web-apps/current-work/#processing-the-image-candidates
> The actual attributes themselves are matched with regex's, to be more
> forgiving to the order.
The spec defines exactly how forgiving you are supposed to be.
On Mon, 21 May 2012, Mike Gossmann wrote:
>
> The big thing I realized is that as a developer, I do not want to write
> more media queries - or anything that works at all like them - into
> image elements. It's redundant. There's a good chance there's already a
> bunch of CSS in place controlling the shape and size of the image
> element itself, why should I have to write a bunch more, somewhere else,
> to control the src of the image too?
Fundamentally, because at the time the browser starts fetching the image,
it hasn't yet seen the CSS.
On Wed, 23 May 2012, Florian Rivoal wrote:
>
> 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.
Could you elaborate on the use cases that it doesn't handle?
> I believe the only way out is through an image format that:
> - stores multiple resolutions in one file
> - stores the higher resolution as incremental information on top of the
> low res, so that downloading low res images isn't a waste of time even if
> you want the high res.
> - is designed so that the browser can stop downloading half way through
> the file, if it determines it got sufficiently high resolution given the
> environment.
Such a format would certainly be a great thing here.
> The "1x, 2x..." syntax probably needs to be tweaked to accommodate such
> images:
> srcset="standard.jpg 1x, progressive.prog 0.1-4x"
Once it's widely supported, you would just give the highest resolution.
If such a format becomes supported, though, I agree that it's something we
should add to aid migration. I'm reluctant to add something like that
before it's a problem, though.
> As an aside, this syntax might work to mix raster images and vector
> images: srcset="foo.svg 0.1-0.5x, foo.jpg 1x"
How would this differ from:
srcset="foo.svg 0.5x, foo.jpg 1x"
...?
On Wed, 23 May 2012, Mathew Marquis wrote:
>
> Honestly, I think this is a brilliant compromise
A compromise is, by its nature, not the best solution.
> combining authors' overwhelming preference for media queries,
Is there really an overwhelming preference for media queries over the
slightly differnet syntax that does the same thing? Why?
> the need for layout-based art direction
srcset="" does this in the same way as media queries.
> the (relative) simplicity of `srcset` for implementors
It's simpler for everyone, not just implementors. :-)
[at this point in the thread I have again skipped a number of e-mails that
revisited topics to which I have given answers earlier in this e-mail]
On Thu, 24 May 2012, Florian Rivoal wrote:
>
> <picture>
> <source srcset="normal.jpg 1x, highres.jpg 2x">
> <source media="(max-width:768px)" srcset="ipad.jpg 1x, ipad3.jpg 2x">
> <source media="(max-width:320px)" srcset="iphone.jpg 1x, iphone4.jpg 2x">
> <img src="normal.jpg">
> </picture>
I don't understand why this is better than:
<img src="normal.jpg" srcset="highres.jpg 2x,
ipad.jpg 768w 1x, ipad3.jpg 768w 2x,
iphone.jpg 320w 1x, iphone4.jpg 320w 2x"
alt="...">
...which as far as I can tell does exactly the same thing.
On Wed, 6 Jun 2012, Henri Sivonen wrote:
>
> Is there a good reason to believe that * will be something other than a
> power of two?
>
> That is, could we just optimize the *x syntax away and specify that the
> first option is 1x, the second is 2x, the third is 4x, etc.?
That's an interesting idea. There's two reasons I don't think we should
imply the multiplier: one is that many of the examples give many images
and I think it would get really confusing to have the resolutions implied
(e.g. consider the example immediately above, and how it would have to be
written if we implied the multiplier); the other reason is that we need a
descriptor to properly parse srcset="" due to the URL being allowed to
contain commas.
On Tue, 3 Jul 2012, Andy Davies wrote:
>
> Which ever solution to the responsive image eventually get's
> incorporated into the spec I think we need to account for this behaviour
> at the user-agent level i.e. if the UA decides to download a non-retina
> image because the user is on a cell network, then they need a way of
> easily choosing to download the retina image if they want.
The spec allows this.
On Mon, 23 Jul 2012, Mathew Marquis wrote:
>
> More and more it seems that it's a waste of effort trying to retrofit
> the original srcset proposal to cover all the use cases of the original
> `picture` proposal. As we attempt to do so, the `srcset` msyntax grows
> more confusing, and shares an increasing amount of overlap with media
> queries — though with some obvious holes, for example: units other than
> `px`. To those ends, the Responsive Images Community Group has
> officially published a draft proposal based on Florian Rivoal's proposed
> compromise (
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html
> ) between the two markup patterns. In this way, `srcset` retains the
> purpose for which it was originally proposed: a terse,
> easily-implemented syntax for switching image sources based on the
> client resolution.
>
> The draft proposal can be found here:
> http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal
I studied this, but couldn't find any reason why it would be better than
srcset="". It has a number of problems (such as those discussed earlier in
this e-mail), and doesn't seem to do anything that srcset="" doesn't do
but which people want to do. (The one example that seems to not be handled
by srcset="" is the print alternative, but in practice when people want to
do a print version they tend to use an entirely different page, not use
alternative medium style sheets, and in my experience, they tend _not_ to
change the images. Were this use case to become more widely desired,
though, we would probably address it at a more general level than
specifically with images, e.g. by introducing a global media="" attribute
in the style of XHTML2's media="" attribute.) (The proposal does mention
'em' units, but as they have to be processed before styling has begun they
are really equivalent to root 'rem' units, i.e. relative to 'medium', and
I believe that browsers will converge on fixing 'medium' at 16px, with
whole-page-zoom being used to increase font size instead of font zoom. So
'em' is just a fixed multiplier of 'px', and thus merely syntactic sugar.)
I did update the spec with examples derived from this proposal, though.
[at this point in the thread I have skipped a bunch of e-mails that were
discussing subtle design points of the <picture> proposals, but that don't
apply if we don't need the more verbose <picture> mechanism]
On Tue, 22 May 2012, Gábor Szabó wrote:
>
> why don't we keep the current markup and use progressive images. this way
> the browser could decide what resolution he needs, and when to stop
> downloading. this would solve the problem
> -having different dpi-s,
> -having different size of images.
> -on the server the overall disk space needed would be smaller.
> -information downloaded by browser could be used to display bigger images
> later.
> -browser could automatically switch to 'low-res' mode when having poor /
> expensive internet connection.
>
> http://www.libpng.org/pub/png/book/chapter01.html#png.ch01.div.2.3
> http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.6
>
> this problem should not be solved by html markup, i believe.
On Tue, 22 May 2012, Glenn Maynard wrote:
>
> This doesn't work. You can't stop a TCP download on a dime, due to TCP
> windowing, and aborting a download kills pipelined transfers, which
> ruins performance. You'd need to know in advance how many bytes to
> download to receive a given number of JPEG passes, which complicates
> things a lot; you'd need to inline a pass count/byte range index, which
> creates a harsh data dependency.
>
> JPEG quality is also a different axis of quality than changing
> resolution; if you want to drop the resolution by 1/2x or 1/4x, you
> often really do want to use an image authored at a lower resolution
> rather than using a lower-quality image, especially for non-photographic
> art like icons. It doesn't really work for PNG, either, since partial
> interlaced PNGs are too low-quality to be of much practical use (at
> least JPEG gives a reasonable quality--but no alpha).
Even if it did work, we'd still need to address the use case that involves
changing the image cropping based on the viewport dimensions.
I'm all for a new format that handles this, but in the absence of such a
format, we still need a solution.
On Tue, 22 May 2012, Paul Court wrote:
>
> As a HTML author and programmer, I just cannot see myself implementing
> the current srcset proposal on sites. As a programmer, it has very much
> got what we would call a "bad code smell".
>
> <img src="face-600-200 at 1.jpeg" alt="" srcset="face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h">
It would look more like this, assuming this is a full-bleed image
intended to cover the entire viewport:
<img src="face-600-200 at 1.jpeg" alt="" srcset="face-600-200 at 2.jpeg 600w 2x, face-icon.png 200w">
> Not to mention, what happens when a 3x device is released?
> Do I have to change all my code again?
Well if you create new images, yes. If you don't, no. I wouldn't expect
most people to go back and create new content images -- in practice, sites
rarely get updated.
> I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96?
It's 2x device pixels per CSS pixel.
> and isn't 600-200 at 2 just the same as 1200-400 at 1?
No, the former has an intrinsic width of 600 CSS pixels, the latter an
intrinsic width of 1200 CSS pixels.
> Wouldn't it be more future proof, instead of making the author supply a
> never ending string of image names, implement variable logic (I think
> first suggested by Matthew Wilcox). However, instead of the suggestion
> of putting as a head <meta> tag, perhaps the logic could be confined to
> the <img> tag (or a <picture> tag to allow slightly smoother
> transition).
>
> Perhaps something like this:-
>
> <picture>
> <src="some.img?{width}-{height}@{dpi}">
> <img src="some-fallback.img">
> </picture>
Not listing the specific dimensions means:
- every time you resize the window, you have to hit the network just in case
- caching is basically entirely lost, since every dimension is a new URL
- the server needs logic, which involves more CPU load than static images
On Fri, 1 Jun 2012, Kornel LesiÅ~Dski wrote:
>
> • I've used media queries for the art-directed use-cases, because: viewport
> size descriptors of srcset are confusing, limited (e.g. you can't have
> separate image only for print), and there must be an option to always
> predictably select image in conjunction with same `@media` in CSS (to adapt
> size of other page elements to the picture).
Can you give any examples of sites that use different images for print
than for screen? I've rarely if ever seen it, even when I wish sites would
do it (e.g. mapping sites).
> <pic src="image.jpg 1x">alt text</pic>
>
> Same as `<img src="image.jpg" alt="alt text">`. The `1x` means 1:1 scale
> of image to CSS pixels.
The lack of backwards-compatible fallback is a big problem here, I think.
> <pic src="small.jpg (max-width:320px), medium.jpg (max-width:768px), large.jpg">alt text</pic>
<img src="large.jpg" srcset="small.jpg 320w, medium.jpg 768w" alt="alt text">
> <pic src="portrait.jpg (orientation:portrait), landscape.jpg">alt text</pic>
>
> Selects image based on orientation of the device.
What's the use case for this? Do you have an example of a page that does
this today?
> <pic src="whitebg.jpg 2x print, blackbg.jpg 1x">alt text</pic>
>
> Embeds high-res image with white background when the page is printed, and a
> regular-res black image otherwise.
Do you have an example of a page that does this today?
(I'm very reluctant to try to address problems that don't actually exist.)
> <pic src="image.jpg">alt text</pic>
>
> Embeds image at 192dpi (default scaling is 2x, possible to override with CSS).
> Same as `<pic src="image.jpg 2x">alt text</pic>` or
> `<img src="100x100px" width="50" height="50" alt="alt text">`.
It seems a bit early for us to be confident that 2x is the right default
multiplier for the forseeable future.
> <pic src="image1.jpg 1x, image2.jpg 2x">alt text</pic>
>
> Embeds image at either 96dpi or 192dpi, depending on capabilities and
> preferences of the user agent (UA can pick any alternative).
>
> Same as `<pic src="image2.jpg 2x, image1.jpg 1x">alt text</pic>` and `<pic
> src="image2.jpg, image1.jpg 1x">alt text</pic>`.
With backwards compatibility:
<img src="image1.jpg" srcset="image2.jpg 2x" alt="alt text">
It's not clear to me that this is worse. In particular, the
backwards-compatibility gain seems huge to me.
> <pic src="small.jpg 0.5x, medium.jpg 1x, large.jpg 2x"
> style="width:100%">alt text</pic>
>
> Selects image based on display resolution/zoom, and optionally width of the
> container (if UA has layout information available when image is [pre]loaded).
> Unlike version with `min`/`max-width` media query, UA is allowed to pick any
> image and dynamically change the image (e.g. prefer cached image or download
> low-res first, replace with high-res when network is idle).
<img src="medium.jpg" srcset="small.jpg 0.5x, large.jpg 2x"
style="width:100%" alt="alt text">
...does the same thing, essentially.
> ##(optional?) extended syntax:
>
> <pic src="a (mq), b 3x">alt text</pic>
>
> is same as:
>
> <pic>
> <source src="a" media="(mq)">
> <source src="b" resolution="3x"">
> alt text
> </pic>
>
> (I'm not sure if `<source>` should allow microsyntax in `src` `<source src="b
> 3x">` instead of `resolution="3x"`)
Note that this introduces all the multiple-element problems listed earlier.
> The `<source>` element allows `width`/`height` to be specified for each
> alternative:
>
> <pic>
> <source src="large.jpg" media="(min-width:1024px)" width="1024" height"="300">
> <source src="medium.jpg" media="(min-width:768px)" width="768" height="200">
> <img src="small.jpg" width="320" height="100">
> alt text
> </pic>
Is the ability to specify the image dimensions that important?
Tab suggested to me once that if we wanted to support this, we could do it
by introducing new descriptors, as in (my syntax, not his):
<img ... srcset="small.jpg 100w is 100x100,
small at 2.jpg 100w 2x is 100x100,
large.jpg 1000w is 500x400">
If this is something people really need, we can add it, certainly.
However, adding it in the way suggested above with <source> seems just as
verbose as what would be possible today with <style scoped>:
<div>
<style scoped>
#a { width: 1024px; height: 300px; }
@media (max-width: 1024px) { #a { width: 768px; height: 200px; } }
@media (max-width: 768px) { #a { width: 320px; height: 100px; } }
</style>
<img src="lare.jpg" srcset="small.jpg 768w, medium.jpg 1024w"
id=a alt="alt text">
</div>
On Mon, 4 Jun 2012, Simon Pieters wrote:
>
> How do <img srcset> and CSS image-resolution interact? What happens with
> e.g. <img srcset="foo.jpg 2x" style="image-resolution:2dppx">?
On Mon, 9 Jul 2012, Tab Atkins Jr. wrote:
>
> I think that the @srcset resolution should be treated as an intrinsic
> resolution. In your example, then, 'image-resolution' would override
> the 2x (though both specify the same value, obviously). Using
> "from-image", though, would defer to the @srcset resolution.
HTML just says "When an img element has a current pixel density that is
not 1.0, the element's image data must be treated as if its resolution, in
device pixels per CSS pixels, was the current pixel density". If that's
not enough to do what Tab says above, please let me know.
On Mon, 25 Jun 2012, Oscar Otero wrote:
>
> I think the responsiveness, when we are talking about images, is not a
> problem of content but a problem of the bandwidth and performance, so
> this problem might be solved when the image is requested by using http
> headers.
As a general rule, authors have huge difficulty using HTTP headers,
unfortunately.
Incidentally, a special shout-out to Odin Hørthe Omdal, who did a great
job of actually reading the spec, answering questions, and asking people
to use regular quoting style on the mailing list, and to Tab Atkins, who
went around clearing up misconceptions and generally explaining things to
anyone who would listen and many who would not. Thanks. :-)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list