Remove specification of intrinsic aspect-ratio, and instead map width…

[tabatkins]

…/height to a presentational property. Fixes #5907

• At least two implementers are interested (and none opposed):
  • Firefox (see Define image intrinsic aspect ratio by mapping to the aspect-ratio property. #5907)
  • Chrome (Remove specification of intrinsic aspect-ratio, and instead map width… #6032 (comment))
• Tests are written and can be reviewed and commented upon at:
  • width/height creates 'aspect-ratio' preshint web-platform-tests/wpt#26010
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1137004
  • Firefox: (already works this way)
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=217529

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/rendering.html ( diff )

[tabatkins]

Huh, how do I give a <code> element that's not meant to link to anything at all? Wattsi is automatically interpreting it as a link and falling over as a result.

[domenic]

Empty data-x="". Sorry :-/.

[domenic]

Seems reasonable editorially. I guess since there's discussion of implementer buy-in, this will want tests.

/cc @emilio @zcorpan

[tabatkins]

Yup, just hadn't gotten to the test yet yesterday. WPT PR open now.

[domenic]

Awesome, tests look to be in order. Ping @cbiesinger to confirm that Chrome intends to implement this?

[cbiesinger]

I am interested in implementing this.

[domenic]

@tabatkins sorry, found something else. Which elements is this for? Is it just img, or is it for embed, iframe, img, object or video (like the width="" and height="" properties)? The sentence you added should state specifically, like the one previous to it does.

[tabatkins]

Ah, good catch. The deleted text only applied it to img, but I'm unsure if I should reproduce that limitation; it does seem good and reasonable to put it on all the sizable replaced elements.

[zcorpan]

Related: #5894 (one of these will need to rebase) cc @yoavweiss

[cbiesinger]

FWIW--

As far as I can tell, this is a behavior change for error images / images without src in that this will now apply to them but didn't (I think) previously (I noticed this due to a failing test while implementing). I think that's fine but wanted to point it out.

[zcorpan]

@cbiesinger hmmm, is that both quirks mode and standards mode?

I believe that in standards mode, img when showing alt text should be a non-replaced inline element by default, per spec.

If the element is an img element that represents some text and the user agent does not expect this to change
The user agent is expected to treat the element as a non-replaced phrasing element whose content is the text, optionally with an icon indicating that an image is missing, so that the user can request the image be displayed or investigate why it is not rendering. In non-graphical contexts, such an icon should be omitted.

https://html.spec.whatwg.org/multipage/rendering.html#images-3

(Not sure why it says "phrasing element" instead of "inline element"...)

https://drafts.csswg.org/css-sizing-4/#propdef-aspect-ratio says that 'aspect-ratio' doesn't apply for inline boxes.

So, AFAICT, the aspect-ratio preshint should do nothing (in no-quirks mode and limited-quirks mode) when showing the alt text. The intention here is to let the alt text flow with the text like normal text, so applying the aspect-ratio seems bad.

[cbiesinger]

I didn't actually test alt text; I tested an error image without text (<img src=nonexistant>)

[zcorpan]

@cbiesinger OK. That seems fine. That case falls into the second branch:

If the element does not represent an image and either:
...
the element has no alt attribute, or
...
The user agent is expected to treat the element as a replaced element whose content is the text that the element represents, if any, optionally alongside an icon indicating that the image is being obtained (if applicable). For input elements, the element is expected to appear button-like to indicate that the element is a button.

[annevk]

Are there tests that the width and height properties continue to be impacted as well? I guess they already exist but it might be nice to merge them?

[cbiesinger]

Awesome, thanks, those look great! If we could also get tests for <input type=image> (and maybe it's worth also testing that it does not do anything for, say, <input type=submit>?) then we should be good to merge.

I will add those in https://crrev.com/c/2690929

Are there tests that the width and height properties continue to be impacted as well? I guess they already exist but it might be nice to merge them?

I don't know where/if they exist. However, I'd rather not put them together with these new tests, because currently that file contains various tests for aspect ratios (also that the layout is right).

[domenic]

Alright, I'm happy to merge this. @annevk, I don't quite understand what tests you're asking for (it seems like @cbiesinger does though). Do you think they're necessary before merging, or just something we should also do while we're in the area?

[cbiesinger]

I believe Anne was asking for a test that width="500" gets mapped to width: 500px; (and same for height)