- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Aug 2018 19:55:14 +0000
- To: public-css-archive@w3.org
'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, `<content-list>` defines a different behavior for invalid images - browsers are allowed to display "broken image" icons in their place. I'm not sure why `<content-replacement>` 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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2831#issuecomment-414800934 using your GitHub account
Received on Tuesday, 21 August 2018 19:55:17 UTC