Re: aspect ratio as an attribute

I wish I could. Let me see if I can explain better.

The OP gives this use case: "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".

My understanding of the use case is during the loading of some
arbitrary page you have an image that you want to show and you want it to
take up, lets say 40% of the width of the container its in. You want its
height to be as high as it needs to be to show the whole image.
*Normally,* you'd
do this with CSS by simply setting the width of the img element and leave
the height unchanged. The problem is that during the loading phase, we
don't know the height and until the image loads, the layout is wrong, the
resource loads and the whole page, or a portion, is laid out again, a
costly operation for both the browser and the user's experience.

The common solution is to use padding to make the element the right size.
But this assumes that at the time you are creating the CSS you know what
the aspect ratio of the images.

My point is that if you're talking about a situation where there person
writing the CSS is not the person who creates the images in question (say
we're talking about on store with user contributed photos) we cannot
reliably say what the aspect ratio of the images ARE. We can make a guess
and TELL content creators to make images in that ratio, and you can use
server code to force that aspect ratio (and maybe even do a not crappy job
of cropping it) but if this is what you want to do then the padding tricks
are *sufficient* just a little verbose (use a SASS mixin and the verbosity
is mostly solved).

Tommy Hodgins asks about @media queries. This highlights what I'm trying to
solve. Regardless of the size of the screen or whatever else you might look
at with @media, the aspect ratio of the image resource *doesn't change*.
HugePhoto.png is always 2300x1292px regardless of the device you load it
on.

So if the goal is to tell the browser ahead of time what to expect so that
it can layout the page once and not have to jiggle things around once the
resource loads... the HTML is the best choice for that hinting for the same
reasons it would make very little sense to put in CSS information that this
text block is 230 characters long. How many of us in the days of pixel
perfect table layouts had to tell users that they could only have about 250
characters for the product description or the layout will break or the text
truncated? This is fundamentally the same issue. You CANNOT reliably
dictate the aspect ratio of images any more than we could reliably dictate
the length of a chunk of text (not in ways that make users happy at least).

Content changes more frequently than design *therefore *HTML is generated
later than CSS (typically on a per-request basis vs per-build). Images are
*content* and so is their meta data (dimensions, url, description, color
depth...). That *content* belongs in the container for content.


On Wed, Dec 14, 2016 at 1:21 PM, Yoav Weiss <yoav@yoav.ws> wrote:

> Can you clarify your use-case? Maybe provide a link for a page that
> demonstrates it?
>
> I'm not clear on which parts should be defined (from your perspective) in
> HTML and which in CSS. (e.g. where is width defined? where is height
> defined? Are the images constrained by their container? etc)
>
> On Wed, Dec 14, 2016 at 10:02 PM Adam van den Hoven <adam@littlefyr.com>
> wrote:
>
>> The problem with CSS arises with what you are trying to say. If you are
>> saying that the image should be laid our with a certain aspect ratio, then
>> the value belongs in the CSS. If, however, you are saying that the image
>> resource has a specific aspect ratio then it should come from the resource.
>> The HTML is closest to the resource (in a cms, for example) so it should be
>> able to declare the aspect ratio.
>>
>> If we're talking logos or anything that is constant through the life of a
>> site (relatively speaking) the CSS is fine. But for content, and content is
>> the prime use case I would think, you can't know at "design time" what the
>> aspect ratio of all your resources are because content creators either
>> don't listen or they forget or they just get it wrong (scaling gave them
>> 640 x 479 for some reason).
>>
>> Allowing the aspect ratio to come from HTML, means your CMS, which may
>> already know the aspect ratio, can set it dynamically. Dynamically
>> generating CSS is really difficult on a page by page basis (you end up
>> rendering the page twice so it's slow).
>>
>> To be clear. I'm ignoring the idea of inline CSS on the assumption that
>> if the dominant use case is inline CSS, then you've just chosen awkward
>> syntax for declaring it in HTML. There might be other reasons to do it in
>> CSS I just don't think the arguments against doing it in HTML in this
>> thread are sufficiently argued.
>>
>> Is also possible that I'm missing some piece of information
>>
>>
>> On Dec 14, 2016 2:46 AM, "Yoav Weiss" <yoav@yoav.ws> wrote:
>>
>> 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
>>
>>
>>