Bug 204163 – list ::marker should accept content, and several writing-mode related properties

• Status: NEW
• Component: CSS

[Miriam Suzanne]

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

[Radar WebKit Bug Importer]

<rdar://problem/57257364>

[Oriol Brufau]

Also the font-kerning property.

Once I finish the implementation of ::marker in Chromium, I can try to port patches into WebKit.

[Mihai Parparita]

Daniel: it looks like you added support for ::marker (with https://trac.webkit.org/changeset/22020) -- is this an expected limitation?

[Daniel Bates]

I added ::marker support. What is the question?

[Mihai Parparita]

(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`.

[Daniel Bates]

(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.

[Daniel Bates]

Just for me, closest I could find was 07/26/2017: <https://github.com/w3c/csswg-drafts/blob/d0f08fdb814ca1edab5281ec54b3d4be478d9cd4/css-pseudo/Overview.bs>

[Ted Whitehead]

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!

[Ted Whitehead]

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).

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.

[Oriol Brufau]

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

[r12a]

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

[Oriol Brufau]

(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.

[r12a]

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

[Ahmad Saleem]

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!

[r12a]

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?

[Ahmad Saleem]

(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!

[Oriol Brufau]

(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

[Sommer Panage]

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.

[Myles C. Maxfield]

This is important for klreq. See https://w3c.github.io/klreq/gap-analysis/#issue53_vertical_text

[r12a]

It's also important for Chinese, Japanese, and Mongolian.
See https://www.w3.org/TR/clreq-gap/#issue249_vertical_text

[Andrew Gioia]

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.

[Karl Dubost]

A report has been added to Webcompat about this for the content property.
https://github.com/webcompat/web-bugs/issues/137820


```
.c-link-list-item[data-v-a43016dc]::marker {
    content: "\2726";
}
```

This is supported by Firefox and Chrome.

[Karl Dubost]

Related also https://wpt.fyi/results/css/css-pseudo?label=master&label=experimental&aligned&q=marker-content

[Woody Lee]

See Also https://bugs.webkit.org/show_bug.cgi?id=277662

[Tim Nguyen (:ntim)]

`isValidMarkerStyleProperty` is the right place for this

[Oriol Brufau]

Just enabling the properties in isValidMarkerStyleProperty won't do anything, see comment 18. Not a good first bug.