Intrinsic dimensions

[yoavweiss]

While working on yoavweiss@d0fda08 to fix #82 I realized that the browser doesn't have enough data with current syntax to get the intrinsic dimensions of the image, only its intrinsic width. The height remains a mystery until the image is downloaded (or until Layout says otherwise).

AFAICT, in order to resolve it, we need to add some data in the syntax regarding height. I propose the following:

• Add an 'h' descriptor.
• If authors want the browser to avoid re-layout after image download (assuming CSS doesn't enforce image dimensions), they needs to provide both 'w' and 'h' to at least one of the resources in each source list (so in each srcset attr)
• The proportion between the first/last resource dimensions that include both 'w' and 'h' will be used to calculate intrinsic dimensions of the picked resource (even if it doesn't include both 'w' and 'h')

Now, I might have missed something, or the above proposal may be bad. Let me know if you think that's the case.

[eeeps]

I don't want to derail the conversation from the problem you're trying to address (re-layouts... for which an 'h' descriptor sounds like a pretty nice solution). But...

Edit: snip, as I then went on to derail the discussion (: Moved to #86.

As an author, being able to add an optional 'h' to one of the sources in order to define the aspect ratio and prevent reflows sounds like an easy win. So this SGTM.

[yoavweiss]

@eeeps - I think this is an important discussion, but can you please open a new issue regarding that? (since it's a separate subject from intrinsic dimensions calculation). It'd enable to keep both topics' discussions on subject.

Thanks :)

[igrigorik]

Add an 'h' descriptor.

srcset does provide height descriptor [1]. That said, one of my takeaways from the resp-img meetup back in September was that h was a very likely candidate to be dropped from the srcset spec. Multiple people (e.g. Boris, who implemented the srcset polyfill) pointed out that the selection algorithm when both w and h are present is a nightmare and is near impossible to figure out. Similarly, when polling the room, we couldn't come up with any compelling use cases for h alone.

But even with that aside, isn't the intent of srcset w and h descriptors to capture "maximum viewport width/height", not describe intrinsic image dimensions? In other words, this seems like the wrong mechanism to begin with... or am I missing something?

[1] http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/#additions-to-the-img-element

[tabatkins]

@igrigorik Don't be confused by the surface similarity with HTML's srcset syntax - the (unimplemented by anyone) w/h descriptors it uses there are compact ways of writing MQs. In <picture>, the w unit (and potentially an h unit) are the physical sizes of the image source, in image pixels. Completely different things.

[igrigorik]

@tabatkins ah, I see... Indeed, didn't catch that. Knowing that, the examples make a lot more sense - #5 in particular. FWIW, it may be worth calling out this difference more explicitly in the spec.

Since I'm two steps behind, let me see if I grok the proposal via an explicit example:

  <picture>
    <source sizes="(max-width: 30em) 100%, (max-width: 50em) 50%, calc(33% - 100px)"
            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 my device max-width is 30em (with 16px default font size) and my DPR is 2.0, then:

• image is intended to be displayed at 100% viewport width
• 30em * 16px * 2DPR = 960px image (ideally)
• UA downloads pic1200.jpg (and downscales on the client)
• UA uses 200h to infer the ratio and (unless CSS overrides it) reserves 480x240px box for the image

Does that look about right?

P.S. Still need to grok how this would also work with sizes + w/h (ala #86).

[tabatkins]

Yup, that's exactly right.

[zcorpan]

Do we need this? Traditionally you would just use width/height attributes on the img element. Is that not good enough?

[zcorpan]

Hmm. Nevermind, that doesn't work for art direction.

[yoavweiss]

Yeah. This bug would be resolved with @tabatkins's proposal

[zcorpan]

I think it is slightly cryptic that a hight descriptor on one image source magically sets the aspect ratio for other image sources also. I don't think that is especially clear for authors. From the example above, it looks to me like the height descriptor is missing from some of the sources. Moreover, the calculated aspect ratio might not exactly match the other image's actual aspect ratios, due to rounding, resulting in the intrinsic height being slightly off.

I think if we want to specify the aspect ratio for all the sources, it would be clearer to have a separate attribute (still subject to rounding). Or use the height descriptor for each image source individually.

[yoavweiss]

Mandating authors to specify height on every image can become cumbersome quick.
Deriving aspect ratio from the first (height, width) tuple is terser, but (as you say) that's not always an advantage...

All in all, I think the best would be to conclude ratio from first tuple, and override it with more specific ones if provided by author, but since it's a matter of authoring convenience (and I'm far from being an expert on the subject or a day-to-day author), I'm not hung up on any particular syntax as long as the browser can conclude the intrinsic size.

[Wilto]

Alright, after a bunch of discussion in the IRC channel, it’s looking like the prevailing opinion is this: for situations where the aspect ratio of all sources in a source will match (+/- rounding errors), <source aspect[-]ratio="16/9" sizes="100%; small.jpg 400, med.jpg 800, big.jpg 1600"> has us covered, with the new attribute using values from http://www.w3.org/TR/css3-mediaqueries/#aspect-ratio

In the event that the sources have differing aspect ratios, adding in-syntax overrides gets clunky in a hurry. We have a handful of votes for relegating differing aspect ratios to different source elements, since it arguably falls under the “art direction” case anyway—it’s not as terse, but this is sort of a special case.

[aarongustafson]

100% agreed on that approach.

On Wed, Feb 26, 2014 at 1:17 PM, Mat Marquis notifications@github.comwrote:

Alright, after a bunch of discussion in the IRC channel, it’s looking like
the prevailing opinion is this: for situations where the aspect ratio of
all sources in a source will match (+/- rounding errors), <source
aspect[-]ratio="16/9" sizes="100%; small.jpg 400, med.jpg 800, big.jpg
1600"> has us covered, with the new attribute using values from
http://www.w3.org/TR/css3-mediaqueries/#aspect-ratio

In the event that the sources have differing aspect ratios, adding
in-syntax overrides gets clunky in a hurry. We have a handful of votes for
relegating differing aspect ratios to different source elements, since it
arguably falls under the “art direction” case anyway—it’s not as terse, but
this is sort of a special case anyway.

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

[zcorpan]

LGTM. The dash should be omitted in the attribute name to match HTML's naming convention.

If the value is invalid, the attribute should just be ignored.