Bug 204163

Summary: list ::marker should accept content, and several writing-mode related properties
Product: WebKit Reporter: Miriam Suzanne <miriam>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ahmad.saleem792, andrew, bootleq, dbates, eoconnor, ishida, mihaip, mmaxfield, obrufau, rik, rniwa, rv1971, simon.fraser, spanage, tedwhitehead, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=141477

Description Miriam Suzanne 2019-11-13 10:35:10 PST
Safari seems to support the `::marker` selector, but only for styling `color` and `font` properties. According to the specification (https://drafts.csswg.org/css-pseudo-4/#marker-pseudo - fully implemented in Firefox), support should also include:

- `content`
- `direction`
- `text-combine-upright`
- `unicode-bidi`

I'm not qualified to comment on the last two, but neither `content` nor `direction` is supported at this point. See my example on codepen: 

https://codepen.io/mirisuzanne/pen/bGGmdpm
Comment 1 Radar WebKit Bug Importer 2019-11-16 15:45:50 PST
<rdar://problem/57257364>
Comment 2 Oriol Brufau 2019-11-18 10:57:47 PST
Also the font-kerning property.

Once I finish the implementation of ::marker in Chromium, I can try to port patches into WebKit.
Comment 3 Mihai Parparita 2020-10-21 16:35:20 PDT
Daniel: it looks like you added support for ::marker (with https://trac.webkit.org/changeset/22020) -- is this an expected limitation?
Comment 4 Daniel Bates 2020-10-21 18:17:26 PDT
I added ::marker support. What is the question?
Comment 5 Mihai Parparita 2020-10-22 10:07:45 PDT
(In reply to Daniel Bates from comment #4)
> I added ::marker support. What is the question?

The lack of support for some the properties listed at https://www.w3.org/TR/css-lists-3/#marker-properties, especially `content`.
Comment 6 Daniel Bates 2020-10-22 23:31:51 PDT
(In reply to Mihai Parparita from comment #5)
> (In reply to Daniel Bates from comment #4)
> > I added ::marker support. What is the question?
> 
> The lack of support for some the properties listed at
> https://www.w3.org/TR/css-lists-3/#marker-properties, especially `content`.

Simple answer: they weren't in the draft at the time I implement it. I implemented Editor's Draft, 24 July 2017.
Comment 7 Daniel Bates 2020-10-22 23:39:34 PDT
Just for me, closest I could find was 07/26/2017: <https://github.com/w3c/csswg-drafts/blob/d0f08fdb814ca1edab5281ec54b3d4be478d9cd4/css-pseudo/Overview.bs>
Comment 8 Ted Whitehead 2021-01-05 14:11:08 PST
Hi there, was just wondering if there are plans to implement `content` in a future release. 

FWIW, none of these sites mention `content` as not being supported in Safari (which obviously isn’t your fault, but added to my confusion until I found this ticket).

- https://caniuse.com/css-marker-pseudo
- https://developer.mozilla.org/en-US/docs/Web/CSS/::marker#Browser_compatibility
- https://web.dev/css-marker-pseudo-element/#browser-compatibilty

Thanks!
Comment 9 Ted Whitehead 2021-01-05 15:27:49 PST
FYI, for anyone who stumbles across this in the future, one of the reasons why `content` is so helpful is because the old technique of setting `list-style: none` and using `:before` causes issues with VoiceOver on Safari (see https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html).
Comment 10 rv1971 2021-03-17 09:49:54 PDT
Hi, is there any hope that `content` will be implemented this year? I find it extremely useful for custom numbering of list items and I don't see a good workaround.
Comment 11 Oriol Brufau 2021-03-18 06:29:57 PDT
Implementing 'content' is not trivial, because RenderListMarker can't have children.
I don't plan to do it, but I guess the same approach that I used for Chromium legacy would work.
I explained the implementation details in https://blogs.igalia.com/obrufau/2020/12/21/css-marker-pseudo-element-in-chromium.html
Comment 12 r12a 2021-11-18 06:27:33 PST
Please consider implementing `text-combine-upright` support for ::marker.  Most vertically-set lists with counters need this in Chinese, Japanese, Korean, and Mongolian.  It is supported already by Blink and Gecko.

See https://www.w3.org/TR/jpan-gap/#issue170_vertical_text
Comment 13 Oriol Brufau 2021-11-19 04:52:57 PST
(In reply to r12a from comment #12)
> Please consider implementing `text-combine-upright` support for ::marker.

First, it seems WebKit doesn't support `text-combine-upright` at all, only `-webkit-text-combine`.

And then, even after turning ::marker into a full-fledged pseudo-element like ::before and ::after, `text-combine-upright`/`-webkit-text-combine` would need bug 208842 in order to work on ::marker.
Comment 14 r12a 2021-11-19 05:43:43 PST
Indeed.  All this needs to be made to work.  

The functionality of text-combine-upright is found everywhere in vertically-set type, and is supported by Blink and Gecko browsers. See also https://bugs.webkit.org/show_bug.cgi?id=150821
Comment 15 Ahmad Saleem 2022-06-14 16:59:21 PDT
I think based on this commit:

https://github.com/WebKit/WebKit/commit/59ae7be745ac297f8b0a3048bf0f2983cbdeb233#diff-ccec2155f5f9f46d273b68bd0e54ef4fbb453fb181324847f58bc04874ad3f9f

Now many of these properties are supported. For any missing, can we have separate bug? Thanks!
Comment 16 r12a 2022-06-15 03:27:51 PDT
Am i right in thinking that text-combine-upright has not yet been fixed, and that there are no tests for that feature either, or did i miss something?
Comment 17 Ahmad Saleem 2022-06-15 09:16:24 PDT
(In reply to r12a from comment #16)
> Am i right in thinking that text-combine-upright has not yet been fixed, and
> that there are no tests for that feature either, or did i miss something?

Hi r12a, I haven't seen "text-combine-upright" in the commit linked but I can see in following commit from 2021:

https://github.com/WebKit/WebKit/commit/5332afa8b4c60b8c7f2a086ecd7ccf3629a8d7ef#diff-ccec2155f5f9f46d273b68bd0e54ef4fbb453fb181324847f58bc04874ad3f9f

So I think it is now supported as well. Thanks!
Comment 18 Oriol Brufau 2022-06-16 01:24:38 PDT
(In reply to Ahmad Saleem from comment #15)
> I think based on this commit:
> 
> https://github.com/WebKit/WebKit/commit/
> 59ae7be745ac297f8b0a3048bf0f2983cbdeb233#diff-
> ccec2155f5f9f46d273b68bd0e54ef4fbb453fb181324847f58bc04874ad3f9f
> 
> Now many of these properties are supported. For any missing, can we have separate bug? Thanks!

That's wrong. The commit didn't add real support for these properties, it just stopped ignoring them in the computed style. But they still have no effect. Note that the test passes are in marker-supported-properties.html and marker-supported-properties-in-animation.html, which only check getComputedStyle().

Relevant tests still failing: marker-text-shadow.html, marker-line-height.html, marker-letter-spacing.html, ...

Creating separate bugs is pointless, because the underlying problem is the same: RenderListMarker has no actual children. IMO the solution is splitting RenderListMarker into:
 - RenderOutsideListMarker, which would be an actual block container
 - RenderInsideListMarker, which would be an actual inline box
Comment 19 Sommer Panage 2022-11-16 13:34:01 PST
At Quip/Slack we're running into an accessibility impact with this bug as well. Namely, when we cannot use ::marker to customize the content of an <li>, then we lose the ability for the screen reader to read the marker out as it reads the item.
Comment 20 Myles C. Maxfield 2023-07-19 09:13:18 PDT
This is important for klreq. See https://w3c.github.io/klreq/gap-analysis/#issue53_vertical_text
Comment 21 r12a 2023-07-21 06:06:47 PDT
It's also important for Chinese, Japanese, and Mongolian.
See https://www.w3.org/TR/clreq-gap/#issue249_vertical_text
Comment 22 Andrew Gioia 2024-03-09 05:24:46 PST
Hi all, is there any update on fully implementing the `::marker` pseudo-element? Specifically adding support for the `content` property? Firefox and Chrome both fully support this. 

I'd like to +1 content in particular for all the reasons here as well as the fact that it would create a third pseudo-element to accept content for some advanced CSS designs.