Open Loirooriol opened 4 years ago
I believe the reasoning behind that edit was to get away from having a dependency on CSSPseudoElement
so I suspect we'll want to go with the first of the three possibilities (i.e. ::before::marker
) here.
@george-steel Are you able to make that edit?
It would be good if the solutions here and in #4456 were consistent.
I would say this resolving this is blocked on #4456 at the moment. We should see what getComputedStyle does and match that behavior. One question I have is are there currently any pseudo-element selectors that do not commute (i.e. they car valid with different meanings in either order). My current mental model if PseudoElement semantics is that they control alternate style slots and any given piece of styled content is controlled by a set of them.
Also isn't the originating element of a pseudo-element always an Element, even using a double-selector. something like ::before::marker
would be the pseudo-selector. We already have this with ::before::first-line
and all its weird inheritance rules.
@george-steel According to https://drafts.csswg.org/selectors-4/#typedef-pseudo-element-selector, ::before::marker
are 2 pseudo-element selectors, not just one.
And https://drafts.csswg.org/css-pseudo-4/#marker-pseudo says
an originating element that is a pseudo-element needs to be explicitly specified in the selector, e.g.
::before::marker
.
so no, the originating element can be a pseudo-element.
AFAIK ::before::first-line
is an invalid combination. But ::first-line
is not tree-abiding, so #foo::first-line
can have fragments inside #foo::before
.
That is definitely a footgun with the definition of originating element. The intention of the spec change was that the target element is always an Element.
We may need two separate concepts (as proposed in https://github.com/w3c/csswg-drafts/issues/3836#issuecomment-502344378). But an originating element that can be a pseudo-element is useful. For example, some behavior of a marker is controlled by the list-style
properties on the originating element. So list-style
on #target
affects #target::marker
, and list-style
on #target::before
affects #target::before::marker
. We don't want the list-style
on #target
to affect both #target::marker
and #target::before::marker
I think you're right, that parents (::first line in a child has both the child and the parent's ::first-line as parents) and originating element are different logical concepts. Any idea on how do disambiguate that?
From https://drafts.csswg.org/web-animations-1/#keyframe-effects,
This seems to assume that pseudo-elements are always originated by an element. But nested pseudo-elements are originated by another pseudo-element.
So what happens if the effect target is a nested pseudo-element like
::before::marker
?I see 3 reasonable possibilities:
::before
, and the target pseudo-selector is::before::marker
. That is, enforce the target element to be an Element, never a CSSPseudoElement, and let the target pseudo-selector be multiple pseudo-element selectors.::before
, and the target pseudo-selector is::marker
That is, enforce the target pseudo-selector to be at most a single pseudo-element selector, and let the target element be either an Element or a CSSPseudoElement. Just forbid the case of the target element being a CSSPseudoElementand the target pseudo-selector being null.