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 [email protected] 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).

[yoavweiss]

@zcorpan: Do you propose that we start shipping srcset's 'w' descriptor, and only then see if 'h' should be added? (either for the purpose of height based images, or to provide authors with means to set the image's display dimensions to avoid re-layouts (per #85 ))

[zcorpan]

Yeah. Actually I think we should wait with adding new stuff until what we have now is implemented in WebKit, Blink, Gecko and IE. If we add too many things we risk vendors rejecting the whole thing. "Baby steps"...

[Wilto]

+1 to shipping piecemeal, so long as we keep in mind that it might make feature testing a little more complicated (we can test for sizes independent of picture easily enough—testing for h support separate from w support might get complicated). If there’s anything we can do to mitigate that complication, I am 100% into it.

[zcorpan]

That's where future-compatible error handling comes in. It might be a bit ugly to test for it, and #152 would make it async, but it should be possible.

For instance <img srcset="foo 1h 1x"> would load foo if h is not supported but not if it is.

[yoavweiss]

A use-case that came up on twitter RE 'h' descriptor support: this site displays height constrained images, and width only sizes makes little sense for it.

[tigt]

+1 on adding an h descriptor. I'm working on a project where images would act like contain based on a larger container (to make a long story short, it's <img> inside <foreignObject> inside inline SVG), and height-constraining is critical.

[anselmh]

Or in short it could become handy when object-fit: contain (or similar techniques as mentioned above) is in use. I think photo galeries are the main target for this.

[ckrack]

+1 for adding contain / cover keywords.
I am not sure an h descriptor is necessary if we have those.

[tigt]

It's possible to hack this logic in today, but it's ugly.

<img sizes="(min-aspect-ratio: 4/5) 80vh">

[neptunian]

+1 for h in srcset on the img tag. The browser currently fetches the wrong image for a height constrained Lightbox viewer which, of course, isn't meant to scroll. h is the height of the viewport. In order to find best size and only providing widths i have to calculate the best width myself.

[zcorpan]

Let's continue this discussion in whatwg/html#2973

Links to sites that would benefit from this, so a solution can be evaluated against real-world cases, would be very useful.