- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 21 Aug 2014 17:05:19 -0700
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
On Thu, Aug 21, 2014 at 3:40 PM, Florian Rivoal <florian@rivoal.net> wrote: > On Fri, 22 Aug 2014 00:21:10 +0200, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: >> 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. > > So we should: > (1) stick to the fact that ::before/::after on replaced elements do nothing > and > (2) eventually spec something like ::sibling-before/::sibling-after > > That would make sense to me, and I don't see any reason to wait to put (1) > in a spec explicitly. Since the selector spec is the one refering to 2.1, > which says we will eventually say how this work, it looks like a good > place for a clarification. How about this at the end of section 3.7: > > Note. Since ::before and ::after add children to the originating > element, they have no effect on replaced elements such as the HTML img > element. The reason we haven't done this yet is that browsers aren't that simple. We have "semi-replaced" elements, such as form inputs, which are considered "replaced" by CSS, but which react to styling as if they had children in several browsers. In particular, most inputs allow ::before/::after to be used. Once we come up with a story for form styling, such that we can actually define the set of "really replaced" elements, I'm happy to add wording that says that ::before and ::after don't apply to them. ~TJ
Received on Friday, 22 August 2014 00:06:06 UTC