Bug 245883 - <img> elements are always treated as a replaced element
Summary: <img> elements are always treated as a replaced element
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-09-30 07:41 PDT by cathiechen
Modified: 2022-10-07 08:02 PDT (History)
2 users (show)

See Also:


Attachments
test-changing-value-of-alt-and-src.html (1.74 KB, text/html)
2022-09-30 07:43 PDT, cathiechen
no flags Details
test-changing-value-of-alt-and-src.html (1.69 KB, text/html)
2022-09-30 07:44 PDT, cathiechen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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:)