- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 21 Aug 2014 15:21:10 -0700
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
On Thu, Aug 21, 2014 at 2:50 PM, Florian Rivoal <florian@rivoal.net> wrote: > On Thu, 21 Aug 2014 23:16:36 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> On 8/21/14, 5:04 PM, Florian Rivoal wrote: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=169334 and to how all >>> (modern) implementations behave, ::before and ::after don't work on >>> replaced content, such as images, making the following code a no-op: >> >> >> The thing is, ::before and ::after add _children_. This is why they don't >> make much sense on replaced elements. >> >> What you're trying to add is a _sibling_. > > That's right, but given that the only spec I could find that explicitly > talks about the interaction between ::before/::after and replaced elements > (CSS21) says that we'll define later how it works, we sort of left the door > open. > > Most probably, we want this to be a no-op for the reason you mentioned, but > then we should close the opening that CSS21 made, since it is still the most > recent relevant spec on the topic as far as I can tell. > > The alternative is to spec that on replaced elements, since adding children > make no sense, ::before and ::after add siblings instead. I suspect there > not much sympathy for that position amongst browser vendors, but from an > author point of view, it would be convenient. > > A bit of googling shows that this is something people try, and get > disappointed when it doesn't work. While we definitely need to figure out something for this eventually, reinterpreting ::before/after as siblings is definitely not the right idea. We'll likely eventually add something that adds siblings for all elements. ~TJ
Received on Thursday, 21 August 2014 22:21:57 UTC