[whatwg] Features for responsive Web design

[Ian Hickson]

On Wed, 25 Jan 2012, Matthew Wilcox wrote:
> On 24 January 2012 23:26, Ian Hickson  wrote:
> > On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
> > >
> > > As we now have the possibility of creating fluid and responsive 
> > > layouts in several ways we have a problem with images.
> > >
> > > There's currently no good feature to implement something like 
> > > responsive images which adapt to the different device-resolutions. 
> > > We only can implement one image with one resolution scaling-up and 
> > > down.
> >
> > You can do adaptive sites using media queries.
> >
> >   
> >   My Site
> >
> >   // CSS
> >   @media (min-width: 320px and max-width: 640px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
> >   }
> >   @media (min-width: 640px and max-width: 1024px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
> >   }
> >   @media (min-width: 1024px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
> >   }
>
> This is of no use to content images - which are the real problem. CSS 
> supplied images are not an issue.

Fair enough.


Looking at the feedback on these threads over the past few months (I 
didn't quote it all here, but thank you to everyone for making very good 
points, both here on the list and on numerous blog posts and documents on 
the Web, referenced from these threads), it seems there are three main 
axes that control what image one might want to use on a page, assuming 
that one is rendering to a graphical display:

 - the size of the viewport into which the image is being rendered

 - the pixel density of the display device

 - the network bandwidth available to the page to obtain resources

Now I'm not sure what to do about the bandwidth one. It's very hard for a 
user agent to estimate its bandwidth availability -- it depends on the 
server, and the network location of the server, almost as much as on the 
location of the client; it depends on the current network congestion, it 
depends on the other things the browser is doing; it depends on whether 
the user is about to go through a tunnel or is about to switch to wifi; it 
depends on whether the user is roaming out of network or is on an OC48 
network pipe. It's hugely variable. It's not clear to me how to 
characterise it, either. It's also something that's changing very rapidly. 
On the more modern mobile networks, the real problem seems to be latency, 
not bandwidth; once you've actually kicked off a download, you can get the 
data very fast, it just takes forever to kick it off. That kind of problem 
is better solved by something like SPDY than by downloading smaller 
images. Downloading smaller images also screws up zooming images, which 
happens a lot more on mobile than on desktop.

A number of people proposed solutions that are variants on the 
/ mechanism, where you have an abundance of elements to 
replace the lonely . Looking at the examples of this, though, I could 
not get over how verbose the result is. If we're expecting this to be 
common -- which I think we are -- then really can't be asking authors to 
be providing dense collections of media queries, switch-statement like 
lists of URLs, and so forth, with each image.

Nor can we ask authors to provide a default and then have an external CSS 
file give alternatives. The syntax is different (and in some proposals 
actually already possible today), but the fundamental problem still 
exists: it's way too much work for just inserting an image in a page.

Another proposal that various people advocated is a header that the 
servers can use to determine what content to use. Besides a wide number of 
problems that people pointed out with this on the thread (such as the 
privacy issues due to fingerprinting, the many ways that such information 
gets abused, the high aggregate bandwidth cost, the difficulties with 
using headers in offline scenarios, etc), the biggest problem with this 
idea, IMHO, is that authors have shown that HTTP headers are simply a 
non-starter. Content-Type headers are perenially wrong, Accept headers are 
mishandled all over the place, adding Origin headers has caused 
compatibility issues... HTTP headers are a disaster. If there's ever an 
option to solve a problem without HTTP headers, we should take it, IMHO.


On Tue, 7 Feb 2012, Kornel LesiÅ~Dski wrote:
> 
> You could just say "I've got these image sizes available, choose which 
> one suits you best", and browser would pick one that makes most sense. 
> You (and every other web developer) wouldn't have to write and maintain 
> code for computation of bandwidth/latency/battery/screen 
> size/density/zoom/cpu speed/memory tradeoffs. With so many variables I'm 
> afraid that average developer wouldn't make better choices than mobile 
> browsers themselves can.

Indeed.

One thing I noticed when looking at the proposals is that they all 
conveyed a lot of information:

 - a list of files, each 

Re: [whatwg] An alternative to and srcset, is this realistic?

[Matthew Wilcox]

We're getting some good feedback over on the Community Group about
this, people seem to like it.

I'm still asking a few people to try and find holes in the proposal
though, reasons why it wouldn't work.

-Matt

On 14 May 2012 17:59, Tab Atkins Jr.  wrote:
> On Mon, May 14, 2012 at 9:31 AM, Matthew Wilcox  
> wrote:
>> All good points, thanks. Sorry I'd missed you saying 

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

Please, have you taken a look at the latest idea?

http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/

It solves many issues:

1) works with pre-fetch
2) is not verbose
3) is backward compatible with current browsers
4) is aimed for future-proofing - a re-design later with new or
different breakpoints would result in no edits to the mark-up
5) Avoids repetition and excessive processing of multiple media tests

I'd greatly appreciate more feedback on this approach at the Community Group.


Kind regards,
Matt Wilcox

On 15 May 2012 08:28, Ian Hickson  wrote:
> On Wed, 25 Jan 2012, Matthew Wilcox wrote:
>> On 24 January 2012 23:26, Ian Hickson  wrote:
>> > On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
>> > >
>> > > As we now have the possibility of creating fluid and responsive
>> > > layouts in several ways we have a problem with images.
>> > >
>> > > There's currently no good feature to implement something like
>> > > responsive images which adapt to the different device-resolutions.
>> > > We only can implement one image with one resolution scaling-up and
>> > > down.
>> >
>> > You can do adaptive sites using media queries.
>> >
>> >   
>> >   My Site
>> >
>> >   // CSS
>> >   @media (min-width: 320px and max-width: 640px) {
>> >     h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
>> >   }
>> >   @media (min-width: 640px and max-width: 1024px) {
>> >     h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
>> >   }
>> >   @media (min-width: 1024px) {
>> >     h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
>> >   }
>>
>> This is of no use to content images - which are the real problem. CSS
>> supplied images are not an issue.
>
> Fair enough.
>
>
> Looking at the feedback on these threads over the past few months (I
> didn't quote it all here, but thank you to everyone for making very good
> points, both here on the list and on numerous blog posts and documents on
> the Web, referenced from these threads), it seems there are three main
> axes that control what image one might want to use on a page, assuming
> that one is rendering to a graphical display:
>
>  - the size of the viewport into which the image is being rendered
>
>  - the pixel density of the display device
>
>  - the network bandwidth available to the page to obtain resources
>
> Now I'm not sure what to do about the bandwidth one. It's very hard for a
> user agent to estimate its bandwidth availability -- it depends on the
> server, and the network location of the server, almost as much as on the
> location of the client; it depends on the current network congestion, it
> depends on the other things the browser is doing; it depends on whether
> the user is about to go through a tunnel or is about to switch to wifi; it
> depends on whether the user is roaming out of network or is on an OC48
> network pipe. It's hugely variable. It's not clear to me how to
> characterise it, either. It's also something that's changing very rapidly.
> On the more modern mobile networks, the real problem seems to be latency,
> not bandwidth; once you've actually kicked off a download, you can get the
> data very fast, it just takes forever to kick it off. That kind of problem
> is better solved by something like SPDY than by downloading smaller
> images. Downloading smaller images also screws up zooming images, which
> happens a lot more on mobile than on desktop.
>
> A number of people proposed solutions that are variants on the
> / mechanism, where you have an abundance of elements to
> replace the lonely . Looking at the examples of this, though, I could
> not get over how verbose the result is. If we're expecting this to be
> common -- which I think we are -- then really can't be asking authors to
> be providing dense collections of media queries, switch-statement like
> lists of URLs, and so forth, with each image.
>
> Nor can we ask authors to provide a default and then have an external CSS
> file give alternatives. The syntax is different (and in some proposals
> actually already possible today), but the fundamental problem still
> exists: it's way too much work for just inserting an image in a page.
>
> Another proposal that various people advocated is a header that the
> servers can use to determine what content to use. Besides a wide number of
> problems that people pointed out with this on the thread (such as the
> privacy issues due to fingerprinting, the many ways that such information
> gets abused, the high aggregate bandwidth cost, the difficulties with
> using headers in offline scenarios, etc), the biggest problem with this
> idea, IMHO, is that authors have shown that HTTP headers are simply a
> non-starter. Content-Type headers are perenially wrong, Accept headers are
> mishandled all over the place, adding Origin headers has caused
> compatibility issues... HTTP headers are a disaster. If there's ever an
> option t

Re: [whatwg] Features for responsive Web design

[Anne van Kesteren]

On Tue, May 15, 2012 at 11:38 AM, 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/

It was quoted and replied to in the email you just replied to.

It has many problems. It adds a level of indirection, it imposes
constraints on where the resources are located and how they are named,
it requires access to the  element for adding an image in a blog
post, and it makes processing of URLs conditional on information
provided elsewhere. These are all significant issues.

I also do not see how it addresses the pixel density use case. You
cannot use a media query for that because a media query queries the
pixel density of the device, it does not *set* the pixel density of
the resource.


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

Constraints on where assets are placed and named? I do not follow your
reasoning here: You put them in the folder that's used for that design
breakpoint:

/anything/{whatever}/this/can/be/anything.jpg

I've seen no objections about that aspect in the Community Group
thread, where a number of authors have given feedback.



It addresses pixel density because it uses media queries and they
address pixel density. Any media query should be valid, so it's not
just



you could use



for example. MQ are by far the most flexible way of dealing with
reacting to device constraints.

What is set is the path to look for the image. This is *exactly* how
this works in CSS already for background-images and all authors are
familiar with this - you don't set the pixel density of an image, you
detect the device pixel density and change the path of the image you
send over CSS. Have a look at how almost any site is built and you'll
see *paths* change, not *image names*. http://enochs.co.uk is one
example.


Requiring access to head is not much of an issue, and has not been
raised by anyone commenting on the CG thread. Web designs tend to be
3-7 breakpoints that are shared site-wide. The actual design of each
page may not be, but the breakpoints are. This is why site's with many
types of page can all share the same list of CSS assets to load:










We are proposing nothing different than that, but to set variables
rather than to load a particular CSS file.

If it works for authors using CSS, why should it not also work for
setting image paths?



-Matt

On 15 May 2012 10:57, Anne van Kesteren  wrote:
> On Tue, May 15, 2012 at 11:38 AM, 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/
>
> It was quoted and replied to in the email you just replied to.
>
> It has many problems. It adds a level of indirection, it imposes
> constraints on where the resources are located and how they are named,
> it requires access to the  element for adding an image in a blog
> post, and it makes processing of URLs conditional on information
> provided elsewhere. These are all significant issues.
>
> I also do not see how it addresses the pixel density use case. You
> cannot use a media query for that because a media query queries the
> pixel density of the device, it does not *set* the pixel density of
> the resource.
>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

I do not see much potential for srcset. The result of asking the
author community was overwhelmingly negative, indirection or no
indirection.

To be clear, I don't see how indirection of this level can be an
issue, under those terms anything you write in CSS to effect a HTML
element is already "indirect" - to the extent of being in a different
file entirely.

-Matt

On 15 May 2012 11:13, Matthew Wilcox  wrote:
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
> 
>
> you could use
>
> 
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
> 
> 
>
> 
>  href="/assets/css/screen.320.css" />
>  href="/assets/css/screen.480.css" />
>  href="/assets/css/screen.750.css" />
>  href="/assets/css/screen.960.css" />
>
> We are proposing nothing different than that, but to set variables
> rather than to load a particular CSS file.
>
> If it works for authors using CSS, why should it not also work for
> setting image paths?
>
>
>
> -Matt
>
> On 15 May 2012 10:57, Anne van Kesteren  wrote:
>> On Tue, May 15, 2012 at 11:38 AM, 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/
>>
>> It was quoted and replied to in the email you just replied to.
>>
>> It has many problems. It adds a level of indirection, it imposes
>> constraints on where the resources are located and how they are named,
>> it requires access to the  element for adding an image in a blog
>> post, and it makes processing of URLs conditional on information
>> provided elsewhere. These are all significant issues.
>>
>> I also do not see how it addresses the pixel density use case. You
>> cannot use a media query for that because a media query queries the
>> pixel density of the device, it does not *set* the pixel density of
>> the resource.
>>
>>
>> --
>> Anne — Opera Software
>> http://annevankesteren.nl/
>> http://www.opera.com/

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

That's one of the major advantages of Adaptive Images (the PHP/JS
solution) and what people most like about it when they give me
feedback - it's all automatic with no custom HTML and it does all
image generation itself.

Yes, the vast majority of people who are going to put images into
websites are not web-developers but people using some CMS. The only
way these people are going to get multiple versions of the same image
is if the CMS can do it either automatically through re-sizing (as AI
does) or through providing upload fields for each breakpoint size.

The problem for end users (CMS users) is one of asset creation -
that's not a problem which can be solved by us in the scope of this
work - but we *do* need to consider this with whatever we end up
implementing. It is *highly* likely that the majority of use cases any
adaptive HTML mechanism will be applied to will have assets reference
through some automated image creation facility - as opposed to
hand-created.

That's why setting path variables is good. It's very likely that any
CMS is going to dump images into folders based on their fitting into a
design breakpoint: exactly as Adaptive Images does now. The number of
uses where people will manually create images at all sizes to
non-predictable paths are competitively tiny.

One-off responsiveness (one image element on a page, which is unique
in terms of adaption points) is where  may be useful. For
general responsiveness, the meta variable method is much more
appropriate and efficient.

-Matt

On 15 May 2012 12:51, Shane Hudson  wrote:
> I agree Matt. I have gone back to basics to define exactly what we are all
> needing and look to see if there are any ways we have not yet thought of.
>
> Ian's explaination of srcset makes me feel more comfortable with it than the
> original draft did, however I do believe it is the wrong way to go. There is
> a lot of repetition and very little room for expansion, the syntax also
> means that every img tag will look horrendous as more sizes develop.
>
> As I say, I am going to be writing a detailed reply shortly.
>
> I do have one question though… since the majority of images on the web are
> uploaded by general users (through the use of a CMS or image uploader such
> as flickr or Facebook), does anyone yet have a solution in which the user
> does not have to manually create the separate files? I may be missing
> something very simple here, but we do not want to be changing the user
> experience, a script will need to be able to convert a single image into the
> different sizes. I might be wrong in thinking a general image resizer would
> not work for this?
>
> 
>
> Shane Hudson (Website Developer - www.ShaneHudson.net)
>
> 07794746595
>
> @ShaneHudson / +Shane Hudson
>
> On Tuesday, 15 May 2012 at 11:22, Matthew Wilcox wrote:
>
> I do not see much potential for srcset. The result of asking the
> author community was overwhelmingly negative, indirection or no
> indirection.
>
> To be clear, I don't see how indirection of this level can be an
> issue, under those terms anything you write in CSS to effect a HTML
> element is already "indirect" - to the extent of being in a different
> file entirely.
>
> -Matt
>
> On 15 May 2012 11:13, Matthew Wilcox  wrote:
>
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
> 
>
> you could use
>
> 
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
> 
> 
>
> 
>  href="/assets/css/screen.320.css" />
>  href="/assets/css/screen.480.css" />
>  href="/assets/css/screen.750.css" />
>  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 wo

Re: [whatwg] , `img set`, and polyfills

[Mathew Marquis]

On May 14, 2012, at 8:29 PM, Kang-Hao (Kenny) Lu wrote:

> (12/05/15 7:17), Mathew Marquis wrote:
>> It’s worth noting that a practical polyfill may not be possible when using 
>> `img set`, for reasons detailed at length elsewhere:
>> http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
>> http://www.netmagazine.com/features/state-responsive-images
>> 
>> Long story short: attempting to write a polyfill for `img set` leaves us in 
>> the exact situation we were in while trying to solve the issue of responsive 
>> images strictly on the front-end. We would be saddling users with a 
>> redundant download—first for the original src, then for the 
>> appropriately-sized source if needed. 
>> 
>> Where the new element would be all but ignored by existing browsers, 
>> efficient polyfills become possible. In fact, two `picture` polyfills exist 
>> today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills
> 
> Sorry but I don't understand why  as used around  by
> these polyfills listed can't be used along .
> 
> If your point is that some Web developers will not cater for NoScript
> users and chose to include  in , I think those authors can
> use  without @src too (if I understand correctly).
> 

Scott Jehl has just posted a great write-up of some of the challenges 
associated with working around the `img` tag. https://gist.github.com/2701939


> 
> Cheers,
> Kenny

Re: [whatwg] Features for responsive Web design

[Jason Grigsby]

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.
> 
>   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.[1]

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.

Selection of what image is appropriate for a given layout at a specific 
breakpoint is not possible with srcset. This is possible for background images 
in CSS which makes srcset feel like a step backwards in this regard.

Bear in mind, I’m not talking about selections of images based on pixel 
density, resolution, bandwidth, etc., which I will readily concede only the UA 
can make an intelligent decision abut. But instead selection of images based on 
decisions about what looks best at each breakpoint in a design which only the 
author can decide.

-Jason

[1] http://adactio.com/journal/5425/

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 4:51 PM, 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.
>>
>>   >        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.[1]
>
> 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.
>
> Selection of what image is appropriate for a given layout at a specific 
> breakpoint is not possible with srcset. This is possible for background 
> images in CSS which makes srcset feel like a step backwards in this regard.
>
> Bear in mind, I’m not talking about selections of images based on pixel 
> density, resolution, bandwidth, etc., which I will readily concede only the 
> UA can make an intelligent decision abut. But instead selection of images 
> based on decisions about what looks best at each breakpoint in a design which 
> only the author can decide.

That's actually fine.  The max-width and max-height information
conveyed in @srcset is *not* used in a "do what you think is best"
manner.  It's a very explicit filter.

You only get the "do what you think is best" behavior when deciding
between resolutions, and those only have an effect on layout if you
mess up your ratios *and* do auto-sizing (it only has an effect on the
intrinsic size, which auto-sizing uses).  As long as you keep your
ratios lined up (like 1000@1, 2000@2, etc.) all of the images will
auto-size in the same way.

So, since you can predict which size of image will get chosen, you can
pair that with ordinary Media Queries to predictably adjust the rest
of your layout.

~TJ

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 9:28 AM, Ian Hickson  wrote:
> On Thu, 10 May 2012, Tab Atkins Jr. wrote:
>>
>> That all said, I don't like the "2x" notation.  It's declaring "this
>> image's resolution is twice that of a normal image".  This has two
>> problems.  For one, we already have a unit that means that - the dppx
>> unit.  Using "2dppx" is identical to the meaning of "2x".  Since
>> image-set() is newer than the dppx unit, we should change it to use
>>  instead.
>
> dppx is pretty ugly. I agree with hober's "2x" design.
>
>> For two, I'm not sure that it's particularly obvious that when you say
>> "2x", you should make sure your image was saved as 196dpi.  You have
>> to already know what the default resolution is.
>
> You don't have to. The resolution of the image is ignored.

If you don't set your image's resolution appropriately, you'll get
unexpected sizing effects.

>> As well, I think that values like 300dpi are pretty common, and they
>> don't map to integral 'x' values.  If people say "screw it" and use
>> "3x", this'll be slightly wrong and I think will cause ugly blurring.
>> If we make this take , people can just use the dpi unit.
>
> 3.125x isn't particularly difficult to specify.

I actually didn't even realize that 300dpi is 3.125 times 96dpi.

Regardless, I think being able to specify "300dpi" is easier than
using a calculator.

~TJ

Re: [whatwg] Features for responsive Web design

[Jason Grigsby]

On May 15, 2012, at 7:58 AM, Tab Atkins Jr. wrote:

> On Tue, May 15, 2012 at 4:51 PM, 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.
>>> 
>>>   >>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.[1]
>> 
>> 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.
>> 
>> Selection of what image is appropriate for a given layout at a specific 
>> breakpoint is not possible with srcset. This is possible for background 
>> images in CSS which makes srcset feel like a step backwards in this regard.
>> 
>> Bear in mind, I’m not talking about selections of images based on pixel 
>> density, resolution, bandwidth, etc., which I will readily concede only the 
>> UA can make an intelligent decision abut. But instead selection of images 
>> based on decisions about what looks best at each breakpoint in a design 
>> which only the author can decide.
> 
> That's actually fine.  The max-width and max-height information
> conveyed in @srcset is *not* used in a "do what you think is best"
> manner.  It's a very explicit filter.

Thanks for responding Tab. I’ve read your comments five or six times now and am 
not certain I understand it fully. Sorry if I’m being dense here. :-)

> You only get the "do what you think is best" behavior when deciding
> between resolutions, and those only have an effect on layout if you
> mess up your ratios *and* do auto-sizing (it only has an effect on the
> intrinsic size, which auto-sizing uses).  As long as you keep your
> ratios lined up (like 1000@1, 2000@2, etc.) all of the images will
> auto-size in the same way.

Are you saying that all of the image source listed in srcset would have the 
same aspect ratio? In the example Hixie provided, face-icon.png is a different 
ratio.

Another way to read this could be that you’re fine so long as your sources with 
different densities (e.g., 1x, 2x, etc) always have the same ratio. If so, I’m 
unclear on how that solves the problem when you have images that need different 
cropping like the Nokia example which is vertical in one case and horizontal in 
another.

> So, since you can predict which size of image will get chosen, you can
> pair that with ordinary Media Queries to predictably adjust the rest
> of your layout.

I’ve honestly been trying to figure out how such a pairing would work since we 
srcset was proposed and just don’t get it. The two seem very different because 
the media query only checks the viewport size and then takes specific action 
whereas srcset compares viewport to image size and grabs the largest image that 
fits. You end up tying image width to breakpoint width to make it work which 
means your image may be larger than it needs to be to fit the design.

Again, I find it very clear how srcset would work for image resolution/density 
use cases, but get utterly confused about how it would work in the use case 
above. If everyone gets it, can someone send me a note outside the list to 
explain it? I don’t want to bog down the list by my lack of understanding if it 
clear to everyone else.

-Jason

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby  wrote:
> Are you saying that all of the image source listed in srcset would have the 
> same aspect ratio? In the example Hixie provided, face-icon.png is a 
> different ratio.
>
> Another way to read this could be that you’re fine so long as your sources 
> with different densities (e.g., 1x, 2x, etc) always have the same ratio. If 
> so, I’m unclear on how that solves the problem when you have images that need 
> different cropping like the Nokia example which is vertical in one case and 
> horizontal in another.

That's what I'm saying.  Authors *can* ensure that, within a
particular breakpoint, their multi-res images all have the same ratio.
 It's a good idea, since the *intention* is that the multi-res
versions are all exact same image, just at different resolutions.

If you don't do that, you get unpredictable results, but you asked for that.

If you *do* do that, then you know what your aspect ratio will be, and
you can predict which breakpoint will be chosen and pair that with MQs
to adjust the rest of your layout.

~TJ

Re: [whatwg] Features for responsive Web design

[Jason Grigsby]

On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote:

> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby  wrote:
>> Are you saying that all of the image source listed in srcset would have the 
>> same aspect ratio? In the example Hixie provided, face-icon.png is a 
>> different ratio.
>> 
>> Another way to read this could be that you’re fine so long as your sources 
>> with different densities (e.g., 1x, 2x, etc) always have the same ratio. If 
>> so, I’m unclear on how that solves the problem when you have images that 
>> need different cropping like the Nokia example which is vertical in one case 
>> and horizontal in another.
> 
> That's what I'm saying.  Authors *can* ensure that, within a
> particular breakpoint, their multi-res images all have the same ratio.
> It's a good idea, since the *intention* is that the multi-res
> versions are all exact same image, just at different resolutions.
> 
> If you don't do that, you get unpredictable results, but you asked for that.
> 
> If you *do* do that, then you know what your aspect ratio will be, and
> you can predict which breakpoint will be chosen and pair that with MQs
> to adjust the rest of your layout.

Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do 
it”? Or am I missing something?

BTW, I know things are a little heated on irc right now so please read my 
questions as sincere attempts to understand how this would work and not as 
attempts to be obstinate. :-)

-Jason

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

Um, the fact of the matter is we don't want to ensure they have the
same ratio. It is exactly why we want to swap images sometimes - the
aspect ratio no longer fits the design being applied at the given
breakpoint.



On 15 May 2012 18:48, Jason Grigsby  wrote:
> On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote:
>
>> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby  wrote:
>>> Are you saying that all of the image source listed in srcset would have the 
>>> same aspect ratio? In the example Hixie provided, face-icon.png is a 
>>> different ratio.
>>>
>>> Another way to read this could be that you’re fine so long as your sources 
>>> with different densities (e.g., 1x, 2x, etc) always have the same ratio. If 
>>> so, I’m unclear on how that solves the problem when you have images that 
>>> need different cropping like the Nokia example which is vertical in one 
>>> case and horizontal in another.
>>
>> That's what I'm saying.  Authors *can* ensure that, within a
>> particular breakpoint, their multi-res images all have the same ratio.
>> It's a good idea, since the *intention* is that the multi-res
>> versions are all exact same image, just at different resolutions.
>>
>> If you don't do that, you get unpredictable results, but you asked for that.
>>
>> If you *do* do that, then you know what your aspect ratio will be, and
>> you can predict which breakpoint will be chosen and pair that with MQs
>> to adjust the rest of your layout.
>
> Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do 
> it”? Or am I missing something?
>
> BTW, I know things are a little heated on irc right now so please read my 
> questions as sincere attempts to understand how this would work and not as 
> attempts to be obstinate. :-)
>
> -Jason

Re: [whatwg] Features for responsive Web design

[Glenn Maynard]

On Tue, May 15, 2012 at 2:28 AM, Ian Hickson  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.

  

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.  (In principle, it could also download the LQ
version first, then after the rest of the site has loaded and the page is
usable, go back and start downloading a better version, replacing the image
in-place invisibly to scripts.  You sort-of get this with progressive
JPEGs, but you can't get any control over it with HTTP.)  This assumes the
image quality is roughly linearly comparable; it probably wouldn't make
sense to mix JPEG and PNG images like this.

The heuristics for figuring out which size to use would be up to
implementations.  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.

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.

-- 
Glenn Maynard

Re: [whatwg] Features for responsive Web design

[Matthew Wilcox]

I think there's a fundamental mis-match in the mental model of how
authors work and what they want. I'm pretty sure we're all shooting
for the same "be more efficient" goal, but I think that here on the
mailing list that's being approached from an angle that has not
considered how authors actually want to do this.

We work with designs that re-arrange content and sometimes call for
different images of the same semantic meaning. That is *not* the same
use case as simply sending a different version of the same image.
Srcset only addresses that one type of use, and that is why authors
feel it's flawed. It doesn't do what we need, and never can because
srcset is based on the assumptin that a UA can somehow pick an
appropriate resource to load - when it can't possibly know about the
authors use of that resource at that time.

-Matt

On 15 May 2012 19:19, Matthew Wilcox  wrote:
> Um, the fact of the matter is we don't want to ensure they have the
> same ratio. It is exactly why we want to swap images sometimes - the
> aspect ratio no longer fits the design being applied at the given
> breakpoint.
>
>
>
> On 15 May 2012 18:48, Jason Grigsby  wrote:
>> On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote:
>>
>>> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby  wrote:
 Are you saying that all of the image source listed in srcset would have 
 the same aspect ratio? In the example Hixie provided, face-icon.png is a 
 different ratio.

 Another way to read this could be that you’re fine so long as your sources 
 with different densities (e.g., 1x, 2x, etc) always have the same ratio. 
 If so, I’m unclear on how that solves the problem when you have images 
 that need different cropping like the Nokia example which is vertical in 
 one case and horizontal in another.
>>>
>>> That's what I'm saying.  Authors *can* ensure that, within a
>>> particular breakpoint, their multi-res images all have the same ratio.
>>> It's a good idea, since the *intention* is that the multi-res
>>> versions are all exact same image, just at different resolutions.
>>>
>>> If you don't do that, you get unpredictable results, but you asked for that.
>>>
>>> If you *do* do that, then you know what your aspect ratio will be, and
>>> you can predict which breakpoint will be chosen and pair that with MQs
>>> to adjust the rest of your layout.
>>
>> Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do 
>> it”? Or am I missing something?
>>
>> BTW, I know things are a little heated on irc right now so please read my 
>> questions as sincere attempts to understand how this would work and not as 
>> attempts to be obstinate. :-)
>>
>> -Jason

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 8:19 PM, Matthew Wilcox  wrote:
> Um, the fact of the matter is we don't want to ensure they have the
> same ratio. It is exactly why we want to swap images sometimes - the
> aspect ratio no longer fits the design being applied at the given
> breakpoint.

I think you misunderstand the scenario I'm talking about.

You do want to vary the aspect-ratio based on screen-size breakpoints.
 For example, you may want to go from a 1024x300 image to a 600x200
image when the window is less than 1024px wide.

You *don't* want to vary the aspect-ratio when you're just selecting
different resolutions.  As far as I know, there's no use-case for
actually giving *different images* when you just select on resolution
(after you've already decided which to use based on breakpoints).  I'm
ready to be corrected, but I haven't seen anything against this
assumption yet.

~TJ

Re: [whatwg] Features for responsive Web design

[Maciej Stachowiak]

On May 15, 2012, at 8:06 AM, Tab Atkins Jr.  wrote:

> On Tue, May 15, 2012 at 9:28 AM, Ian Hickson  wrote:
>> On Thu, 10 May 2012, Tab Atkins Jr. wrote:
>> 
>> 3.125x isn't particularly difficult to specify.
> 
> I actually didn't even realize that 300dpi is 3.125 times 96dpi.
> 
> Regardless, I think being able to specify "300dpi" is easier than
> using a calculator.

On the other hand, checking for an integer X factor is easier than checking for 
an integer multiple of 96dpi, for authors who would like to avoid the ugly 
visual artifacts of non-integral scaling. Which I hope is all of them. It's 
easier to tell that 3.125x is a bad idea than with 300dpi.

Regards,
Maciej

Re: [whatwg] Features for responsive Web design

[Glenn Maynard]

On Tue, May 15, 2012 at 10:06 AM, Tab Atkins Jr. wrote:

> >> For two, I'm not sure that it's particularly obvious that when you say
> >> "2x", you should make sure your image was saved as 196dpi.  You have
> >> to already know what the default resolution is.
> >
> > You don't have to. The resolution of the image is ignored.
>
> If you don't set your image's resolution appropriately, you'll get
> unexpected sizing effects.
>

I think the terms are confused, since we use "resolution" to refer to both
image dimensions and DPI, which are very different things.  We might want
to avoid the term in a discussion that involves both.

The DPI is ignored by browsers, of course; it's the dimensions vs. the
scale factor that you have to get right.

It would probably help readability a lot if you're allowed to use ratios,
eg. 300/96 to mean 3.125.

-- 
Glenn Maynard

[whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Andy Davies]

Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...

   

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.

Andy

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 1:42 PM, Andy Davies  wrote:
> Looking at the srcset proposal it appears to be recreating aspects of
> media-queries in a terse less obvious form...
>
>           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.

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.

Are there good cases to use other types of media queries?  I never got
to join the CG, so I'm sure I missed out on lots of use-cases that
were presented.

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Bruce Lawson]

On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr.   
wrote:



On Tue, May 15, 2012 at 1:42 PM, Andy Davies  wrote:

Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...

  

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.


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.


Just so I understand

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)


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.


Is that accurate?

I'm sympathetic to (2); why require a developer to think of and describe  
every permutation if the environment, when she could instead describe that  
which she knows - the images - and then allow the UA to take the decision.  
As time goes on, UAs get cleverer, so behaviour improves without the  
markup needing changing.


But it doesn't seem necessary to saddle authors with (1) to acheive (2),  
as far as I can see.


bruce-speaking-for-myself-not-Opera

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 2:46 PM, 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)
[snip]
> I'm sympathetic to (2); why require a developer to think of and describe
> every permutation if the environment, when she could instead describe that
> which she knows - the images - and then allow the UA to take the decision.
> As time goes on, UAs get cleverer, so behaviour improves without the markup
> needing changing.
>
> But it doesn't seem necessary to saddle authors with (1) to acheive (2), as
> far as I can see.

I think I more or less agree with you.  However, when you look at MQ,
literally the only things you want to decide on are width/height, and
*maybe* grayscale/color. You really don't need to be generic here, so
you might as well optimize the syntax to make it easier to type.

I think this is too much, personally.  I'd prefer more verbosity here, like:



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.)

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Anne van Kesteren]

On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr.  wrote:
> 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.)

Well, it's not a media query. It *describes* the size of the image. A
media query *evaluates* device capabilities. They are completely
different and allow for different resource selection algorithms.


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 3:01 PM, Anne van Kesteren  wrote:
> On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr.  wrote:
>> 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.)
>
> Well, it's not a media query. It *describes* the size of the image.

No it doesn't.  Saying "600w" next to a URL says nothing about the
size of the image, just that you claim that the image at that URL is
intended for screens at least 600px wide.

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Chris Heilmann]

On 15/05/2012 22:46, Bruce Lawson wrote:
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. 
 wrote:


On Tue, May 15, 2012 at 1:42 PM, Andy Davies  
wrote:

Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...



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.


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.


Just so I understand

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)


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.


Is that accurate?

I'm sympathetic to (2); why require a developer to think of and 
describe every permutation if the environment, when she could instead 
describe that which she knows - the images - and then allow the UA to 
take the decision. As time goes on, UAs get cleverer, so behaviour 
improves without the markup needing changing.


But it doesn't seem necessary to saddle authors with (1) to acheive 
(2), as far as I can see.


bruce-speaking-for-myself-not-Opera


I also wonder what we do with videos? Surely they have the same issues 
and there is no proposal for changing the syntax there. 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.


From a semantic point of view this is a terrible mix of everything - 
something that the picture proposal with multiple sources was not.


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.


embed is the fallback to video with various sources. img is the fallback 
to embed. I'd like to see picture - done like video for consistency as 
it is a new use case for images. Old browsers could disregard them and 
new ones can use mediaqueries to apply the different sources as needed. 
Yes, mediaqueries do not all the things we need here and browsers have 
bugs loading various sources instead of only one but these are things to 
fix in the browser engines, not add an extra use case in the spec.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Anselm Hannemann Web Development]

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...?

-Anselm

Am 15.05.2012 um 23:56 schrieb Tab Atkins Jr.:

> On Tue, May 15, 2012 at 2:46 PM, 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)
> [snip]
>> I'm sympathetic to (2); why require a developer to think of and describe
>> every permutation if the environment, when she could instead describe that
>> which she knows - the images - and then allow the UA to take the decision.
>> As time goes on, UAs get cleverer, so behaviour improves without the markup
>> needing changing.
>> 
>> But it doesn't seem necessary to saddle authors with (1) to acheive (2), as
>> far as I can see.
> 
> I think I more or less agree with you.  However, when you look at MQ,
> literally the only things you want to decide on are width/height, and
> *maybe* grayscale/color. You really don't need to be generic here, so
> you might as well optimize the syntax to make it easier to type.
> 
> I think this is too much, personally.  I'd prefer more verbosity here, like:
> 
> 
> 
> 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.)
> 
> ~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Anselm Hannemann Web Development]

Am 16.05.2012 um 00:06 schrieb Chris Heilmann:

> On 15/05/2012 22:46, Bruce Lawson wrote:
>> On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr.  
>> wrote:
>> 
>>> On Tue, May 15, 2012 at 1:42 PM, Andy Davies  wrote:
 Looking at the srcset proposal it appears to be recreating aspects of
 media-queries in a terse less obvious form...
 
 >>>   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.
>>> 
>>> 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.
>> 
>> Just so I understand
>> 
>> 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)
>> 
>> 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.
>> 
>> Is that accurate?
>> 
>> I'm sympathetic to (2); why require a developer to think of and describe 
>> every permutation if the environment, when she could instead describe that 
>> which she knows - the images - and then allow the UA to take the decision. 
>> As time goes on, UAs get cleverer, so behaviour improves without the markup 
>> needing changing.
>> 
>> But it doesn't seem necessary to saddle authors with (1) to acheive (2), as 
>> far as I can see.
>> 
>> bruce-speaking-for-myself-not-Opera
>> 
>> 
> I also wonder what we do with videos? Surely they have the same issues and 
> there is no proposal for changing the syntax there. 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.
> 
> From a semantic point of view this is a terrible mix of everything - 
> something that the picture proposal with multiple sources was not.
This is what I think, too.
> 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.
> 
> embed is the fallback to video with various sources. img is the fallback to 
> embed. I'd like to see picture - done like video for consistency as it is a 
> new use case for images. Old browsers could disregard them and new ones can 
> use mediaqueries to apply the different sources as needed. Yes, mediaqueries 
> do not all the things we need here and browsers have bugs loading various 
> sources instead of only one but these are things to fix in the browser 
> engines, not add an extra use case in the spec.
And that is a reason why picture is (imo) the better option. It is far more 
flexible to future changes of media.
I also don't think we need a now working solution but a solution that work for 
the next couple of years (maybe 10yrs or more). I also won't say picture is the 
best way to go but it is far better than the proposal that made it in some 
"draft" earlier this day.

-A.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Chris Heilmann]

On 15/05/2012 23:11, 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...?



+1

The fetish for brevity is something I never understood. More 
understandable code is faster to write than cryptic short code.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 3:06 PM, 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. 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.

 is a special case, unfortunately.  It would be difficult to
avoid using  there, but we shouldn't look at it as a good
example in general.  Using  introduces a lot of problems that
would be good to avoid if possible.

> From a semantic point of view this is a terrible mix of everything -
> something that the picture proposal with multiple sources was not.

There's no semantics in here - this is all presentation and usability.
 This is just a very compact way to state the information that
 presented more verbosely.

 is no more a "terrible mix of everything" than


  


is.

> 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.

We should take care not to be future-hostile, but designing for all
hypothetical futures just results in muddled, hard-to-use designs.
Among current MQs, there are 2/4 (depending on if you count min/max
separate) queries you definitely want to use, and one that *might* be
useful (and which can be added to the microsyntax cleanly).

I'm not aware of proposed future MQs that would be useful to tie into
this functionality, either.


> embed is the fallback to video with various sources. img is the fallback to
> embed. I'd like to see picture - done like video for consistency as it is a
> new use case for images. Old browsers could disregard them and new ones can
> use mediaqueries to apply the different sources as needed. Yes, mediaqueries
> do not all the things we need here and browsers have bugs loading various
> sources instead of only one but these are things to fix in the browser
> engines, not add an extra use case in the spec.

See the blog post I wrote today so I'd have to stop giving this same
argument over and over again. ^_^ .
 You simply can't make a good decision about which resolution to send
to the user based on information from Media Queries.

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Odin Hørthe Omdal]

Andy Davies  wrote:

Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...

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...


Ah! What a truly great question, so simple.

The answer is: no, it is not media-queries although they look like it. A
big problem is that it's so easy to explain it by saying "it's just like
media-query max-width", rather than finding the words to illustrate that
they are totally different.

The *limited effect* also feels similar which doesn't help the case at
all.

So, even though I have a rather bad track record of explaining any
thing, I'll try again:

Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.


That's the basic difference, totally different. :-)


With mediaqueries, you don't know at the time when you're prefetching an
image, what box it is in. So many media queries will either not make
sense (so they won't work like authors intend them to), OR the browser
would have to wait until it has layout for it to start fetching images.
Neither of these two would actually be good, so they are in conflict.

I'd also like to give an example on the "smart uses in the future" for
imgsrc; right-click save could fetch the biggest quality image and save
that one instead of the one it has currently fetched.


Bruce Lawson  skreiv Tue, 15 May 2012 23:46:44 +0200

Just so I understand

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)


No. It only works on device-width also, and it's only a hint, so it's
actually part of your part 2:

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.


Is that accurate?


Yeah, sounds more like it. But it applies to the whole thing.

I'm sympathetic to (2); why require a developer to think of and describe  
every permutation if the environment, when she could instead describe  
that which she knows - the images - and then allow the UA to take the  
decision. As time goes on, UAs get cleverer, so behaviour improves  
without the markup needing changing.


Exactly.

But it doesn't seem necessary to saddle authors with (1) to acheive (2),  
as far as I can see.


It's heavily optimized for the usecase that will happen most often: for
"retina" type displays:





bruce-speaking-for-myself-not-Opera


I'm not speaking for Opera either, but we do work for Opera, and it's
hard to disclaim everything always.


I hope it made sense.

--
Odin Hørthe Omdal (odinho/Velmont) · Opera Software

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Silvia Pfeiffer]

On Wed, May 16, 2012 at 8:37 AM, Odin Hørthe Omdal  wrote:
> Andy Davies  wrote:
>>
>> Looking at the srcset proposal it appears to be recreating aspects of
>> media-queries in a terse less obvious form...
>>
>> 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...
>
>
> Ah! What a truly great question, so simple.
>
> The answer is: no, it is not media-queries although they look like it. A
> big problem is that it's so easy to explain it by saying "it's just like
> media-query max-width", rather than finding the words to illustrate that
> they are totally different.
>
> The *limited effect* also feels similar which doesn't help the case at
> all.
>
> So, even though I have a rather bad track record of explaining any
> thing, I'll try again:
>
> Media queries come from the client side. They allow the author of a web
> page to tell exactly how she want to lay out her design based on the
> different queries. The browser *HAS* to follow these queries. And also,
> I don't think (please correct me if wrong) the media query can be subset
> to only the stuff that's really meaningful to do at prefetch-time.
>
> The srcset proposal, on the other hand, are purely HINTS to the browser
> engine about the resources. They are only declarative hints that can be
> leveraged in a secret sauce way (like Bruce said in another mail) to
> always optimize image fetching and other features. If you make a new
> kind of browser (like e.g. Opera mini) it can have its own heuristics
> that make sense *for that single browser* without asking _anyone_.
> Without relying on web authors doing the correct thing, or changing
> anything or even announce to anyone what they are doing. It's opening up
> for innovation, good algorithms and smart uses in the future.
>
>
> That's the basic difference, totally different. :-)

If that's the case, would it make sense to get rid of the @media
attribute on  elements in  and replace it with @srcset?

Silvia.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Odin Hørthe Omdal]

Silvia Pfeiffer  skreiv Wed, 16 May 2012  
00:57:48 +0200



Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.

That's the basic difference, totally different.


If that's the case, would it make sense to get rid of the @media
attribute on  elements in  and replace it with @srcset?


Video is at least a bit different in that you don't expect it to be fully  
loaded and prefetch at such an early stage as img. But I've been thinking  
about that since I read something like "we already have media queries in  
source for video, but it's not really implemented and used yet".


I'm not sure. What do you think? As far as I've seen, you're highly  
knowledgeable about . Why do we have mediaqueries on video element?  
Do we have a use case page? Doing the same as whatever  ends up doing  
might be a good fit if the use cases are similar enough. Would be nice to  
be consistent if that makes sense.


--
Odin Hørthe Omdal · odinho / Velmont · Opera Software

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Jeremy Keith]

Odin wrote:
> It's heavily optimized for the usecase that will happen most often: for
> "retina" type displays:
> 
>

Okay. This is also what Ted said about the srcset proposal and it makes a lot 
of sense for that use case.

But it seems far less suited to the use-case of "art-directed" image decisions 
i.e. allowing the author to specify which image should be displayed (based on 
some criteria, possibly the viewport size).

Jason does a good job of differentiating both use-cases here:

http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/

> 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.

Now ideally we'd find one solution that solves both use-cases but after the 
discussion here and in IRC I think that's looking increasingly unlikely.

So if we can agree that srcset is a good solution for handling "retina" 
displays and other "secret sauce" conditions (like bandwidth, as Tab blogged 
about), can we move on to trying to find a different solution for the other use 
case?

I *suspect* that the solution for the art-direction use-case could look almost 
exactly like media queries (because the use-case is so similar to common 
use-cases for media queries).

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Kornel Lesiński]

On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann   
wrote:


The fetish for brevity is something I never understood. More  
understandable code is faster to write than cryptic short code.


There is significant difference in verbosity for a *very common case* of  
serving images for high-dpi ("Retina") display (which I suspect is only  
going to get more common):




vs







It will get tiring when it'll have to be used for every image on the page.

Authors couldn't be bothered to type extra markup for all vendor's  
prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which  
was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.


--
regards, Kornel Lesiński

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Kornel Lesiński]

On Tue, 15 May 2012 23:57:48 +0100, Silvia Pfeiffer  
 wrote:



Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.


That's the basic difference, totally different. :-)


If that's the case, would it make sense to get rid of the @media
attribute on  elements in  and replace it with @srcset?


I think something like that would be perfect.

In fact, I'd keep @media, because it serves some cases very well (I see  
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:  
http://geekhood.net/MediaQuery-vs-PerfQuery.png)



It may be enough to add another attribute that describes image properties,  
and can be used either alone or with conjunction with MQs:







would be equivalent to:



(I've proposed that in the RespImg community group)


And combination of the two opens new possibilities:








--
regards, Kornel Lesiński

Re: [whatwg] Features for responsive Web design

[Kornel Lesiński]

On Tue, 15 May 2012 19:25:23 +0100, Matthew Wilcox  
 wrote:



I think there's a fundamental mis-match in the mental model of how
authors work and what they want. I'm pretty sure we're all shooting
for the same "be more efficient" goal, but I think that here on the
mailing list that's being approached from an angle that has not
considered how authors actually want to do this.

We work with designs that re-arrange content and sometimes call for
different images of the same semantic meaning. That is *not* the same
use case as simply sending a different version of the same image.
Srcset only addresses that one type of use, and that is why authors
feel it's flawed. It doesn't do what we need, and never can because
srcset is based on the assumptin that a UA can somehow pick an
appropriate resource to load - when it can't possibly know about the
authors use of that resource at that time.


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, while  is  
perfect for it.


 is not very good for resolution/bandwidth optimisation, while  
srcset is perfect for it.



I think those are simply two different problems that just happen to be  
called "adaptive images". We should recognized that they're separate and  
design separate solutions for them. A single solution can't do both well,  
since there's a fundamental difference between author-controlled and  
UA-controlled decision.


--
regards, Kornel Lesiński

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 4:23 PM, Jeremy Keith  wrote:
> Odin 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.
>
> Now ideally we'd find one solution that solves both use-cases but after the 
> discussion here and in IRC I think that's looking increasingly unlikely.

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.

Looking through the list of Media Queries, it seems that the only
useful ones for art-direction style changes are the width/height ones,
and maybe the monochrome or color ones.  We can always add the latter
to the microsyntax if necessary (their syntax in MQ is pretty weird).

I'm not aware of any plans for future MQs that would be very useful here either.

~TJ

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 4:43 PM, Kornel Lesiński  wrote:
> On Tue, 15 May 2012 19:25:23 +0100, Matthew Wilcox 
> wrote:
>
>> I think there's a fundamental mis-match in the mental model of how
>> authors work and what they want. I'm pretty sure we're all shooting
>> for the same "be more efficient" goal, but I think that here on the
>> mailing list that's being approached from an angle that has not
>> considered how authors actually want to do this.
>>
>> We work with designs that re-arrange content and sometimes call for
>> different images of the same semantic meaning. That is *not* the same
>> use case as simply sending a different version of the same image.
>> Srcset only addresses that one type of use, and that is why authors
>> feel it's flawed. It doesn't do what we need, and never can because
>> srcset is based on the assumptin that a UA can somehow pick an
>> appropriate resource to load - when it can't possibly know about the
>> authors use of that resource at that time.
>
>
> 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, while  is perfect
> for it.
>
>  is not very good for resolution/bandwidth optimisation, while
> srcset is perfect for it.
>
>
> I think those are simply two different problems that just happen to be
> called "adaptive images". We should recognized that they're separate and
> design separate solutions for them. A single solution can't do both well,
> since there's a fundamental difference between author-controlled and
> UA-controlled decision.

I suspect this is simply confusion about the proposal - @srcset
handles the "art-directed" case same as , just with a
somewhat more compact microsyntax rather than using MQs directly.  (On
the plus side, the slightly-special processing of the microsyntax
ensures that at least one image will be chosen no matter what, while
it's unclear how an MQ-based solution will work if none of the MQs
match.)

Given that @srcset was generated as a solution to the use-cases that
the CG brought up, it would be difficult to justify it if it didn't
handle those cases.  ^_^

~TJ

Re: [whatwg] Features for responsive Web design

[Jason Grigsby]

On May 15, 2012, at 4:51 PM, Tab Atkins Jr. wrote:

> I suspect this is simply confusion about the proposal - @srcset
> handles the "art-directed" case same as , just with a
> somewhat more compact microsyntax rather than using MQs directly.  (On
> the plus side, the slightly-special processing of the microsyntax
> ensures that at least one image will be chosen no matter what, while
> it's unclear how an MQ-based solution will work if none of the MQs
> match.)
> 
> Given that @srcset was generated as a solution to the use-cases that
> the CG brought up, it would be difficult to justify it if it didn't
> handle those cases.  ^_^

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.

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:



With a viewport width of 400px, the media query I defined to modify my layout 
would take affect. The layout would thus assume a square image. But @srcset 
would pick the rectangle image because both images are smaller than the 
viewport and the algorithm that Hixie defined says, “then of the remaining 
images pick the widest one, if any have a width, tie-breaking by picking the 
tallest one”.

This is where the disconnect on the art direction side happens. From a layout 
perspective, we’ve making decision based on viewport size (or whatever other 
media query we want, but primarily viewport size). But from the img tag 
perspective, we’re selecting images by comparing image size to viewport.

It seems to me that the differences in these comparisons will inevitably cause 
problems for the art direction use case because they will be out of sync.

-Jason

Re: [whatwg] Features for responsive Web design

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 5:15 PM, Jason Grigsby  wrote:
>
> On May 15, 2012, at 4:51 PM, Tab Atkins Jr. wrote:
>
>> I suspect this is simply confusion about the proposal - @srcset
>> handles the "art-directed" case same as , just with a
>> somewhat more compact microsyntax rather than using MQs directly.  (On
>> the plus side, the slightly-special processing of the microsyntax
>> ensures that at least one image will be chosen no matter what, while
>> it's unclear how an MQ-based solution will work if none of the MQs
>> match.)
>>
>> Given that @srcset was generated as a solution to the use-cases that
>> the CG brought up, it would be difficult to justify it if it didn't
>> handle those cases.  ^_^
>
> 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.
>
> 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:
>
>      srcset="a-rectangle.png 300w 150h 1x,
>             a-square.png 100w 100h 1x">

Nope, what you want is this:



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.


> With a viewport width of 400px, the media query I defined to modify my layout 
> would take affect. The layout would thus assume a square image. But @srcset 
> would pick the rectangle image because both images are smaller than the 
> viewport and the algorithm that Hixie defined says, “then of the remaining 
> images pick the widest one, if any have a width, tie-breaking by picking the 
> tallest one”.

With the fixed example, at a window width of 400px, the rectangle
image would be thrown out and we'd use the square.

~TJ

[whatwg] "fullscreenchange" event should be delayed to after transition is complete

[Chris Pearce]

Hi,

I think that the "fullscreenchange" even dispatch should be specified to 
be dispatched once the animation to transition to/from fullscreen has 
finished.


The problem is that at least two of the platforms we're supporting have 
non-instantaneous transitions from windowed to fullscreen mode. So if we 
dispatch "fullscreenchange" events as specified during 
HTMLElement.requestFullscreen() then the "fullscreenchange" events can 
arrive before the transition animation has finished, so things like 
window.screenY and window.size.* haven't reached their stable fullscreen 
values.


Our unit tests have been randomly failing because of this, so I'm sure 
this will cause problems with authors in the wild.


I think having the state changes performed by 
HTMLElement.requestFullscreen() happen synchronously before the 
animation/transition to enter fullscreen completes (as specified 
currently) and having them undone before the animation to exit 
fullscreen completes (also as specified currently in exitFullscreen()) 
is probably OK, since these state changes maybe required for the 
transition/animation. It's only the dispatch of "fullscreenchange" I 
think we should change.



Cheers,
Chris Pearce.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Boris Zbarsky]

On 5/15/12 7:33 PM, Kornel Lesiński wrote:

In fact, I'd keep @media, because it serves some cases very well (I see
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:
http://geekhood.net/MediaQuery-vs-PerfQuery.png)


@media on video source is terrible for layout adaptation: it's only 
considered when selecting a source.  So if you load the page, then turn 
your device so it's in landscape mode (or resize your browser window or 
whatever), the source won't change, even though which source matches the 
medium might have just changed.


Is the expectation that device-adapting images will reload from the new 
URI in cases like the above?  Or not?  Both answers have some problems.  :(


-Boris

[whatwg] / not needed

[Aldrik Dunbar]

Hi there,

Adding a new *presentational* attribute/element for adaptive/responsive
images makes no sense and is not required. We already have a flexible
image format that can accomplish this — SVG, e.g.:



http://www.w3.org/2000/svg"; viewBox="0 0 900 1135">
A painting by Edvard Munch, commonly known as "the scream".
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";);
 }
}
]]>



Regards,
Aldrik Dunbar.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[D. Pitchford]

On 2012-05-15, at 7:23 PM, Kornel Lesiński wrote:

> On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann  wrote:
> 
>> The fetish for brevity is something I never understood. More understandable 
>> code is faster to write than cryptic short code.
> 
> There is significant difference in verbosity for a *very common case* of 
> serving images for high-dpi ("Retina") display (which I suspect is only going 
> to get more common):
> 
> 
> 
> vs
> 
> 
> 
> 
> 
> 
> 
> It will get tiring when it'll have to be used for every image on the page.
> 
> Authors couldn't be bothered to type extra markup for all vendor's prefixes 
> in CSS. Nobody bothered with verbose SVG gradient syntax which was usable 
> before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.
> 
> -- 
> regards, Kornel Lesiński


This brings up a very good point: multiplying the number of images.

I'll go one step further and suggest a hypothetical (which is not really a 
hypothetical):
- 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 
 or  to align with the new design?
With either proposal this does not seem like the most efficient way for anyone 
to spend their time, and is opening a door to a *huge* maintenance issue.

I dread the day when I have to dig through, possibly hundreds of pages, with 
multiple images per, to update the breakpoints and resolutions.
Surely there's a better way to manage breakpoints on a global level rather than 
burying the specifics within the elements or attributes themselves.

See the thread here: 
http://www.w3.org/community/respimg/2012/04/26/syntax-issue-with-displaying-high-resolution-images-in-the-picture-element-how-a-mole-hill-could-turn-into-a-mountain/
See example here from Brett Jankord: https://gist.github.com/2509534

I would hope than any solution to responsive images takes maintenance a little 
more serious than it has up to this point, as it seems more of an afterthought 
than anything.
Both proposals at this point regardless of semantics, syntax, verbosity or 
terseness will do no one any favours, and will have huge ramifications in areas 
nobody is talking about.

Copy/Paste from the example gist above, which I can very much see in happen in 
the wild:

 

 
 

 
 

 
 

 
 
 


//Notes
//--
Markup based off of Scott Jehl's picturefill example.
Added commented source elements (needed for IE9, Android 2.1-2.3 and iOS 4.3 
Safari) 
to demonstrate how a real life cross-browser implementation might look like. 
15 lines of code for "1" image :( 



Granted this may be better aligned to a separate topic unto itself, but thought 
it needed to be documented.

Cheers,
D.

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Silvia Pfeiffer]

On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal  wrote:
> Silvia Pfeiffer  skreiv Wed, 16 May 2012 00:57:48
> +0200
>
>>> Media queries come from the client side. They allow the author of a web
>>> page to tell exactly how she want to lay out her design based on the
>>> different queries. The browser *HAS* to follow these queries. And also,
>>> I don't think (please correct me if wrong) the media query can be subset
>>> to only the stuff that's really meaningful to do at prefetch-time.
>>>
>>> The srcset proposal, on the other hand, are purely HINTS to the browser
>>> engine about the resources. They are only declarative hints that can be
>>> leveraged in a secret sauce way (like Bruce said in another mail) to
>>> always optimize image fetching and other features. If you make a new
>>> kind of browser (like e.g. Opera mini) it can have its own heuristics
>>> that make sense *for that single browser* without asking _anyone_.
>>> Without relying on web authors doing the correct thing, or changing
>>> anything or even announce to anyone what they are doing. It's opening up
>>> for innovation, good algorithms and smart uses in the future.
>>>
>>> That's the basic difference, totally different.
>>
>>
>> If that's the case, would it make sense to get rid of the @media
>> attribute on  elements in  and replace it with @srcset?
>
>
> Video is at least a bit different in that you don't expect it to be fully
> loaded and prefetch at such an early stage as img. But I've been thinking
> about that since I read something like "we already have media queries in
> source for video, but it's not really implemented and used yet".

Some browsers support @media in video for min/max width and height
specifications. But I believe the use case is more like the one we are
trying to solve with @srcset than a traditional media queries use
case.


> I'm not sure. What do you think? As far as I've seen, you're highly
> knowledgeable about . Why do we have mediaqueries on video element?
> Do we have a use case page?

Hehe, thanks. :-) But media queries were in  before I arrived,
so I missed the whole discussion around it and how it got there. Some
of the browsers that implement support for it should speak up.


> Doing the same as whatever  ends up doing
> might be a good fit if the use cases are similar enough. Would be nice to be
> consistent if that makes sense.

I'm not 100% sure I grok the difference between media queries and
@srcset. I threw this question into the mix to see the reaction -
maybe we need both? What would that even mean?

In addition, I wonder about the adaptive streaming case where byte
ranges from different files are being switched to dynamically during
playback because of bandwidth change. For video, the solution seems to
be: use a manifest file in your @src (such as DASH) and rely on the
browser to pick between the files. Or you use javascript:
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
. An attribute like @srcset would allow listing the alternative files
directly in the HTML file. That may be preferable?

More questions than answers right now, but we should think
consistently between audio, video and images.

Cheers,
Silvia.

Re: [whatwg] "fullscreenchange" event should be delayed to after transition is complete

[Brandon Jones]

I've had intermittent issues with this as well, and completely agree that
the even should happen after the transition is done. Barring that, it would
be useful if the elements on the page reported their post-transition sizes
and positions in the even callback.

In the same vein, I'd also like to point out that I've had very similar
issues with orientationchange on mobile devices. Many mobile browsers have
a quick "rotating" animation that accompanies an orientation change, but
the related events seem to fire before the page is actually transformed.
The best method I've found for handling it is to start a ~1sec timeout
after the orientation change event before measuring any elements. That
creates a noticeable delay in the layout update for the users though.

In short, any APIs that transform the document like this really ought to
specify that the related events fire post-transition.

-Brandon

On Tue, May 15, 2012 at 5:33 PM, Chris Pearce  wrote:

> Hi,
>
> I think that the "fullscreenchange" even dispatch should be specified to
> be dispatched once the animation to transition to/from fullscreen has
> finished.
>
> The problem is that at least two of the platforms we're supporting have
> non-instantaneous transitions from windowed to fullscreen mode. So if we
> dispatch "fullscreenchange" events as specified during
> HTMLElement.requestFullscreen(**) then the "fullscreenchange" events can
> arrive before the transition animation has finished, so things like
> window.screenY and window.size.* haven't reached their stable fullscreen
> values.
>
> Our unit tests have been randomly failing because of this, so I'm sure
> this will cause problems with authors in the wild.
>
> I think having the state changes performed by
> HTMLElement.requestFullscreen(**) happen synchronously before the
> animation/transition to enter fullscreen completes (as specified currently)
> and having them undone before the animation to exit fullscreen completes
> (also as specified currently in exitFullscreen()) is probably OK, since
> these state changes maybe required for the transition/animation. It's only
> the dispatch of "fullscreenchange" I think we should change.
>
>
> Cheers,
> Chris Pearce.
>

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Anselm Hannemann Web Development]

You might remember about my proposal 9 months ago. If not you can see it here: 
https://gist.github.com/1158855

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";
>

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.

>> Doing the same as whatever  ends up doing
>> might be a good fit if the use cases are similar enough. Would be nice to be
>> consistent if that makes sense.
> 
> I'm not 100% sure I grok the difference between media queries and
> @srcset. I threw this question into the mix to see the reaction -
> maybe we need both? What would that even mean?

I don't know if we need both. Why should we? Because @media-query features are 
currently not enough? Standard behavior which is build in a browser won't need 
any of these solutions, right? Also the picture-element does not *require* a 
MQ. It can also be used to just serve a list of sources and let it up to the 
browser what to fetch.

> In addition, I wonder about the adaptive streaming case where byte
> ranges from different files are being switched to dynamically during
> playback because of bandwidth change. For video, the solution seems to
> be: use a manifest file in your @src (such as DASH) and rely on the
> browser to pick between the files. Or you use javascript:
> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
> . An attribute like @srcset would allow listing the alternative files
> directly in the HTML file. That may be preferable?

This sounds good but too complicated for a normal developer and you have to see 
that we also should respect CMS implementations.
I don't know (but probably only don't understand the technique correct) if this 
is not too complicated?

> More questions than answers right now, but we should think
> consistently between audio, video and images.

That is what I totally support except there are already adaptive streaming 
technologies for video-formats but not for pictures (which is another topic I 
came up against a brick-wall).
-Anselm

Re: [whatwg] / not needed

[Anselm Hannemann Web Development]

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.

Another thing is: We do not have any graphic editor to do such things you have 
described yet. So you have to write this on your own along with SVG polyfills 
etc.
This is a valid solution but won't work for the masses of developers. Please, 
always think of the millions of HTML-developers who only want to do a normal 
cool website using responsive images.

Thanks!
-Anselm

Am 16.05.2012 um 03:23 schrieb Aldrik Dunbar:

> Hi there,
> 
> Adding a new *presentational* attribute/element for adaptive/responsive
> images makes no sense and is not required. We already have a flexible
> image format that can accomplish this — SVG, e.g.:
> 
> 
> 
> http://www.w3.org/2000/svg"; viewBox="0 0 900 1135">
>   A painting by Edvard Munch, commonly known as "the scream".
>      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";);
>  }
>   }
>   ]]>
> 
> 
> 
> Regards,
> Aldrik Dunbar.

Re: [whatwg] / not needed

[Tab Atkins Jr.]

On Tue, May 15, 2012 at 6:23 PM, Aldrik Dunbar  wrote:
> Hi there,
>
> Adding a new *presentational* attribute/element for adaptive/responsive
> images makes no sense and is not required. We already have a flexible
> image format that can accomplish this — SVG, e.g.:
>
>
> 
> http://www.w3.org/2000/svg"; viewBox="0 0 900 1135">
>        A painting by Edvard Munch, commonly known as "the 
> scream".
>                        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";);
>  }
>                }
>        ]]>
> 

This is *way* more verbose than either  or ,
doesn't interact with preloading, and doesn't do any kind of
negotiation resolution.  There are good reasons for the designs that
have been discussed so far.

~TJ

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

[Maciej Stachowiak]

On May 15, 2012, at 3:06 PM, 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.

With current codecs, and given human perception of visual images, videos can be 
decoded at multiple resolutions without as obvious visual degradation as 
images. Even at 1:1 scale, videos as served by many popular sites have 
significant visual artifacts. So for videos, we're still in the real of 
straight tradeoff of visual quality for bandwidth and/or size. Generally, 
increasing the bitrate will increase quality on all displays, and there's not 
much purpose to doing it selectively.

In theory, resolution-based selection could apply to the poster attribute of 
, as well as to . But it seems reasonable to figure 
things out fully and get some deployment experience with img before extending 
this feature.

 - Maciej