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
<rdar://problem/57257364>
Also the font-kerning property. Once I finish the implementation of ::marker in Chromium, I can try to port patches into WebKit.
Daniel: it looks like you added support for ::marker (with https://trac.webkit.org/changeset/22020) -- is this an expected limitation?
I added ::marker support. What is the question?
(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`.
(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.
Just for me, closest I could find was 07/26/2017: <https://github.com/w3c/csswg-drafts/blob/d0f08fdb814ca1edab5281ec54b3d4be478d9cd4/css-pseudo/Overview.bs>
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!
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.
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
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
(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.
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
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!
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?
(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!
(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
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.
This is important for klreq. See https://w3c.github.io/klreq/gap-analysis/#issue53_vertical_text
It's also important for Chinese, Japanese, and Mongolian. See https://www.w3.org/TR/clreq-gap/#issue249_vertical_text