How widely should HTML's 'aspect-ratio' presentational attribute be applied?

[tabatkins]

In whatwg/html#6032, I'm fixing HTML to define that <img width height> constitutes an 'aspect-ratio' presentational hint (setting 'aspect-ratio' at the presentation-hint layer, lower specificity than any rule). (Previously, this was defined as width/height attributes actually giving the element an intrinsic aspect ratio.)

The text I'm replacing only defined this mapping for img elements, but it seems reasonable that this should apply to all element that currently process 'width' and 'height' attributes as presentational hints: embed, iframe, img, object, and video. Does this sound reasonable to other people?

[fantasai]

No, it should apply to video, but embed/object/iframe often represent elements that have a width and a height but no aspect ratio. So it should not map to those.

I feel like there's existing discussion about this over in the WHATWG space...

[zcorpan]

What @fantasai said.

Although embed and object can be an image (and so have an intrinsic aspect ratio), they can also be a nested browsing context (no intrinsic aspect ratio).

There is however input type=image which could map width/height to 'aspect-ratio'.

For canvas, the spec currently says

The intrinsic dimensions of the canvas element when it represents embedded content are equal to the dimensions of the element's bitmap.

https://html.spec.whatwg.org/multipage/canvas.html#the-canvas-element:intrinsic-dimensions

[fantasai]

So basically img, input type=image, video, and canvas should have an aspect-ratio mapping, but none of the others should.

[css-meeting-bot]

The CSS Working Group just discussed How widely should HTML's 'aspect-ratio' presentational attribute be applied?, and agreed to the following:

• RESOLVED: apply aspect ratio pres hint to img, <input type=image>, video, canvas

The full IRC log of that discussion

<heycam> Topic: How widely should HTML's 'aspect-ratio' presentational attribute be applied?
<heycam> github: https://github.com//issues/5608
<heycam> TabAtkins: Emilio brought up in the HTML spec that it would make sense to make the aspect-ratio attribute integration from width/height setting intrinsic size, to being them setting an intrinsic ratio pres hint
<heycam> ... I wrote the spec text for it
<heycam> ... Domenic asked which elemetns it should apply to
<heycam> ... prev spec text applied to img specifically
<heycam> ... (side discussion about <picture>)
<heycam> ... but there are other elements that we do use width/height on
<heycam> ... video, possibly embed/object
<heycam> ... canvas, <input type=image>
<jensimmons> q
<jensimmons> q+
<heycam> ... first question, does it make sense to widen the spec text from the previous img/picture only, and if so, which elements should we expand it to?
<heycam> ... I think we should, and go with elika's list
<heycam> ... embed/object applying an intrinsic ratio doesn't always apply)
<emilio> q+
<heycam> jensimmons: to remind everyone, this is about improving the experience for users while the page is loading
<heycam> ... the intention is that it has no affect on layout after these assets have loaded
<Rossen_> ack jensimmons
<heycam> ... once an image has loaded, it should get the same layout it would've had
<heycam> ... should work the same way for video
<heycam> ... they do have an intrinsic aspect ratio
<heycam> ... should apply to any HTML element where this is true
<heycam> ... so does not apply to a typical iframe, since they don't have intrinsic aspect ratio
<heycam> ... it's also true that embed/object can sometimes have an intrinsic aspect ratio
<florian> q+
<heycam> ... but if there are complications it's not critical
<heycam> emilio: I agree with this
<Rossen_> ack emilio
<heycam> ... when we initially implemented this for img, we still didn't have the compat requirements
<heycam> ... I think this is pretty reasonable
<heycam> florian: makes a lot of sense to me
<Rossen_> ack florian
<heycam> ... given the text you're replacing didn't apply to these things, is the compat story different for img and the things that are like it?
<heycam> ... or it all falls into the same bucket?
<heycam> emilio: when we did it for img, we override the aspect ratio, but people put wrong values
<heycam> ... the auto value is like a low priority hint
<heycam> ... I think the compat impact is going to be extremely low
<heycam> florian: canvas loads a bit differently from these other things
<heycam> ... you don't load an external file
<heycam> TabAtkins: intrinsic size is based on the backing store
<heycam> florian: script controlled? and so if the script hasn't run yet it's a similar situation?
<heycam> myles: it's based on the attributes on the element
<heycam> TabAtkins: you're right
<Rossen_> q?
<heycam> ... but it would still be consistent with images
<heycam> florian: less useful but still doesn't hurt
<heycam> Rossen_: in the case of picture/srcset, does it come from the first image?
<heycam> emilio: I think it would be the actual <img> inside the picture
<heycam> ... but there's another PR to make width/height apply to src
<heycam> ... there's no precedent for other elements' attributes affecting intrinsics
<heycam> TabAtkins: but that's behind discussed elsewhere
<heycam> s/behind/being/
<TabAtkins> img, input type=image, video, canvas
<heycam> RESOLVED: apply aspect ratio pres hint to img, <input type=image>, video, canvas
<TabAtkins> <br dur=10min> (back at :10 after your hour)