Skip to content

[css-content] Does content: url() apply to images? #2831

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
emilio opened this issue Jun 27, 2018 · 7 comments
Open

[css-content] Does content: url() apply to images? #2831

emilio opened this issue Jun 27, 2018 · 7 comments
Labels
css-content-3

Comments

@emilio
Copy link
Collaborator

emilio commented Jun 27, 2018 •
edited
Loading

Blink and WebKit implement content: url() allowing to replace an element with an image.

However the behavior differs and doesn't look quite intentional, and WebKit's behavior looks different if the image is already loaded or not (the second image would display alt text after a relayout, wat).

Consider this test-case:

>
<img src="broken" style="content: url(https://www.w3.org/2008/site/images/logo-w3c-mobile-lg)" alt="This is my alt text">
<img src="https://www.w3.org/2008/site/images/logo-w3c-mobile-lg" style="content: url(broken)" alt="This is my alt text">

How should this render? Should content: url() apply or not? If it does, should it display the alt text? Why only for (if the image is broken in a

) it just doesn't render?

Also, note that in Blink at least, if the image is already loaded for the second , or if you toggle display manually, suddenly it displays the image instead of the alt text.
@emilio
Copy link
Collaborator Author

emilio commented Jun 27, 2018

cc @lilles

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 30, 2018
@emilio
Bug 215083: Implement content: url(..) for elements. r=tnikkel,dholbert
6d73d28 
Dynamic changes are handled correctly because content property changes already
cause a reframe.

This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.

In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.

Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in w3c/csswg-drafts#2831 /
w3c/csswg-drafts#2832.

I don't think it matters in terms of web compat in any case.

MozReview-Commit-ID: JUurhC60hWr
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 30, 2018
@emilio @moz-wptsync-bot
Implement content: url(..) for elements.
1f15219 
Dynamic changes are handled correctly because content property changes already
cause a reframe.

This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.

In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.

Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in w3c/csswg-drafts#2831 /
w3c/csswg-drafts#2832.

I don't think it matters in terms of web compat in any case.

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=215083
gecko-commit: 2ca43c308ce1c5063fd1f2be7984dc781ab70c0c
gecko-integration-branch: mozilla-inbound
gecko-reviewers: tnikkel, dholbert
@moz-wptsync-bot moz-wptsync-bot mentioned this issue Jun 30, 2018
Merged
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 30, 2018
@emilio @moz-wptsync-bot
Implement content: url(..) for elements.
f83787e 
Dynamic changes are handled correctly because content property changes already
cause a reframe.

This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.

In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.

Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in w3c/csswg-drafts#2831 /
w3c/csswg-drafts#2832.

I don't think it matters in terms of web compat in any case.

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=215083
gecko-commit: 2ca43c308ce1c5063fd1f2be7984dc781ab70c0c
gecko-integration-branch: mozilla-inbound
gecko-reviewers: tnikkel, dholbert
xeonchen pushed a commit to xeonchen/gecko-cinnabar that referenced this issue Jul 2, 2018
@emilio
Bug 215083: Implement content: url(..) for elements. r=tnikkel,dholbert
36cb611 
Dynamic changes are handled correctly because content property changes already
cause a reframe.

This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.

In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.

Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in w3c/csswg-drafts#2831 /
w3c/csswg-drafts#2832.

I don't think it matters in terms of web compat in any case.

MozReview-Commit-ID: JUurhC60hWr
@emilio emilio mentioned this issue Jul 30, 2018
Closed
@karlcow
Copy link
Member

karlcow commented Aug 21, 2018 •
edited
Loading

Edited on 2018-08-22 with a better screenshot.

Tested with http://la-grange.net/2018/07/31/content/ in

  • left Firefox Nightly 63.0a1 (2018-08-21) (64-bit)
  • middle Version 70.0.3529.3 (Build officiel) canary (64 bits)
  • right Safari Tech Preview Release 63 (Safari 12.1, WebKit 13607.1.2.1)

capture d ecran 2018-08-22 a 09 02 30

@tabatkins
Copy link
Member

'content' should definitely work on img; there's nothing particularly special about it that would make this not true, I think.

Now, what to do when the 'content' URL is broken, but a 'src' url exists, is an interesting question. It seems like it makes the most sense to have 'content' fully win, so that if it's specified but the URL is broken, you just get the "0x0 transparent image" that's specified in the spec? This appears to be what falls out of the definitions, at least. We could instead specify that there's some notion of an "intrinsic image" coming from the element that it can fall back if possible, but that seems like complexity for complexity's sake; if we want to do fallback, we should just implement image() properly, not rely on this weird hack.

Notably, tho, defines a different behavior for invalid images - browsers are allowed to display "broken image" icons in their place. I'm not sure why is defined differently, and I'd be okay with harmonizing them.

Assuming that, ignoring the relayout bugs, Safari's behavior would be correct (showing a broken image, since no alt was provided in content). Chrome's would be incorrect.

@karlcow
Copy link
Member

karlcow commented Aug 22, 2018

I changed the screenshot in #2831 (comment) as Chrome and Safari seem to be consistent.

@emilio
Copy link
Collaborator Author

emilio commented Aug 22, 2018

'content' should definitely work on img; there's nothing particularly special about it that would make this not true, I think.

Well, image is a replaced element, and content: url() on other elements like or