[css-lists] The cursor property should apply to ::markers

[pxeger]

The spec for the properties which apply to ::markers does not include the cursor property. I'd like to be able to apply this to the ::marker of a summary element in particular, to give user feedback that clicking on it will do something (that is, open/close the details).

You can add cursor to the whole summary, but that also applies it to the actual content of the summary, and the blank space after the content, with no easy way to remove it there. Demo:

<style>
  summary {
    cursor: pointer;
  }
</style>
<details>
  <summary>Label</summary>
  Content
</details>

[Loirooriol]

I already mentioned cursor in #4568 (comment). The resolution in #4568 (comment) was

If property applies to text and no dependency on box geometry it can be set on ::marker and inherits to text of marker

I guess the cursor property kinda exposes the size of the ::marker, so it depends on box geometry.

However, resetting cursor in UA origin would be bad. So it's possible to set cursor on the list item, let it inherit, and reset it for the contents of the list item. And anyways, getComputedStyle exposes the size without user interaction. So allowing cursor doesn't seem a big deal, and not allowing it is a hassle for authors.

[fantasai]

I think that even though this expresses the geometry, it doesn't do so in a way that would significantly break if we change how the geometry is calculated, so I think it would be safe to apply this to ::marker.

[Loirooriol]

Thinking about this again:

• cursor is defined to apply to all elements
• So in particular, it applies to inline elements. And it's an inherited property.
• Therefore, as per [css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303 (comment), cursor applies to text.
• So as per https://drafts.csswg.org/css-lists-3/#marker-properties

  Inheritable properties that apply to text can be set on the ::marker pseudo-element: these will inherit to and take effect on its text contents.

I still think cursor should apply to the ::marker box itself and not just to the text inside, but I guess that in most cases the difference would be hard to tell. So just following the existing resolutions would already be an improvement.

[yisibl]

I think the use of ::marker in details>summary is a mistake.

1. This makes the display have to be a list-item, and by default you can't use a layout like flexbox(This means that marker cannot be placed to the right via the order property).
2. There are only a limited number of properties that can be set in marker, you can't use transform to animate it
3. The cursor cannot be set as mentioned in this issue.
4. Adds additional computational and performance overhead. See Figure out some way to trigger ::marker without being a list item #6781

If we just allow the use of the cursor, we can't solve similar problems completely.

So I think a generic pseudo-element should be added, which faces the same problem as checkmark in selectlist, the current Chrome implementation (by @josepharhar ) uses ::before.

[Loirooriol]

Sure, but allowing cursor on ::marker seems useful on actual list items too. Changing <summary> can be discussed in other issues.

[yisibl]

Sure, but allowing cursor on ::marker seems useful on actual list items too. Changing <summary> can be discussed in other issues.

I agree.

[yisibl]

Here is a collection of requests to support more properties in ::marker.

• Allow user-select on ::marker pseudoelements #8892
• [css-lists] The cursor property should apply to ::markers #6203
• [css-pseudo][css-lists] Allow counter-* in ::marker #5265
• [css-pseudo-4][css-lists-3] Allow 'writing-mode' on ::marker #5250

[css-meeting-bot]

The CSS Working Group just discussed [css-lists] The `cursor` property should apply to `::marker`s, and agreed to the following:

• RESOLVED: cursor property applies to ::marker pseudo

The full IRC log of that discussion

<flackr> fantasai: proposal is to allow cursor to ::marker. Technically this exposes the geometry of ::marker which we avoided in the past because we haven't defined the layout of it
<flackr> fantasai: changing the cursor a few pixels either way seems unlikley to break anything significant so it seems like it should be same to apply even though we don't know where it is
<TabAtkins> +1
<flackr> astearns: comments or questions?
<kizu> +1
<fantasai> s/same to/safe to/
<TabAtkins> (we should solve this issue more generally, but this is good as a particular change)
<ChrisL> +1 to allowing cursor in ::marker but note the list of other properties to add at the end of that issue
<ChrisL> q+
<florian> +1 to allowing it
<flackr> TabAtkins: we should figure out how to make marker have the same power as before and after in the future
<flackr> TabAtkins: we'd like to make it a real element that's just not in the tree
<astearns> ack ChrisL
<fantasai> an "element-emulating" pseudo-element :p
<flackr> ChrisL: I think it's good to add it, the last comment in the issue has a bunch of other properties which should prob be added so let's not close it off without migrating it
<flackr> astearns: links to other issues though
<flackr> Proposed resolution: cursor property applies to ::marker pseudo
<flackr> RESOLVED: cursor property applies to ::marker pseudo