News

Add new post →

The Picturefill named Div

grayghostvisuals

Posted on

Gray Ghost Visuals

So I was messing with my own site when this spark started (also the same time Scott was updating the repos) and I’d like to get some feedback from outside entities. To give you an idea of what I’m talking about let me show you this little snippet (pasted below) and mind you this is just for the stupid little social icons in my footer. I’ve implemented the most recent commits from Picturefill that I’d like to personally go ahead and coin as “Divfill.”

[side note : This Divfill artist formerly known as Picturefill now appends an img element within div[data-picture]. As you hopefully will see this markup pattern can get unruly very quickly if used on a larger scale.]

I've also created a new branch with my own fork of Picturefill where I'm putting together a real world example using this technique of Scott's on a larger scale –with a Flickr–like layout. I hope we can use this live example and build upon it as a way to identify verboseness and at the same time indicate what's working. I've done this only because a real world example is crucial to understand what we really need. This isn't to blow the wind out of the Divfill sail. The two example images in use are just not cutting it. As they say, the proof is in the puddin' so here comes the spoon.

Markup using div polyfill

The following is the snippet I used within my footer. I also set my fallbacks for Retina


<article id="footer-socials">
<h3>Follow Along</h3>
<ul class="socials-listing">
<li class="twitter">
<a href="https://twitter.com">
<div data-picture data-alt="">
<div data-src="img/twitterBird.png" data-media="screen"></div>
<div data-src="img/twitterBird@2x.png" data-media="(-webkit-min-device-pixel-ratio: 2),(min-device-pixel-ratio: 2)"></div>
<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
<noscript><img src="img/twitterBird.png" alt=""></noscript>
</div>
</a>
</li> 

<li class="dribbble">
<a href="http://dribbble.com">
<div data-picture data-alt="Social Follow Buttons">
<div data-src="img/dribbbleLogo.png" data-media="screen"></div>
<div data-src="img/dribbbleLogo@2x.png" data-media="(-webkit-min-device-pixel-ratio: 2), (min-device-pixel-ratio: 2)"></div>
<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
<noscript><img src="img/dribbbleLogo.png" alt=""></noscript>
</div>
</a>
</li> 

<li class="facebook">
<a href="http://www.facebook.com">
<div data-picture data-alt="Social Follow Buttons">
<div data-src="img/facebookLike.png" data-media="screen"></div>
<div data-src="img/facebookLike@2x.png" data-media="(-webkit-min-device-pixel-ratio: 2), (min-device-pixel-ratio: 2)"></div>
<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
<noscript><img src="img/facebookLike.png" alt=""></noscript>
</div>
</a>
</li> 

<li class="github">
<a href="https://github.com">
<div data-picture data-alt="Social Follow Buttons">
<div data-src="img/githubOctocat.png" data-media="screen"></div>
<div data-src="img/githubOctocat@2x.png" data-media="(-webkit-min-device-pixel-ratio: 2), (min-device-pixel-ratio: 2)"></div>
<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
<noscript><img src="img/githubOctocat.png" alt=""></noscript>>
</div>
</a>
</li>
</ul>
</article>

Florian’s Compromise

Mathew Marquis

Posted on

Filament Group

I’ve been fairly quiet in this group for a while now. Part of that was wanting to let the dust settle on all the chaos that was surrounding this topic a few short weeks ago, and part of that was giving myself some time to digest the bits of signal that came through amidst all the “responsive images” noise.

More and more it seems that it’s a waste of effort trying to retrofit the original srcset proposal to cover all the use cases of the original picture proposal. As we attempt to do so, the srcset microsyntax grows and more and more confusing, and shares an increasing amount of overlap with media queries. To those ends, I asked Florian Rivoal — editor of the media query spec — to join the discussion on the WHATWG mailing list and offer his perspective.

Florian joined the list by posting a brilliantly thought-out compromise between the two syntax patterns. I’d like to share my thoughts on this proposal here, as I feel it combines the strengths of srcset and picture in a practical and logical way.

Let’s begin by taking a look at the proposed syntax.

Sample Markup Pattern


<picture alt="Description of image subject.">
  <source srcset="small.jpg 1x, small-highres.jpg 2x">
  <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
  <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x">
  <img src="small.jpg" alt="Description of image subject.">
</picture>

The chain of events followed by the above markup pattern are:

  1. If the picture element is unsupported, the img contained therein is shown as fallback markup.
  2. If picture is supported, use media attributes to determine which source element best suits the user’s viewport.
  3. Once an appropriate source element has been selected, the srcset attribute determines which image source is best suited to the user’s screen resolution. If only a single resolution is necessary, the src attribute will function as expected.

In terms of selecting a source element, this markup leverages all the strengths of media queries — the syntax created for this very purpose — to handle the “art direction” use case that Jason Grigsby has illustrated so eloquently.

However, as has been detailed at length on the WHATWG mailing list and elsewhere, device-pixel-ratio media queries are poorly suited towards these decisions. As an author, using vendor-prefixed min-device-pixel-ratio media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern.

Once we’ve used media queries to determine the most appropriate source element, srcset’s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user’s resolution.

It’s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an img tag for simply preforming resolution switching, nor does it preclude the use of picture as originally proposed, with src in source elements rather than srcset.

Bandwidth

The dark cloud hanging over all these discussions is the concept of “bandwidth detection.” We cannot reliably make assumptions about bandwidth based on client capabilities — a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection.

It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms.

I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this.

In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.

It seems srcset won’t be going anywhere, and that’s not an indictment. There is a time and a place for srcset. I feel that place is resolution switching, as it was originally intended. Our best efforts to bring srcset closer in-line with the originally proposed picture element only stand to leave us with a siloed microsyntax that inconsistently serves the purpose of media queries. With that comes further opportunity for errors by implementors and authors alike — countless new potential points of failure.

An Updated Polyfill

In order to better wrap my head around this pattern, I’ve updated Scott Jehl’s Picturefill to make use of the proposed syntax. The source code is available on GitHub, and I’ve posted a demo as well.

Next Steps

I’ve been discussing the implementation details of this pattern with several vendors recently, and the feedback has been extremely promising.

I’d love to hear everyone’s thoughts on this compromise, and through your feedback put together a set of formal proposals: a change proposal returning srcset to its original resolution-only syntax, and a proposal for picture that focuses on the “art direction” use case and optimization for client displays through media queries, excluding resolution.

The Constant Caveat

It seems I always end my posts in much the same way, but it always seems to ring true: this solution is not the ultimate solution to every problem in the “selectively loading assets” arena — nor does it have to be, right now.

There will always be limitless room for improvement when it comes to markup — a better way to handle source management for rich media, for example. But we can’t solve everything now — we can’t fall into the trap of seeking the perfect solution all at once.

Our goal is a laser-focused solution with the potential to fall in-line with other rich media elements, as we solve the greater issues one by one — issues of bandwidth detection; issues of organization. Our goal is to solve a very real and increasingly urgent problem, in a way that serves as a canvas for future enhancements. I’m confident that this syntax affords us that opportunity.

We can’t predict the future. We can only strive to be future friendly, while solving the problems of today. I’m confident this proposal does so.

A new proposal in the WHATWG Mailing List featuring both advantages

Anselm Hannemann

Posted on

Kornel Lesinski just published a new proposal on the WHATWG mailing list this morning. He proposes a new element in HTML called <pic> which is shorter to write than <picture> would be.

This solution combines the advantages of our proposal of the picture-element and the proposal of the resolution based srcset approach by the WHATWG published recently.

The syntax also can be written in a short way and in a long way. This is good for developers because normal developers can write it the common HTML-like way while advanced developers are provided with a short-syntax.
Also the syntax is able to use @media-queries as well as resolutions.

In short syntax the code could look:

<pic src="small.jpg (max-width:320px), medium.jpg (max-width:768px), large.jpg">alt text</pic>

<pic src="portrait.jpg (orientation:portrait), landscape.jpg">alt text</pic>

<pic src="small.jpg 0.5x, medium.jpg 1x, large.jpg 2x" style="width:100%">alt text</pic>

While the long syntax could be like that:

<pic>
       <source src="large.jpg" media="(min-width:1024px)" width="1024" height"="300">
       <source src="medium.jpg" media="(min-width:768px)" width="768" height="200">
       <img src="small.jpg" width="320" height="100">
       alt text
</pic>

This of course is a first proposal to which I already replied with several improvements but it looks like we finally get in the right direction where we will get the best approach we can find together. And I am super happy that this has been proposed.

Here is the full description and here the link to the thread.

Respondu: responsive implementation framework (alpha) – implements picture and srcset

David Clements

Posted on

Update: After being inspired by the suggestions of Florian Rivoal (editor of the CSS Media Queries spec) and Markus Ernst over on the whatwg mailinglist Respondu now supports a new hybrid format that combines picture and srcset in a way that reduces markup and increases flexibility for the best of both worlds.

References:

Hi all,

I’ve developed a basic framework that allows us to implement a responsive technique (e.g. picture, srcset or any new/improved ideas), it’s called Respondu https://github.com/davidmarkclements/Respondu

(if anyone has a better name, let me know :D ).

Examples can be found at http://respondu.davidmarkclements.com/

One of the main features of this framework is that it defers the loading of assets (e.g. src’s etc) until it’s finished processing (this includes script tags in the body). It achieves this using the noscript technique (discovered by filament group (?)) – except instead of wrapping img’s individually we wrap the whole body and then use a cheeky hack (dynamically wrap it in a style tag) to pull the noscript contents out (for browsers that wipe noscript contents on render).

Benefits,

  1. supports non-js clients (e.g. search bots, screen readers etc.)
  2. no wasted HTTP-connections or bandwidth
  3. it’s relatively unintrusiveness, you simply wrap it round all your body code
  4. extendible, you can easily create you own implementations

Once the final spec is implemented by vendors, the technique can be used as a fallback for
browsers without support for responsive, whilst also in turn falling back again for browsers without Javascript.

Currently, Respondu has picture and srcset implementations available, for instance here’s srcset:

<!DOCTYPE HTML>
<html>
<head>
<style>img {width:100%} /* use fluid layouts */</style>
<script src=js/R.js></script>
</head>
<body>

<script>window['#R']('srcset');</script>
<noscript>

<img src="images/photo.jpg" srcset="images/photo.small.jpg 320w, images/photo.small@2x.jpg 320w 2x, images/photo.medium.jpg 640w, images/photo.medium@2x.jpg 640w 2x, images/photo.large.jpg 1280w, images/photo.large@2x.jpg 1280w 2x, images/photo.xlarge.jpg 20000w, images/photo.xlarge@2x.jpg 20000w x2">

</noscript></style>

</body>
</html>

So far, I’ve tested it in Chrome, IE8, iOS Safari, and Firefox.

If anyone would like to test in other browsers (ie7, ie9, OSX Safari, Opera) please be my guest, you beautiful person.

Respondu is currently alpha as there’s a few things to do for smooth script integration (getting it to “just-work” with domready stuff), I’m totally sure the code could be tidier, and more optimized – any contributions to the code base or posted issues are invited, and warmly welcomed.

See the github page for more details!

https://github.com/davidmarkclements/Respondu

An update on responsive images

Philip Ingrey

Posted on

Hey everyone,

I guess a lot of you guys aren’t signed up to the whatwg mailing list so I thought it’d be good to give an update on what’s going on. I don’t claim to be an authority, in fact I’m sure my knowledge is flawed; Also things are moving so fast that any information here might be plain wrong by the time you read it! (please leave a comment if you see an error)

How srcset really works (-ish!)
When an image tag reads <img src=”mobile.jpg” alt=”" srcset=”medium.jpg 600w, desktop.jpg 1000w”> what this means is: default to mobile.jpg, unless the viewport width is greater* than 600px then the browser is free to choose mobile.jpg or medium.jpg as it sees fit. Once the viewport width is greater than 1000px the browser is free to choose any of the three images.

For a much better explanation read Bruce Lawson’s great html5doctors post

Tab’s suggestion
On the mailing list Tab Atkins (& others) suggested the following CSS like notation might be more helpful:
<img src=”mobile.jpg” alt=”" srcset=”medium.jpg min-width:600px, desktop.jpg min-width:1000px”>
And the browser would be free to choose any image where it’s corresponding media query is satisfied (this is different to <picture> where the browser gets no choice). Also only a subset of media queries would be allowed (min-width, max-width and maybe min-pixel-density). This is more friendly to developers that know CSS, it’s more readable and allows for units other that px to be used. On the downside it’s slightly more verbose.

Going forward
I’d suggest you all join up to the mailing list, but if you don’t want to receive dozens of emails a day, feel free to leave comments/thoughts below.

* there is discussion whether “600w” should reference the maximum viewport or minimum viewport, however for the sake of brevity I’m going to just to talk about minimum.

Shouldn’t we be defining content, not context?

Jacob Mather

Posted on

AlphaXtreme, LLC

One of the points that I have seen raised against Matt’s most recent suggestion involving templates has stuck a major chord with me: indirection.

A Warning

What I’m about to suggest seems quite “off the wall” in relation to what has been discussed prior to now. I believe some of this has already been talked about, but I’m not sure if it’s been looked at in this particular way. Regardless, I’ve warn my flame retardant pants today, so feel free to call me crazy.

A Short Description:

Indirection causes a lot of problems when we think about how users will interact with any of the suggested solutions. Either the indirection is as simple and obvious as Matt Wilcox’s template variables, or as systemic and obtuse as every suggested solutions requirement on basing the image size on the browser size. I believe at one point srcset was planned the way I am about to propose, but I could be wrong.

The Problem:

By relying on things outside of the content to define the content (either head parameters, or browser size, or anything of that nature) we break the ability for that content to be portable, and put a large burdon on future friendliness of the content.

Shouldn’t the content be free of having to know layout implementations?

A Solution:

We should describe which image to use based on the space available for the image to fill. Perhaps this is done with new media queries (container-width, max-container-width, min-container-width), or perhaps it’s done with just making srcset’s dimension controls focus on the containing box instead of the browser’s box. Maybe we work this into a new structure altogether.

Arguments for:

The breakpoints you’ve built for your image today, will still be valid three years from now.

Arguments against:

As far as I can tell, the only argument against this is that we would have to wait for CSS to be processed in order to load content images. To that end: so what?

So what if it takes a little longer to load the content images. It will encourage better/faster css processors. It will encourage leaner CSS. It will encourage compression and concatenation.

Implementation:

What if this worked into a mixture of picture and srcset? Cherry-picking the best of each, so to speak.

<picture alt="description">
  <source src="/images/large-1x/picture.jpg" min-width="800px">
  <source src="/images/large-2x/picture.jpg" min-width="800px" resolution="2dppi">
  <source src="/images/medium-1x/picture.jpg" min-width="400px" max-width="800px">
  <source src="/images/medium-2x/picture.jpg" min-width="400px" max-width="800px" resolution="2dppi">
  <source src="/images/small-1x/picture.jpg">
  <source src="/images/small-2x/picture.jpg" resolution="2dppi">
</picture>

I’m not married to this sort of markup, and I know it looks repetitive, but there are a couple reasons I can think to argue for it:

  1. The intent behind the markup is clearly understandable. I could go with shortening things in some ways, but the point is to make sure it’s understandable what is going on. The less trouble people have adopting (and remembering) something, the better.
  2. It makes sense out of context, because we’re only describing the content.

One of the things I have heard from the srcset proposal is browsers being unsure of what to do (picture proposal wise) when presented with an image without dimensions and sans resolution information. I think giving them the dppi resolves this concern.

There are other concerns I’m not addressing in here that I’m sure will be pointed out, and I apologize ahead of time for that. I think it’s easier if we have a discussion to resolve those than for me alone to try and think them through in this post.

Thanks!

I know, it’s a shift from what I believe has been discussed. I know I may be crazy. This is what had been nibbling at the back of my mind all along though, and I figured it couldn’t hurt to share. Especially with my flame-retardant pants.

srcset added to WHATWG spec

David Goss

Posted on

Thackerays

Despite significant opposition from developers, the srcset attribute has been added to the WHATWG’s HTML spec by Ian Hickson. He has written a long email to the mailing list commenting on many of the issues and explaining his actions.

As the news broke and the uproar began on Twitter, the W3C replied, saying they are “looking at this” and to “stay tuned”.

Expect more developments soon.

More on the srcset proposal

David Goss

Posted on

Thackerays

After a lot of reading over the weekend and a fair bit of discussion on the WHATWG mailing list,  I’ve come to a couple of conclusions:

  1. Initially, I totally misunderstood how <img srcset> works
  2. I still don’t want it, and still do want <picture>

The appeal of <picture> is that you can select different image sources based on any media query, giving you fine control over which version is served under various conditions. Currently this includes viewport width/height, device orientation, pixel density, colour capability etc, and as more media queries arrive (surely there will be a connection speed query sooner or later, and I’d love to see containing element width/height as well) the element becomes even more useful and flexible. Initially, I thought <img srcset> was an attempt to avoid creating a new element by shoehorning this functionality into a new attribute.

In fact, <img srcset> comes from a radically different angle. For each version of the image, we add an entry to the srcset attribute with the filename, and optionally the width, height and resolution (expressed as “1x”, “2x” etc). The user agent then decides which version to serve, based on the metadata we’ve given it and the current conditions on the client (viewport, connection speed, pixel density, user settings, etc). Unlike <picture>, authors aren’t specifying which source to use and when; rather, we’re just telling the user agent what’s available and letting it make the call on its own. <img srcset> allows authors to provide lots of different versions of an image, but affords us no control over when they are used.

Update: I had this wrong, and so did quite a few other people. There’s still some ambiguity, with the spec contradicting itself in places. Jeremy Keith has done an excellent job of clearing up what the parameters in srcset actually do in his post today.

When we practise responsive design, we are trying to give the best possible experience to our users by adapting our websites to work with whatever they are using to access them. <picture>, by design, gives us the control to do this with content images. <img srcset>, by design, takes it away.

Of course, <picture> is imperfect (duplication of alt attributes is annoying, as is the potential duplication of media queries on some pages), but in my view it’s the best path to continue down.

An alternative proposition to picture and srcset, with wider scope

Matt Wilcox

Posted on

Managing responsive designs is hard, so let’s use our <head>

Here is what I believe is the best proposition yet for managing our responsive designs. This includes managing our CSS, JavaScript, and inline <img>’s.

<head>
  <meta name='case' data='breakpoint1' media='min-width:350px' />
  <meta name='case' data='breakpoint2' media='min-width:1000px' />
</head>

Deconstructing the case for breakpoint management in <head>

To re-cap our current problems with breakpoint management; we write our Media Query’s dozens of times in CSS files, we write the same tests in our JS files, and we will soon write them inside every <picture> element too. The same tests, in every case, but with a different “do something if true” instruction. That’s wasteful in terms of repetition, becomes very hard to manage, requires continuous re-processing of a test that never changes, and is future unfriendly. Read more detail here.

So why does that code up there solve all these issues?

At first glance, that code is going to cause many people a few frowns. We are not used to seeing this sort of thing – meta elements are supposed to describe a property of the URI aren’t they? Well, no. We already set meta elements that do not describe a property of the loaded URI – all of us do. Every time we set <meta name=”robots” content=’index,follow’ /> or any associated instruction. Or when we tell Google Translate to not run on the page. Or when we tell IE not to use its picture menus. These are all examples of using a meta tag to control the behaviour of some software that’s consuming the URI’s HTML, and not to describe properties of the page itself.

What the code above does is set ‘case’ to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it – the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.

Some people will be uncomfortable with having the queries in the head, but I’d say putting the queries into the CSS is, most of the time, backward – it’s just that we’re used to doing it that way so it makes a certain kind of sense. Remember that the order we actually build a site goes like this:

1) Consider a device size
2) Create a design for that size on paper or in Photoshop
3) Write the code to implement it
4) Increase device size and goto 1

All of our code is actually hanging off the same media query breakpoints, because they’re the design breakpoints. So why re-define the same tests in each technology rather than do it once in HTML and have the CSS and JS just reference them? We could still do specific tasks in the “old” way, if desired.

How would we use these <meta> elements?

In HTML

Addressing first how we might use it to control <img/> in our mark-up:

<body>
  <img src='/content/images/{case}/photo.jpg' alt='' />
</body>

What has this bought us?

  1. Well, we have a single image element with no custom properties or other code, which will adapt to any number of breakpoints you want to declair, without ever adding another character to the image code.
  2. We have something that is backward compatible right now: either create a directory called “[case]” so that a file exists there, or if you want to be cleverer about it, set your server to alias [case]’s path to an already existing path.
  3. The image is cachable by proxies and CDNs because the source for each version of the image has a unique URI.
  4. UPDATE: By using {} instead of [] this solution is actually complying with the URI Template too (See the RFC) – thanks Brett!

Are there any drawbacks?

None that I can see. Even with the current proposal, we should never change the alt attribute because all resources are supposed to have the same semantic meaning.

In CSS

Rather than writing endless clauses like this, where a test must be performed each time:

@media only screen and (min-width: 700px) { ... }

We could write this instead:

@media (case: breakpoint1) { ... }

What has this bought us?

  1. We are abstracting the test itself away from the block of code that defines a response. This means if we decide to change the breakpoint condition, we do it once in the <head> and everything else works automatically.
  2. We reduce the number of tests required of the browser. It’s not re-running a test, it’s instead checking the value of case – which has already been computed.
  3. We have smaller code. Yeah, i know, it’s a tiny point but it’s a benefit non the less.

Are there any drawbacks?

Not that I can see, because you can still carry on using existing syntax if you like, this is just an additional capability we may want to take advantage of. It can also be used in all the same ways you use any existing media-query.

In the case of JavaScript

It’s largely the same as for CSS. Instead of doing its own tests, it can just use whatever value is stored in the ‘case’ node. There is prior art for this: the behaviour here would be exactly the same as the wonderful shiv that a lot of people are now using Conditional CSS, but it’d check against the meta element and not the body:before pseudo element.

So why might this not work?

I’ve only analysed this from the perspective of an author. I do not know how much effort it might be for a browser vendor to actually implement, and whether they would be willing to do so. For me, this is the only potential downside to the whole idea – it needs the vendors to implement it. In terms of functionality and benefits of the approach, i can see no downsides to the idea itself.

I think vendors may object initially to the idea of browsers having to do this:

1) detect the existence of a specific meta tag

2) if it exists scan all src=”" properties for the variable string to replace with the variable value

If no meta tag was there, it wouldn’t have to do anything with the src strings.

How likely are variables?

There is a history of our core technologies not supporting Variables, but there is a trend of adding them recently:

1) We now have variables in CSS ( http://dev.w3.org/csswg/css-variables/ )
2) We now have variables in URIs ( http://code.google.com/p/uri-templates/ )
3) We’ve always had variables in JS

So, HTML’s the last one standing without support for variables.

———–

N.b., This post is a re-post from a blog entry I wrote, it was suggested on Twitter that the Community Group should see it. Source: http://mattwilcox.net/archive/entry/id/1091/

The suggestions here are a mix from an older suggestion of mine which worked with <picture>, and the ideas of Denis LeBlanc

———–

UPDATE: Philip Ingrey has written a polyfil for this soultion!

Responsive image element proposed by the WHATWG

Mathew Marquis

Posted on

Filament Group

After months of discussing possible solutions for responsive images on the WHATWG mailing list, I discovered yesterday that another, different syntax was proposed on the WHATWG IRC channel. Additionally, when I joined the discussion, it became apparent that the majority of the WHATWG leads present in IRC weren’t aware of the proposed picture element—or, in fact, this Community Group. Thankfully, after being informed about our efforts, I was assured they would attempt to incorporate our input.

The majority of the people involved in the IRC discussion had not heard of our Community Group, and —though none of us were contacted for input when the time came to propose solutions.

So we’re all in the loop here, the currently proposed solution is a new set attribute on the img element. If that link’s not working for you, the proposed syntax is:

<img src="face-600-200@1.jpg" alt="" set="face-600-200@1.jpg 600w 200h 1x, face-600-200@2.jpg 600w 200h 2x, face-icon.png 200w 200h">

To recap, the markup pattern proposed by this community group is as follows:

<picture alt=""> <source src="mobile.jpg" /> <source src="large.jpg" media="min-width: 600px" /> <source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" /> <img src="mobile.jpg" /> </picture>

I noted a number of concerns with the new, WHATWG-proposed img syntax in IRC, namely that it seems far less developer-friendly than the proposed picture markup structure.

But now? Now we need to hear from you.

The WHATWG, having now realized there’s been significant work being done in this group, wants to hear what you think. I’ve been asked to provide citations of developer opinion on the topic, so I’d like to ask you to sound off in the comments:

Does picture seem like something you’d like to write, or does the img set attribute seem more accessible to the average developer?

Additionally, if you have more thoughts on the topic you’d like to share with the WHATWG, here’s how to continue the discussion:

If you have a clear argument for or against the proposed syntax here, for or against the picture element, or a decided preference between the two: it seems like now is our opportunity to have our voices heard.

If you care about responsive images, I’d love for you to join in.