out of my league on this one – John Marstall https://theiconmaster.com Fri, 24 Aug 2012 15:05:46 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.2 Give img set a chance https://theiconmaster.com/2012/05/give-img-set-a-chance/ Thu, 17 May 2012 02:33:12 +0000 http://theiconmaster.com/?p=309 two competing proposals, feelings are hurt, etc. If we're going to improve web images, these two assumptions seem sensible to me:
  1. One should modify the <img> tag as little as possible. Web designers know how the <img> tag works. It's not the most elegant thing imaginable, but it's familiar. We should work with what we've got.
  2. The new syntax should be as compact as possible. <img> tags get used a lot. Anything that gets added to <img> could potentially need to be added to a page dozens of times. We should save ourselves some keystrokes.
Let's look at the contenders. First, the offering from the Responsive Images Community Group, the <picture> element:
<picture> <source src="image.png" /> <source src="image@2x.png" media="min-width: 600px, min-device-pixel-ratio: 2" /> <img src="image.png" /> </picture>
To me, this looks like a pain. It requires the new tags be wrapped around every <img> element which needs to be made responsive (likely all of them). The <source> has to be spelled out for every alternate version. And while the "min-width" and "min-device-pixel-ratio" syntax matches that of a media query stylesheet, in a media query stylesheet these need only be typed once per media type. With the <picture> element proposal, those queries will need to be added to every image. Below is the version Apple suggested, "img set." And let's just acknowledge the elephant in the room: iOS retina devices are the entire reason this conversation is going on. Giving Apple's proposal a little extra weight may not be unreasonable.
<img src="image.png" set="image.png 600w 200h 1x, image@2x.png 600w 200h 2x" />
Hey, this looks pretty compact by comparison. It only requires a new attribute on the familiar <img> tag. Think about that: it's just one tag. (I count four in the alternative, excepting the closing tag.) Using "w" and "h" for width and height is unusual in web development but easy enough to remember. To me, this looks like a winner. One of the arguments in favor of the <picture> element is that its syntax more closely matches that of the HTML5 <video> and <audio> elements. But this is a bad comparison. It's fairly rare for video or audio to be embedded in a page more than once; while a single page, again, could contain dozens of images.]]> Oh the drama.

Web standards wonks are hashing out a new standard for serving the appropriate version of an image given the resolution of a user’s device. Unfortunately, that single standard has turned into two competing proposals, feelings are hurt, etc.

If we’re going to improve web images, these two assumptions seem sensible to me:

  1. One should modify the <img> tag as little as possible. Web designers know how the <img> tag works. It’s not the most elegant thing imaginable, but it’s familiar. We should work with what we’ve got.
  2. The new syntax should be as compact as possible. <img> tags get used a lot. Anything that gets added to <img> could potentially need to be added to a page dozens of times. We should save ourselves some keystrokes.

Let’s look at the contenders. First, the offering from the Responsive Images Community Group, the <picture> element:

<picture>
<source src=”image.png” />
<source src=”image@2x.png” media=”min-width: 600px, min-device-pixel-ratio: 2″ />
<img src=”image.png” />
</picture>

To me, this looks like a pain. It requires the new tags be wrapped around every <img> element which needs to be made responsive (likely all of them). The <source> has to be spelled out for every alternate version. And while the “min-width” and “min-device-pixel-ratio” syntax matches that of a media query stylesheet, in a media query stylesheet these need only be typed once per media type. With the <picture> element proposal, those queries will need to be added to every image.

Below is the version Apple suggested, “img set.” And let’s just acknowledge the elephant in the room: iOS retina devices are the entire reason this conversation is going on. Giving Apple’s proposal a little extra weight may not be unreasonable.

<img src=”image.png”
set=”image.png 600w 200h 1x,
image@2x.png 600w 200h 2x” />

Hey, this looks pretty compact by comparison. It only requires a new attribute on the familiar <img> tag. Think about that: it’s just one tag. (I count four in the alternative, excepting the closing tag.) Using “w” and “h” for width and height is unusual in web development but easy enough to remember. To me, this looks like a winner.

(Update: it’s worth noting that both specifications are still in flux and at least in the case of “img set,” some of the components may be optional. Imagine the following:

<img src=”image.png”
set=”image.png 1x,
image@2x.png 2x” />

Now that’s nice.)

One of the arguments in favor of the <picture> element is that its syntax more closely matches that of the HTML5 <video> and <audio> elements. But this is a bad comparison. It’s fairly rare for video or audio to be embedded in a page more than once; while a single page, again, could contain dozens of images.

]]>