[css-lists] Interaction of ::marker with other pseudo-elements. #3826

emilio · 2019-04-14T14:15:57Z

A few different questions that occurred to me, that should probably be tested and clarified on the spec, and they interact with each other.

Do `::before` and `::after` generate markers?

In #3766 it was clarified that they increment the list-item counter and are considered list items. But do they generate marker boxes?

Browsers generally do (Edge didn't use to though, so we may have some leeway). It's a bit weird that we're generating nested pseudo-elements.

If they do... Do those markers generated by pseudo-elements match selectors from the page?

WebKit and Gecko's implementation do show two red bullets here:

<!doctype html>
<style>
  li::after {
    content: "After";
    display: list-item;
  }
  ::marker {
    color: red;
  }
</style>
<ul>
  <li>Bar

But then that means that you can address a marker generated by a pseudo-element with selectors. Which is inconsistent in the sense that it doesn't happen for ::before and ::after. Which carries me to the next question...

If they do... Does `display` apply to `::marker`? And thus, can `::marker` boxes be list items?

If we allow content on marker, they can just be a normal box, affected by display, and thus have display: list-item on them. If generated markers can be list items, then:

Do they increment the list-item counter?
Do they generate other markers?

I really hope the answer to these two question is "no", but otherwise, how should this work?

<!doctype html>
<style>
  li::after {
    content: "After";
    display: list-item;
  }
  ::marker {
    display: list-item;
    content: counter(list-item) ".";
  }
</style>
<ol>
  <li>Foo
  <li>Bar

I think ::marker shouldn't be a list-item, even if it's a box with display: list-item like @fantasai clarified in #3766, and that it should not increment the list-item counter nor generate other markers.

The text was updated successfully, but these errors were encountered:

emilio · 2019-04-14T17:59:42Z

WebKit and Gecko's implementation do show two red bullets here:

This is apparently wrong, I don't know what I was testing, but loading that again on WK doesn't show the red marker. So I think those markers shouldn't be addressable by selectors.

But the third question is probably worth answering.

emilio · 2019-04-14T18:09:59Z

And the first, probably... I'd prefer if they wouldn't generate markers. Because then you don't have to have pseudo-elements generating other pseudo-elements, even if those can't be addressed by content.

emilio · 2019-04-14T18:29:10Z

And the first, probably... I'd prefer if they wouldn't generate markers. Because then you don't have to have pseudo-elements generating other pseudo-elements, even if those can't be addressed by content.

Basically, if we generate those markers, the UA sheet for marker needs to be defined in some magic way that also matches pseudo-element markers, somehow. I'd rather avoid that.

EDIT: I've noticed that that UA rule only applies to li elements, is that intentional?

MatsPalmgren · 2019-04-14T18:54:36Z

I don't think you should take that UA sheet too seriously. It's wrong in a number of ways. I'm guessing its purpose is mainly to explain how the CSS built-in list-item counter works using the familiar HTML list elements as an example, even if it's not precise. Obviously you can't match "display has the value list-item" in a selector etc.

MatsPalmgren · 2019-04-14T19:23:22Z

Regarding your questions, I think ::before/::after/::marker should all be list items when styled with display:list-item and generate a marker. A pseudo's marker can't be addressed by a selector currently , but I see no reason why that could't be added in a future version of the Selectors spec. It seems to me we shouldn't exclude that possibility.

emilio · 2019-04-14T19:29:05Z

It seems to me then that ::marker { display: list-item } would generate an infinite amount of list items, which is not great.

MatsPalmgren · 2019-04-14T19:48:45Z

No, because ::marker is the same as *::marker and * only matches ordinary elements, not pseudo-elements. You can't set display (or any properties) on any deeper level markers since there's no selector for it.

jonjohnjohnson · 2019-04-14T20:17:24Z

You can't set display (or any properties) on any deeper level markers since there's no selector for it.

@MatsPalmgren would you then suggest that selectors like ::before::marker/::marker::marker be valid (https://drafts.csswg.org/selectors-4/#pseudo-element-structure) to actually be stylable/useful?

MatsPalmgren · 2019-04-14T20:43:44Z

Right, I'm not really suggesting any particular syntax, but we might want to add a selector to address nested pseudos like that in the future so I think it's premature to forbid ::markers on pseudos now just because we currently can't style them.

(But yes, ::before::marker/::marker::marker/::before::marker::marker etc seems reasonable. We might also want some selector syntax to address markers on any level, for convenience. The second syntax clearly needs to have some built-in limitations to avoid creating infinite levels of markers though, say by ignoring display:list-item in such rules.)

Loirooriol · 2019-04-15T16:17:33Z

I think most of this was already resolved in #1793 (comment)

Do ::before and ::after generate markers?
Yes, but the marker will have no box if the ::before or ::after doesn't have display: list-item, as usual.
Do those markers generated by pseudo-elements match selectors from the page?
As Mats says I don't think ::marker should select these markers, because ::marker means *::marker, and * only matches elements.
But something like ::before::marker might be allowed in the future.
Does display apply to ::marker? And thus, can ::marker boxes be list items?
Currently display does not apply to ::marker (https://drafts.csswg.org/css-pseudo-4/#marker-pseudo), so they cannot be list items.
And even if they could, the resolution in [css-display][css-pseudo] Is ::marker created by display:list-item or does it always exist? #1793 said that marker pseudo-elements (in the element tree, not marker boxes) are only originated by elements, ::before and ::after, but not by other markers. Otherwise the element tree would have an infinite depth.

SebastianZ · 2019-04-16T22:14:39Z

If they do... Do those markers generated by pseudo-elements match selectors from the page?

WebKit and Gecko's implementation do show two red bullets here:

Gecko's implementation obviously does, but has a bug when changing the styles. I've reported that as bug 1544959.

Does display apply to ::marker? And thus, can ::marker boxes be list items?

Currently display does not apply to ::marker (https://drafts.csswg.org/css-pseudo-4/#marker-pseudo), so they cannot be list items.

In the Firefox implementation at least display: none obviously applies to it and causes the marker(s) not to be displayed. The other display values including list-item have no effect on it, though.

Sebastian

tabatkins · 2019-04-19T22:14:34Z

Agree with all of Mats' answers. ::before/after generate ::marker, 'display' doesn't apply to ::marker, and a ::marker selector can't select the marker on the ::before because it's not visible in the tree (you'd need ::before::marker)

emilio · 2019-04-20T13:24:42Z

The way I read @MatsPalmgren is that display should apply to marker (when using ::content at least)... right?

MatsPalmgren · 2019-04-20T18:25:48Z

Right, as I've said before, I'm opposed to introducing arbitrary unnecessary styling restrictions on ::marker. It's much simpler for everyone (spec authors, implementors, authors) if it behaves the same as ::before/::after.

There are still some uncertainty about the exact layout model for outside markers (#3771), so feel free to add an ISSUE note about that in the spec, but my gut feeling is that we can allow pretty much all of CSS on those too. We definitely should allow display:none to suppress the box.

I don't see a reason treat content/non-content markers differently. (Gecko currently has two code paths, where the non-content legacy code path has some restrictions, but I consider that to be a temporary implementation bug that we'll fix soon.) Given that ::marker is relatively new, I don't see any web-compat concerns that could justify introducing styling restrictions.

css-meeting-bot · 2019-05-08T16:43:26Z

The CSS Working Group just discussed ::marker vs other pseudo-elements, and agreed to the following:

RESOLVED: don't expand the list of props that apply to ::marker

The full IRC log of that discussion

<fantasai> Topic: ::marker vs other pseudo-elements
<fantasai> github: https://github.com//issues/3826
<fantasai> I agree with https://github.com//issues/3826#issuecomment-483320040
<fantasai> emilio: I think there was some confusion of whether 'display' applies to markers
<fantasai> fantasai: display doesn't currently apply to markers
<fantasai> fantasai: and I don't think it should until marker layout is fully defined
<fantasai> fantasai: and its interaction with display is also defined
<fantasai> TabAtkins: Mats is arguing for much more than display
<fantasai> TabAtkins: He's arguing for marker to take all properties, like ::before/::after
<fantasai> TabAtkins: Is there a reason to stop at display or re-litigate after?
<dbaron> ScribeNick: florian
<florian> fantasai: the reason we have a limited list of properties is that because we don7t know how marker layout works
<florian> fantasai: so allowing these properties without knowing what they do is bad
<florian> fantasai: we also don't know the size of the box, so any property that makes that visible is a problem
<florian> fantasai: we don't know if line-height plays a role... many other properties have the problem
<florian> fantasai: there are implementation specific answers, but so far they're not exposed
<florian> fantasai: so if we expose them, me might accidentally lock compat on whatever ships first
<florian> fantasai: so we should not
<florian> emilio: makes sense to me, will apply that to firefox
<florian> fantasai: for now we just allow text related properties
<florian> fantasai: eventually we want to relax that, but only after layout is defined
<fantasai> https://www.w3.org/TR/css-pseudo-4/#marker-pseudo
<florian> proposed resolution: don't expand the list of props that apply to ::marker
<florian> RESOLVED: don't expand the list of props that apply to ::marker
<fantasai> It would probably be OK to add more properties from css-text/text-decor
<fantasai> those that apply to inlines
<emilio> github: https://github.com//issues/3815
<emilio> github: https://github.com//issues/3826

…r pseudo-element can be selected, but not with '::marker' because that expands to '*::marker' and * doesn't match pseudos. #3826 #3766

fantasai · 2019-06-28T22:40:20Z

Emilio responded in the minutes, so marking Commenter Satisfied.

emilio added css-lists-3 Current Work css-lists-4 labels Apr 14, 2019

emilio added the Agenda+ label Apr 14, 2019

css-meeting-bot removed the Agenda+ label May 8, 2019

mozilla-apprentice mentioned this issue May 8, 2019

[css-lists] Interaction of ::marker with other pseudo-elements. mozilla/wg-decisions#30

Closed

tabatkins added Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. Commenter Response Pending labels Jun 28, 2019

fantasai added a commit that referenced this issue Jun 28, 2019

[css-pseudo-4] Clarify that the marker of a list-item ::before/::afte…

67f8681

…r pseudo-element can be selected, but not with '::marker' because that expands to '*::marker' and * doesn't match pseudos. #3826 #3766

fantasai added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Jun 28, 2019

fantasai closed this as completed Jun 28, 2019

fantasai mentioned this issue Jun 28, 2019

[css-lists] Clarify whether ::before and ::after pseudo-elements can be list-items and increment the list-item counter. #3766

Closed

Loirooriol mentioned this issue Dec 4, 2019

[css-pseudo] Default UA styles for markers don't affect ::before::marker and ::after::marker #4474

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-lists] Interaction of ::marker with other pseudo-elements. #3826

[css-lists] Interaction of ::marker with other pseudo-elements. #3826

emilio commented Apr 14, 2019

emilio commented Apr 14, 2019

emilio commented Apr 14, 2019

emilio commented Apr 14, 2019 •

edited

Loading

MatsPalmgren commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

emilio commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

jonjohnjohnson commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

Loirooriol commented Apr 15, 2019

SebastianZ commented Apr 16, 2019

If they do... Do those markers generated by pseudo-elements match selectors from the page?

tabatkins commented Apr 19, 2019

emilio commented Apr 20, 2019

MatsPalmgren commented Apr 20, 2019

css-meeting-bot commented May 8, 2019

fantasai commented Jun 28, 2019

[css-lists] Interaction of ::marker with other pseudo-elements. #3826

[css-lists] Interaction of ::marker with other pseudo-elements. #3826

Comments

emilio commented Apr 14, 2019

Do ::before and ::after generate markers?

If they do... Do those markers generated by pseudo-elements match selectors from the page?

If they do... Does display apply to ::marker? And thus, can ::marker boxes be list items?

emilio commented Apr 14, 2019

emilio commented Apr 14, 2019

emilio commented Apr 14, 2019 • edited Loading

MatsPalmgren commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

emilio commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

jonjohnjohnson commented Apr 14, 2019

MatsPalmgren commented Apr 14, 2019

Loirooriol commented Apr 15, 2019

SebastianZ commented Apr 16, 2019

If they do... Do those markers generated by pseudo-elements match selectors from the page?

tabatkins commented Apr 19, 2019

emilio commented Apr 20, 2019

MatsPalmgren commented Apr 20, 2019

css-meeting-bot commented May 8, 2019

fantasai commented Jun 28, 2019

Do `::before` and `::after` generate markers?

If they do... Does `display` apply to `::marker`? And thus, can `::marker` boxes be list items?

emilio commented Apr 14, 2019 •

edited

Loading