[Webkit-unassigned] [Bug 245883] <img> elements are always treated as a replaced element

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=245883

--- Comment #4 from cathiechen <cathiechen at igalia.com> ---
(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:)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221007/2e79122a/attachment.htm>