W3C home > Mailing lists > Public > public-respimg@w3.org > December 2016

Re: aspect ratio as an attribute

From: Simon Pieters <simonp@opera.com>
Date: Fri, 02 Dec 2016 14:34:47 +0100
To: tomhodgins@gmail.com, Charles.Hall@mrm-mccann.com, steve@steveclaflin.com, pdescham49@gmail.com, jonathan@jooped.co.uk, gwhit@microsoft.com, yoav@yoav.ws, jason@cloudfour.com, public-respimg@w3.org, alex@bellandwhistle.net
Message-ID: <op.yruin9nridj3kv@simons-macbook-pro.local>
On Tue, 29 Nov 2016 17:03:07 +0100, <alex@bellandwhistle.net> wrote:

> Hi,
>
> I’ve been lurking here and just wanted to put two cents in about  
> aspect-ratio.
>
> Like most devs here I’ve often dreamed of a way to hint the browser  
> about image proportions during page load, but without fixing either  
> dimension.  I often use padding-boxes for above-the-fold images, to  
> limit layout jumps during load. It works, but it’s a pretty miserable,  
> time-consuming pattern. It seems to me that this is the really urgent  
> use case. Speaking as a user, when I accidentally tap on the wrong link  
> because an image just above my finger has suddenly loaded, the  
> irritation factor is really high.
>
> Putting together lots of what’s been said, it seems that solution needs  
> to be:
>
> 1) Attribute-based. The CSS aspect-ratio proposals solve different, more  
> complicated problems. They are harder to understand, harder to  
> implement, harder to polyfill. I don’t want to wait five years. Since  
> the ratio is a property of the asset, it should be marked up with the  
> image/video.
>
> 2) Only a hint during load. Once the asset (metadata) is loaded  
> successfully, the actual aspect-ratio of the asset takes over. If the  
> image fails to load, the image’s box retains the hint. This fails  
> gracefully, in cases of sloppy authoring. It also allows conventional  
> stretching via CSS, as Tommy Hodgins has requested. Basically, it should  
> do its job and then get out of the way.
>
> 3) Distinct from sizes attribute. I don’t see a way to add onto the  
> existing sizes syntax without backwards-incompatible changes. zcorpan,  
> correct me if I’m wrong here? Even if there were a way to do it, I’m  
> worried it would be hard to read.

We can add new things to sizes="" in a backwards-compatible way; the sizes  
parsing algorithm was specifically designed to make this possible. In  
particular, items in the list that fail to parse get dropped, so the  
subsequent items can be used as fallback. For example:

<img
    sizes="(min-width: 40em) something new, (min-width: 60em) something  
new, something new,
           (min-width: 40em) 60vw         , (min-width: 60em)  
80vw,          100vw"
    srcset="examples/images/medium.jpg 375w,
            examples/images/large.jpg 480w,
            examples/images/extralarge.jpg 768w"
    alt="…">


> I suggest a syntax that closely parallels sizes, e.g.:
>
> <img
>    sizes="(min-width: 40em) 60vw, (min-width: 60em) 80vw, 100vw"
>    aspect-ratio=“(min-width: 40em) 3:2, (min-width: 60em) 16:9, 4:3”
>    srcset="examples/images/medium.jpg 375w,
>            examples/images/large.jpg 480w,
>            examples/images/extralarge.jpg 768w"
>    alt="…">
>
>
> This has the advantage of being familiar, and handles the the  
> “art-direction” use case easily.

If you have different aspect ratios for different breakpoints, then you  
are probably doing art direction, and should be using <picture><source  
media>, not srcset+sizes. I think it makes more sense to have a single  
aspect ratio apply to all assets in `srcset`.

-- 
Simon Pieters
Opera Software
Received on Friday, 2 December 2016 13:35:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 December 2016 13:35:33 UTC