Re: aspect ratio as an attribute

I agree with two caveats. First, for better or worse this will break enough
of the internet that I wouldn't be surprised if the browser guys balked at
it. Second, you would need to account for srcset; they may all likely have
the same aspect ratio, they will not have the same dimensions.

Adding aspect may be a sufficient solution for what we wish to accomplish.

On Dec 19, 2016 3:17 AM, "Simon Pieters" <simonp@opera.com> wrote:

> On Mon, 19 Dec 2016 04:29:18 +0100, L. David Baron <dbaron@dbaron.org>
> wrote:
>
> On Thursday 2016-12-15 22:32 +0100, Simon Pieters wrote:
>>
>>> On Thu, 15 Dec 2016 19:49:37 +0100, Greg Whitworth <gwhit@microsoft.com>
>>> wrote:
>>> > > In his original post, Alex said: "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." (emphasis mine)
>>> >
>>> > This is a great point, that said there is nothing stopping us from
>>> > making it so that the CSS property can accomplish this and we should
>>> > ensure that the CSS property is able to do this. I would prefer to not
>>> > have an HTML attribute that behaves differently than the CSS property.
>>>
>>> It would not need to behave differently. If there are good reasons to
>>> have
>>> an HTML attribute (I recall someone mentioning lint checkers being able
>>> to
>>> check HTML attributes but not so much parse and apply CSS), we can
>>> define it
>>> as a "presentational hint" attribute that just maps to the CSS property.
>>> A
>>> lot of HTML presentational attributes do this.
>>>
>>
>> I don't think this is necessarily the desired approach here.
>>
>> I think it was a design mistake in the early days of HTML that the
>> height and width attributes on img overrode the intrinsic sizes of
>> the image, rather than just being hints for when the image was
>> loading.  This has led to many unintentionally-scaled images, and
>> a decent number of images that use way more bandwidth than needed.
>>
>> Had that mistake not been made, mapping the height and width
>> attributes on img into the 'height' and 'width' CSS properties
>> wouldn't have made sense.  They would have instead mapped to
>> intrinsic dimensions (as defined in
>> https://drafts.csswg.org/css-images/#sizing-terms ).
>>
>>
>> Wanting a way to describe the intrinsic size of an external resource
>> so that relayout doesn't happen when the resource loads is a useful
>> goal.  Making the mechanism for that have effects after the resource
>> has loaded, or interacting with the CSS model in any way other than
>> providing intrinsic dimensions (as defined above, including
>> intrinsic aspect ratio) prior to the resource being loaded,
>> complicates the mechanism and causes it to have undesired effects
>> for the simple (and important) use case of avoiding relayout.
>>
>> This seems like it might become more important as developers do more
>> responsive things with images using some of the new mechanisms
>> available in CSS (e.g., object-fit/object-position, flexbox, grid,
>> and correct implementation of min/max-height/width).
>>
>
> Yeah, I think you are right. We also still have an opportunity to map to
> intrinsic dimensions for <source>.
>
> Still, the behavior you describe could also be (new) CSS properties,
> possibly useful for generated content.
>
> --
> Simon Pieters
> Opera Software
>