New issue
Advanced search Search tips

Issue 923325 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

[LayoutNG] IMG with content URL that fails to load prevents margin collapsing

Project Member Reported by mstensho@chromium.org, Jan 18 (4 days ago)

Issue description

This is the reason why http/tests/images/restyle-decode-error.html currently fails in NG.

When a block-level IMG element has an image URL content property, there's special code in HTMLImageElement::CreateLayoutObject(), to funnel us into LayoutObject::CreateObject(), which has special-code to deal with URL content properties on *any* element type.

When it later on turns out that the URL fails to load, we'll re-attach and end up in HTMLImageElement::CreateLayoutObject() again. This time we'll decide to create fallback-content (this is normally how the broken image "image" is generated, but in the case of content URL fallback, we end up with nothing inside), and we'll call LayoutObjectFactory::CreateBlockFlow().

The difference is that legacy treats the IMG block as a self-collapsing block, while LayoutNG does not. The main reason for this is that legacy layout calls LayoutBlockFlow::CreatesNewFormattingContext(), while NGLayoutInputNode::CreatesNewFormattingContext() calls AvoidsFloats() - which, in addition to calling LayoutBlockFlow::CreatesNewFormattingContext() also calls ShouldBeConsideredAsReplaced() (which is true in our case, because of the IMG element type).

It's not obvious to me which behavior is better, and whether this is a bug in NG or legacy.
 

Comment 1 by mstensho@chromium.org, Jan 18 (4 days ago)

Only Blink and WebKit seem to support content image URLs on arbitrary elements (including IMG), but this is in accordance with the spec:

https://www.w3.org/TR/css-content-3/#content-property

Attaching demo.
demo.html
296 bytes View Download

Sign in to add a comment