[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 <picture> may be useful. For
general responsiveness, the meta variable method is much more
appropriate and efficient.

-Matt

On 15 May 2012 12:51, Shane Hudson <Shane at shanehudson.net> wrote:
> I agree Matt. I have gone back to basics to define exactly what we are all
> needing and look to see if there are any ways we have not yet thought of.
>
> Ian's explaination of srcset makes me feel more comfortable with it than the
> original draft did, however I do believe it is the wrong way to go. There is
> a lot of repetition and very little room for expansion, the syntax also
> means that every img tag will look horrendous as more sizes develop.
>
> As I say, I am going to be writing a detailed reply shortly.
>
> I do have one question though… since the majority of images on the web are
> uploaded by general users (through the use of a CMS or image uploader such
> as flickr or Facebook), does anyone yet have a solution in which the user
> does not have to manually create the separate files? I may be missing
> something very simple here, but we do not want to be changing the user
> experience, a script will need to be able to convert a single image into the
> different sizes. I might be wrong in thinking a general image resizer would
> not work for this?
>
> ________________________________
>
> Shane Hudson (Website Developer - www.ShaneHudson.net)
>
> 07794746595
>
> @ShaneHudson / +Shane Hudson
>
> On Tuesday, 15 May 2012 at 11:22, Matthew Wilcox wrote:
>
> I do not see much potential for srcset. The result of asking the
> author community was overwhelmingly negative, indirection or no
> indirection.
>
> To be clear, I don't see how indirection of this level can be an
> issue, under those terms anything you write in CSS to effect a HTML
> element is already "indirect" - to the extent of being in a different
> file entirely.
>
> -Matt
>
> On 15 May 2012 11:13, Matthew Wilcox <mail at matthewwilcox.com> wrote:
>
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
> <meta name="case" value="large" media="min-width:900px;" />
>
> you could use
>
> <meta name="case" value="very-large" media="(device-pixel-ratio:2) and
> (min-width:30em)" />
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
> <!-- Styling for all devices -->
> <link rel="stylesheet" media="screen" href="/assets/css/screen.core.css" />
>
> <!-- Styling for progressively larger displays -->
> <link rel="stylesheet" media="only screen and (min-width: 320px)"
> href="/assets/css/screen.320.css" />
> <link rel="stylesheet" media="only screen and (min-width: 480px)"
> href="/assets/css/screen.480.css" />
> <link rel="stylesheet" media="only screen and (min-width: 750px)"
> href="/assets/css/screen.750.css" />
> <link rel="stylesheet" media="only screen and (min-width: 960px)"
> href="/assets/css/screen.960.css" />
>
> We are proposing nothing different than that, but to set variables
> rather than to load a particular CSS file.
>
> If it works for authors using CSS, why should it not also work for
> setting image paths?
>
>
>
> -Matt
>
> On 15 May 2012 10:57, Anne van Kesteren <annevk at annevk.nl> wrote:
>
> On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox <mail at matthewwilcox.com>
> wrote:
>
> Please, have you taken a look at the latest idea?
>
> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>
>
> It was quoted and replied to in the email you just replied to.
>
> It has many problems. It adds a level of indirection, it imposes
> constraints on where the resources are located and how they are named,
> it requires access to the <head> element for adding an image in a blog
> post, and it makes processing of URLs conditional on information
> provided elsewhere. These are all significant issues.
>
> I also do not see how it addresses the pixel density use case. You
> cannot use a media query for that because a media query queries the
> pixel density of the device, it does not *set* the pixel density of
> the resource.
>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/
>
>