WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
245883
<img> elements are always treated as a replaced element
https://bugs.webkit.org/show_bug.cgi?id=245883
Summary
<img> elements are always treated as a replaced element
cathiechen
Reported
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
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
cathiechen
Comment 1
2022-09-30 07:43:47 PDT
Created
attachment 462727
[details]
test-changing-value-of-alt-and-src.html
cathiechen
Comment 2
2022-09-30 07:44:46 PDT
Created
attachment 462729
[details]
test-changing-value-of-alt-and-src.html
Radar WebKit Bug Importer
Comment 3
2022-10-07 07:42:17 PDT
<
rdar://problem/100897933
>
cathiechen
Comment 4
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:)
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug