W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: [css-images][selectors][css21] ::before and ::after on replaced elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 21 Aug 2014 15:21:10 -0700
Message-ID: <CAAWBYDBJRZqnbx1vudCM8910HDw282rrs7cRMS+cFqs2sdOxGw@mail.gmail.com>
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.

Received on Thursday, 21 August 2014 22:21:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:43 UTC