Aspect ratios and default styling

[eeeps]

Images and videos both have intrinsic aspect ratios. But given this markup...

<video src="300x150.ogv" />
<img src="300x150.jpg" />

...and this CSS:

video, img { width: 300px; height: 300px; }

<img> and <video> do different things. <img> distorts the JPEG, stretching it vertically to fill its box, while <video> preserves the OGG's native aspect ratio via letterboxing.

There are a number of things you could do here, all possible with the widely-unimplemented object-fit property:

1. Proportionally resize the resource to contain it within the box, padding the non-fit dimension (what <video> does).*
2. Proportionally resize the resource to cover the box, cropping the non-fit dimension.
3. Distort the resource to fill the box without any cropping or padding (what <img> does).
4. Display the image at its intrinsic resolution and crop or pad both the height and width dimensions (what background-image does).

As far as I can tell, except for using background-image in the "rough CSS equivalent" stylesheet, the <picture> spec dosen't specify a behavior here. Should it?

In my view, the only one of the above that makes sense as a default for content images within a responsive layout is containing -- just like <video>. All of the rest have their uses, but seem wrong as the default.

There are probably some very good arguments for keeping <picture>'s default styling as similar as possible to <img>. But a new element seems like a golden opportunity to set things right.

* You can often size an <img> this way using a max/min-width/height property or two, but that only works if you know that your resource is bigger, smaller, wider, or taller than the box. It is currently impossible to resize a content image to be contained within a box if you don't know the resource's intrinsic dimensions relative to the dimensions of that box (without resorting to Javascript).

[anselmh]

That is an important point you hit here. I am in favor of reaching out to the CSSWG here which has to add <picture> to the list of targeted elements for object-fit. This would drastically improve handling of images in responsive designs as the use-cases you mentioned are a daily thing in resp webdesign.

As the support (as far as I understood) does not affect the picture element's specification itself (except we have to add this property to the list of supported properties) I would love to add it and don't think it would be a problem. I hope to hear some additional thoughts about this topic here.

[By the way] I didn't know such thing exists. Also as this topic rises up from time to time in CSSWG's mailing list I don't think too much people know of. Does anyone know which browser supports it and if there are already some feature-requests in UA bugtrackers?

[edit] Also found out about a new CSS3 sizing spec: http://www.w3.org/TR/css3-sizing/ - seems to target similar use-cases.

[nwtn]

Really great point @eeeps. I'd definitely be in favour of having the default styling keeping aspect ratio, similar to video. And good job digging up that CSS3 spec, @anselmh, I wasn't aware of it.

[eeeps]

object-fit is currently only implemented in Opera; they implemented it three years ago:

http://caniuse.com/object-fit

Bugs:

• https://bugs.webkit.org/show_bug.cgi?id=52040
• https://bugzilla.mozilla.org/show_bug.cgi?id=624647
• https://code.google.com/p/chromium/issues/detail?id=236333
• https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ucynLrNXheo/YOSBKSeHuiwJ

It appears that Morten Stenshorne, Opera engineer, is on the brink of landing it in both Blink & WebKit (woo!).

Re: specifying a default in the <picture> spec, I have no idea what's appropriate or not, but the <video> spec seems to do so? "In the absence of style rules to the contrary..."

The CSS3 sizing stuff also seems super exciting ... need to study up.

[anselmh]

Thanks for identifying the proper bugs. It seems Blink will implement it, WebKit has a patch since end of April waiting for review and the only one with no statement at all is Mozilla. Let's share the bug and vote for it!

For our spec we should add a similar phrasing as the video spec does: http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#concept-video-intrinsic-height – anyone feel free to adopt and send a pull-request to our spec here! :)

Regarding the css3-sizing it seems that this covers a similar approach but from the wording it seems the definition in video spec applies to both css specs – sizing and object-fit so that might be secondary to us.

[aarongustafson]

This is great @eeeps! I completely agree on the consensus regarding coverage: default styling keeps the aspect ratio.

On a related side note, has anyone thought at all about how to resposively/responsibly deal with the poster attribute for video? It seems having a similar setup for that would be really beneficial. Does anyone think we should propose such a thing? Perhaps picture as a child tag of video with rel="poster" set on it or something similar. Thoughts?

[anselmh]

@aarongustafson I don't see a reason why we would need a poster image but maybe you do? Do you have a use-case for that?

[aarongustafson]

@anselmh The poster is not for picture, but rather for video.

It’s a bit of a tangent, but it is something I was thinking about the other day with respect to the art direction use case. For videos in a responsive context, it may be useful to allow for different poster crops, especially given that the video can often be bumped to full screen (making the in-page container size less important). In the case of wanting to art direct the poster image for a video, the solution we have come up with for picture makes sense. Similarly, the idea of a srcset option for multiple resolutions of poster image also makes sense from a bandwidth-saving perspective.

This is related because video is essentially an image before it is played. The options and behavior should mirror IMHO.

[anselmh]

@aarongustafson ooh, sorry misunderstood you. As this is tied to video this might be discussed either in another issue or in mailing list of the related working group. I'd propose video supporting srcset which does not add too much bloat to the video element. Having picture inside of video is very confusing I think.

[aarongustafson]

@anselmh I agree, this is probably a topic for the HTMLWG, but I just wanted to raise the question here to get a sense of whether or not anyone feels this is an issue we should try to address after we get picture to a good place.

[yoavweiss]

I agree this is an issue worth taking into consideration. I also agree it shouldn't be part of picture.

I think the best way to resolve this is to add a poster attribute to the various <source> elements (for art-direction, assuming media won't get taken out), and possibly support the srcset syntax inside poster (for resolution-switching)

On Mon, May 20, 2013 at 5:30 PM, Aaron Gustafson notifications@github.comwrote:

@anselmh https://github.com/anselmh I agree, this is probably a topic for the HTMLWG, but I just wanted to raise the question here to get a sense of whether or not anyone feels this is an issue we should try to address after we get picture to a good place.

— Reply to this email directly or view it on GitHubhttps://github.com/ResponsiveImagesCG/picture-element/issues/45#issuecomment-18153771 .

[nwtn]

So:

• @eeeps do you want to work on a pull request as @anselmh suggested to get some language into the spec around intrinsic width/height? If/when that gets accepted, we can close this issue.
• @aarongustafson do you want to create a separate issue about poster, where we can throw around some ideas? since it won't probably be directly related to picture, it should probably be marked as on hold pending some sort of discussion with other working groups.

[eeeps]

Yeah! I started work on that last night -- hopefully I'll be able to give it another look and submit a request tonight.

[aarongustafson]

@nwtn Will do! Traveling at the moment, but I will start a thread soon.

[eeeps]

Changes merged!