Allow user-select on ::marker pseudoelements

[bionicles]

As described in my stack overflow post at https://stackoverflow.com/questions/76280867/enable-user-select-on-ol-li-marker-to-avoid-losing-numbers-from-numbered-lis

"""
I face a problem with copying numbered lists (<ol>) from a chat application. When I copy the text, it doesn't include ::marker numbers. This makes the list items lose context, as numbers represent the order of content.

I know CSS ::marker pseudo-element isn't selectable by default, but I seek a workaround. The chat application often generates ordered lists, and users need to copy entire text, numbers included. It's not my app so I need to override CSS using the Stylus Chrome extension, I can't change their HTML or JS.

Does anyone know a way to select ::marker content, or keep ol li list numbers during text copy?

Here's a basic example:

<ol>
  <li>Item one</li>
  <li>Item two</li>
  <li>Item three</li>
</ol>

Here's my 1st attempted CSS:

::marker {
  user-select: all;
}

This CSS still leaves out ::marker numbers when I copy a numbered list, so the issue persists across modern browsers.

Thank you for taking the time to read this and thank you in advance for any help!

Bion
"""
Note, for the purpose of an easy intuitive solution, it would be awesome to have that 1st attempted CSS work, but it's OK if there needs to be a different solution. And please let me know if there's already a fix for this issue!

• please link to the spec section you're talking about, or at least the spec
  I'm unfamiliar with the structure of the spec, but it pertains to the ::marker pseudoelement. I guess that means this:
  https://drafts.csswg.org/css-pseudo-4/

[fantasai]

So on the topic of plaintext copy of list numbers, I think there are several ways forward here:

• Don't output generated content.
• Output all CSS generated content.
• Output only ::marker generated content.
• Output only HTML generated content (ignoring CSS, relying only on markup).

As mentioned here, we could use user-select to allow this to be controllable.

Follow-up question if we go with outputting CSS generated content: do we use the primary string, or the alt text string? https://www.w3.org/TR/css-content-3/#alt

[css-meeting-bot]

The CSS Working Group just discussed Allow user-select on ::marker pseudoelements, and agreed to the following:

• RESOLVED: Attempt to make this work for ::marker as well as ::before/after, come back with a specific proposal that allows it while respecting platform conventions

The full IRC log of that discussion

<TabAtkins> fantasai: Someone's trying to copy out a list, and not getting the ::marker numbers
<TabAtkins> fantasai: So this brings up, what do we do with ::marker when copying?
<florian> q+
<TabAtkins> fantasai: There's 4 things we could do
<TabAtkins> fantasai: 1) never output gencon
<TabAtkins> fantasai: 2) always output gencon
<TabAtkins> fantasai: 3) output ::marker gencon but not others
<TabAtkins> fantasai: 4) output only html-derived content (ignore css, only markup-based)
<TabAtkins> fantasai: In terms of controlling whether you want to copy out gencon, user-select might help manage that
<TabAtkins> fantasai: That was the commenter's original impression of how it shoudl work when they filed
<Rossen_> q?
<TabAtkins> fantasai: Then if we use CSS content, do we use the primary string, or the alt text if present?
<TabAtkins> fantasai: So the question is, again, what part of gencon should be part of plaintext copying
<emilio> q+
<TabAtkins> florian: We touched on a related topic before, it's tricky
<Rossen_> ack florian
<TabAtkins> florian: user-select says it may optionally apply to ::before/after
<TabAtkins> florian: Gives some advice on what to do
<TabAtkins> florian: Trick here is that if we think about css and html only it's not that hard
<TabAtkins> florian: I think the options elika listed are what's on the menu there
<TabAtkins> florian: But this also relates to the Selection API
<TabAtkins> florian: You expect to get a match between selection and what you copy
<TabAtkins> florian: As it exists, I believe Selection is not capable of describing pseudos
<TabAtkins> florian: I think it would be good to allow this to work, but to make it coherent we need to make Selection API capable of describng pseudos in its range
<Rossen_> ack emilio
<TabAtkins> emilio: is there a pre-existing diff between the output of Range.toString and the clipboard?
<TabAtkins> emilio: the clipboard use-case seems fixable without the selection API
<TabAtkins> emilio: I don't think we should include gencon in the text/html clipboard, but maybe in the text/plain one
<florian> q?
<Rossen_> q+
<florian> q+
<TabAtkins> emilio: I just think we might be able to fix clipboard without having to touch Selection
<Rossen_> ack florian
<TabAtkins> florian: I believe there's no current diff between them, but I think you're right - we can either introduce a difference or complexity the Selection API
<fantasai> +1 to emilio
<hober> q+
<hober> ack Rossen_
<TabAtkins> Rossen_: We're assuming there's only one thing on the clipboard, that's usually not the case for rich editing cases
<TabAtkins> Rossen_: Also, I'd expect whatever ends up in the clipboard isn't what we serialize to a11y tools. So if they today get the gencon or lose the gencon, i'd expect the same from copy/paste
<Rossen_> q?
<Rossen_> ack hober
<TabAtkins> hober: I'm not an expert on this aprt of webkit but we have people elsewhere who are, i've asked [Went?] to come over and express an opinion. I'd prefer not to resolve until we have an expert on our side weigh in.
<myles> q+
<TabAtkins> myles: when you said multiple things on the clipboard did you mean multiple mime types?
<TabAtkins> Rossen_: Yes, sorry
<hober> s/[Went?]/Wenson/
<TabAtkins> Rossen_: So what do we want to do with this?
<florian> q+
<TabAtkins> Rossen_: For me, one of the stronger goals is to make sure we're not degrading a11y tools and experience
<TabAtkins> Rossen_: But if we're waiting for input we can postpone this issue a bit.
<hober> q+
<fantasai> TabAtkins: I think it's fine to wait a little bit
<TabAtkins> TabAtkins: I think I'm fine to wait a little bi?
<TabAtkins> florian: In general for ::marker I think it's at least as desirable as ::before/after.
<myles> q-
<TabAtkins> florian: So wanting to do something seems reasonable.
<Rossen_> ack florian
<TabAtkins> florian: The spec says it *may* work for ::before/after but not how, so we should consider these together.
<fremy> q+
<TabAtkins> florian: Selection API, clipboard, etc. We should circle back to see what's feasible.
<TabAtkins> florian: So I think the use-case makes sense but it's about how to make it work.
<TabAtkins> florian: I don't think it's reasonble to resolve quite yet until research.
<TabAtkins> hober: other thing to keep in mind is that different native platforms have diff behavior
<TabAtkins> hober: It's usually the case that a browser wants to match that platform's behavior for cut/paste interop
<TabAtkins> hober: Myles is trying to figure out what our platform behavior even is
<Rossen_> ack hober
<TabAtkins> hober: But just noting if the spec requires us to violate platform behavior we'd probaby violate spec
<TabAtkins> florian: I think it's probably not an issue
<TabAtkins> florian: The broader conventions outside the browser don't have anything to see about before/after
<TabAtkins> hober: Right but they do have lists, so there's at least an analogy
<myles> q+
<emilio> Browsers diverge even on `data:text/html,<p style="display: inline">foo</p><p style="display: inline">bar</p>` :)
<florian> s_anything to see about before/after_anything to say about web platform pseudos
<Rossen_> ack fremy
<TabAtkins> fremy: I jsut tried out of curiosity multiple browsers, adn they don't copy the same formatting now anyway
<TabAtkins> fremy: So not sure if it makes much sense to specify this behavior if browsers don't have interop on simpler things
<TabAtkins> fremy: But they are at least consistent that they don't copy gencon
<TabAtkins> fremy: So I'm just ot sure it makes sense to specify behavior on ::marker if we don't specify copy/paste in general
<Rossen_> ack fantasai
<TabAtkins> fantasai: I'm fine to defer the discussion if we're asking for more info, just don't think we should close and forget about it
<fremy> test case: https://wptest.center/#/4ff743
<TabAtkins> fantasai: To francois' point, fi the default is to not copy out, yeah it should keep being the default
<TabAtkins> fantasai: But think there should be a way to copy it, it's confusing when you copy out and the numbers disappear
<florian> q+
<TabAtkins> fantasai: You lose a lot of important context
<emilio> q+
<Rossen_> ack myles
<TabAtkins> Rossen_: Agree, just wanting to narrow down the issues in a while that'll help
<TabAtkins> myles: our platform behavior isn't just that the marker text isn't put on the clipboard
<TabAtkins> myles: We *also* put tab characters in the clipboard so the list looks indented
<Rossen_> q
<fremy> @myles, what you describe seems to match Firefox, not Chrome
<TabAtkins> myles: So our resolution shouldn't be that it only takes the gencon, it should ideally match our behavior there
<Rossen_> ack florian
<TabAtkins> florian: I suggest we take a resolution that we try to make this work, take an action item to chekc in with people already working in this area with Selection. We should know if they have plans or have already rejected in this space.
<TabAtkins> florian: Also to check in with the a11y api. That might rescope the problem a bit.
<myles> s/should ideally match our behavior there/should allow for matching platform behavior/
<TabAtkins> florian: And based on that, trying to define in a way that woudln't conflict with the constraint that Myles expressed
<TabAtkins> florian: So I think we should try to add ::marker to that list and then figure out what it means
<Rossen_> ack emilio
<TabAtkins> emilio: Just looked at our code, we do have different serializatio for Selection API vs clipboard
<TabAtkins> emilio: There's a weird mix where for some things we serialize based on DOM, and others based on CSS, and there's probably a bigger meta question
<TabAtkins> emilio: so if you copy a <p style=display:table> are you copying a table or a paragraph
<TabAtkins> emilio: In general it probably makes sense to look at CSS
<TabAtkins> emilio: But then the html clipboard and plaintext clipboard will be rather different.
<TabAtkins> Rossen_: That's good
<TabAtkins> Rossen_: So first two options are opposite ends of the spectrum, don't do anything, yes do everything
<TabAtkins> Rossen_: Sounds like we're aiming at a nuanced appraoch between these
<florian> q+
<TabAtkins> Rossen_: Would it make sense to eliminate these two, and make progress navigating something like the other two, designing and refining what gets output and when?
<TabAtkins> fantasai: I mean what if you actually want to copy everything?
<Rossen_> ack florian
<TabAtkins> florian: AS a reminder, and we can change if it's wrong, the way user-select is currently defined is that initial value is auto, and auto computes to none on pseudos
<TabAtkins> emilio: used value
<TabAtkins> florian: it resolves to none
<TabAtkins> florian: But authors can explicitly opt into saying yes. whether that works or not is fuzzy
<TabAtkins> florian: So default is to not copy the content. whether that still affects something with lists, that's up to us
<Rossen_> q?
<TabAtkins> fantasai: So if we wanted to copy lists by default we could make ::marker have non-none behavior
<TabAtkins> florian: sure
<TabAtkins> Rossen_: So can we eliminate those two extreme options to make progress?
<TabAtkins> fantasai: Do other browsers need info?
<TabAtkins> fantasai: If I'm working on this issue what do I need besides talking to Tess and Myles?
<TabAtkins> florian: So first ask for existing standards people on Selection or editing to see if they're already working in this area.
<TabAtkins> fremy: Maybe an action on browser vendors to describe what they're doing today?
<TabAtkins> florian: Selection is editted by rniwa
<TabAtkins> fantasai: So that makes it easy
<myles> q+
<TabAtkins> myles: because our primary concern is platform consistency, the result of this investigation shouldn't be "write down exactly what platforms do", it should be flexible enough to allow platforms to do different things that could change.
<Rossen_> q?
<myles> q=
<myles> q-
<Rossen_> ack myles
<TabAtkins> Rossen_: So a proposed resolution?
<TabAtkins> florian: Attempt to make this work for ::marker as well as ::before/after, come back with a specific proposal that allows it while respecting platform conventions
<TabAtkins> Rossen_: Objections?
<fremy> (at least on Windows, no browser outputs Text that is similar to Word for the same code...)
<TabAtkins> RESOLVED: Attempt to make this work for ::marker as well as ::before/after, come back with a specific proposal that allows it while respecting platform conventions

[bionicles]

Amazed by your thoughtful discussion! Thank you so much!