Re: aspect ratio as an attribute

I'd like to +1 Greg's concerns regarding adding this to HTML. There's no
real technical reason to do that (i.e. there are no performance benefits to
doing so) and the aspect-ratio is required for display of all elements, so
it makes sense for it to be part of CSS.

On Fri, Dec 2, 2016 at 2:34 PM Simon Pieters <simonp@opera.com> wrote:

> 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
>