The sizes="" attribute only works with width-constrained images

[eeeps]

(Moved from #85, where Yoav was suggesting an 'h' descriptor within the sizes="" attribute for completely different reasons.)

Could such a descriptor also enable height-based selection? I'd be all for that, if there's an elegant way to integrate it into the syntax and if it doesn't complicate the choosing algorithm too much...

<source sizes-h="100vh" srcset="large.jpg 768w 1024h, small.jpg 384w" />

?

While height-constrained layouts (especially responsive ones) aren't common, they're out there. It's much more common to see slideshow modes that constrain on both height and width. To accommodate that sort of thing, though—defining boxes instead of lengths—the syntax + the source selection might have to get a bit hairy...

[tabatkins]

I had planned to do exactly this, but I couldn't come up with an elegant way to do height-based selection. I didn't give it a ton of thought, though - it's very possible for there to be a good method that I just didn't come up with. I'm open to doing this if we can figure it out.

Dealing with both width and height is quite a bit more difficult, but not impossible, particularly if we just allow something like sizes="contain|cover", which is sufficient for slideshow uses I think.

[tabatkins]

Wait, I think I'm dumb. The w unit in a source list isn't used for "selection" directly. It specifies the width of the image source in image pixels; once you know the size of the <img> (either from sizes='' or width='' or whatever), then the image source width is converted to an image source density, and that's what's used in the selection algorithm (which is completely browser-defined).

So, using height in sizes='' would work the same way - you'd have to give a height to all your sources (or we can figure out something with ratios, if we wanna get fancy), and then the browser'll convert that into a density like normal.

Doing cover/contain constraints is identical, except we can't tell a priori whether we'll be calculating the density from the width or the height, as that depends on the relative aspect ratios of the viewport and the image source.

So, concrete proposal:

We add an optional "h" unit to the srcset syntax as well, as proposed above in the OP.

We extend the grammar of sizes, so that each value, rather than just being a <length>, is one of:

1. [width | height]? <length> (defaulting to width - this is the current behavior).
2. [cover | contain] <length>{2}? (defaulting to 100vw 100vh)

The MQ part of sizes values is unchanged.

We change the algorithm to parse a srcset attribute so that if it finds a source with both a w and h unit, it takes the first such one and considers that the canonical ratio. It then fills in the width/height of any other sources that are missing one of the values with that ratio information.

We then change the algo to normalize the source densities to use either the width or the height, depending on the sizes mode, to calculate the density. Sources missing the required dimension are dropped from the list.

[igrigorik]

So, once again, trying a (basic) example.. does this make sense:

  <picture>
    <source sizes="(max-width: 30em) contain 30vh, (max-width: 50em) 50vw"
            srcset="pic400.jpg 400w 200h, pic800.jpg 800w, pic1200.jpg 1200w">
    <img src="pic400.jpg" alt="The president giving an award.">
  </picture>

Let's say I'm on an IPhone 5 (320 x 568px viewport, DPR: 2.0):

• The image should occupy 30% of viewport height
• 568px * 2DPR * 0.3 ~= 340px and based on 400w 200h, the w/h ratio is .5, so..
• UA downloads pic800.jpg (400px height) and downscales on the client

Not sure if I'm using the right markup, but does that look about right?

It seems like there would be a lot of edge cases to cover once we get into both vw/vh in sizes plus cover vs. contain. Maybe it's just me, but I'd love to see some hands on examples... easier to grok than spec language. :)

[tabatkins]

The contain or cover keywords need either 0 or 2 values - 0 just defaults to "the viewport" (identical to specifying 100vw 100vh, 2 defines a rectangle explicitly that it'll fill.

It sounds like, from the following text, that you meant to say height rather than contain. In that case, yes, your interpretation is correct.

[yoavweiss]

@tabatkins - the proposal sounds great (and would also resolve #85).

One question regarding height based sizes - what do we do with percentage based lengths? Can we simply treat them as percentages of the viewport height (so, identical to vh)?

e.g. in (max-width: 30em) height 30%, (max-width: 50em) 50%, is the height 30% part parsed as 30% of the viewport height? Can it be replaced by height 30vh? (Just like the 50% part can be replaced by 50vw)

[tabatkins]

Yeah, definitely.

[eeeps]

This looks great. Modes + sensible defaults, requiring no change to the already-proposed syntax to get the already-propsed functionality... perfect!

Thinking through the syntax and some edge cases with my own example...

<picture>
  <source
    sizes="(width < 32em) contain, (width >=32em) contain 80vw calc(100vh - 10em)"
    srcset="full.jpg 2048h 1024w, half.jpg 1024h, quarter.jpg 512h, eighth.jpg 256h" />
  <img src="eighth.jpg" alt="¡Obama mambo!" />
</picture>

In "cover" or "contain" modes:

• what happens if only zero or one length is supplied? Hunch: the first specified value is always a width, and default values (100vw/100vh) get substituted for any missing values.
• what happens when the srcset dosen't have both an h and a w on any of its sources, and is therefore unable to determine the image's aspect ratio? Hunch: the CSS default replaced element size (300x150 CSS pixels) is used for any missing, needed length. This could lead to some frustratingly silent bugs for authors... but it could also be a way to handle cases where the dimensions supplied in srcset don't match the mode, e.g. <source sizes="width 100%" srcset="pic.jpg 1024h, small.jpg" /> would work equivalently to <source sizes="width 100%" srcset="pic.jpg 300w 1024h, small.jpg 300w 150h" />. Or should that throw some sort of error?

[tabatkins]

Following a cover/contain keyword, you must supply either zero or two lengths. Zero is identical to supplying 100vw 100vh - it refers to the viewport. Supplying only one value violates the syntax, and will cause the <source> to be ignored.

Hmm, good point on none of them having both lengths - you need the aspect ratio so you can compare it with the ratio of the contain/cover rect. I'll have to think on this.

Regarding unneeded dimensions, such as giving a h value when the mode is width, the unneeded dimension is simply ignored. This means that in your first example, the first source has no relevant dimensions, and so is treated as 1x, same as the second source.

However, it will still affect the intrinsic size of the image. Since the canonical ratio is taken from the first such image, in your second example the intrinsic width will be 100vw and the intrinsic height'll be 341.3vw (calc(100vw * 1024 / 300)).

[eeeps]

If we're going to discard <source> elements with the wrong number of sizes lengths in the first case, rather than supplying default values, it probably makes sense to discard cover/contain'd sources whose aspect ratio is indeterminate, too?

[tabatkins]

Oh yeah, that makes sense.

On Sat Jan 04 2014 at 1:25:09 PM, eeeps notifications@github.com wrote:

If we're going to discard elements with the wrong number of sizeslengths in the first case, rather than supplying default values, it
probably makes sense to discard cover/contain'd sources whose aspect ratio
is indeterminate, too?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-31589011
.

[zcorpan]

I think we should wait with adding this until the current proposal has implementation experience. If I recall correctly from the picture face-to-face in Paris last year, there was consensus that height-based selection is rare and does not need to be supported (yet).