Bug 245883

Summary:

<img> elements are always treated as a replaced element

Product:

WebKit

Reporter:

cathiechen <cathiechen>

Component:

DOM

Assignee:

Nobody <webkit-unassigned>

Status:

NEW ---

Severity:

Normal

CC:

cathiechen, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
test-changing-value-of-alt-and-src.html	none
test-changing-value-of-alt-and-src.html	none

Description cathiechen 2022-09-30 07:41:27 PDT

Per [1] and [2], when it is fail to download the image data, <img> element is not always treated as a replaced element. It could be treated as a text or empty inline element, which is depended on the values of attributes src and alt, intrinsic dimensions, and so on.
In WebKit, HTMLImageElement always creates RenderImage as its renderer, and let RenderImage handle the scenarios in which <img> represents alt text or nothing. This could cause some issues like bugs 245136 and 244386. Or <img> does not display the content proper when alt or src attributes change (See test cases in the attachment). Or the alt text is too long, it is not displayed.
Should we consider creating a different renderer for <img> depending on which type of content it represents, and create a shadawRoot to display the alt text if needed?
Something similar to the implementation in Chromium [3].

[1] https://www.w3.org/TR/2016/WD-html51-20160412/rendering.html#replaced-elements-images
[2] https://www.w3.org/TR/2016/WD-html51-20160412/semantics-embedded-content.html#the-img-element
[3] https://codereview.chromium.org/481753002

Comment 1 cathiechen 2022-09-30 07:43:47 PDT

Created attachment 462727 [details]
test-changing-value-of-alt-and-src.html

Comment 2 cathiechen 2022-09-30 07:44:46 PDT

Created attachment 462729 [details]
test-changing-value-of-alt-and-src.html

Comment 3 Radar WebKit Bug Importer 2022-10-07 07:42:17 PDT

<rdar://problem/100897933>

Comment 4 cathiechen 2022-10-07 08:02:47 PDT

(In reply to cathiechen from comment #0)
> Per [1] and [2], when it is fail to download the image data, <img> element
> is not always treated as a replaced element. It could be treated as a text
> or empty inline element, which is depended on the values of attributes src
> and alt, intrinsic dimensions, and so on.
> In WebKit, HTMLImageElement always creates RenderImage as its renderer, and
> let RenderImage handle the scenarios in which <img> represents alt text or
> nothing. This could cause some issues like bugs 245136 and 244386. Or <img>
> does not display the content proper when alt or src attributes change (See
> test cases in the attachment). Or the alt text is too long, it is not
> displayed.
> Should we consider creating a different renderer for <img> depending on
> which type of content it represents, and create a shadawRoot to display the
> alt text if needed?
> Something similar to the implementation in Chromium [3].
> 
> [1]
> https://www.w3.org/TR/2016/WD-html51-20160412/rendering.html#replaced-
> elements-images
> [2]
> https://www.w3.org/TR/2016/WD-html51-20160412/semantics-embedded-content.
> html#the-img-element
> [3] https://codereview.chromium.org/481753002

[1] https://html.spec.whatwg.org/multipage/rendering.html#images-3
[2] https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element
These two are the latest version:)