Intent to Ship: CSS ::marker pseudo-element

177 views
Skip to first unread message

Oriol Brufau

unread,
Jul 8, 2020, 8:17:20 AM7/8/20
to blink-dev
Contact emails
obr...@igalia.com

Explainer
https://developer.mozilla.org/en-US/docs/Web/CSS/::marker

Design doc/Spec
https://drafts.csswg.org/css-pseudo-4/#marker-pseudo
https://drafts.csswg.org/css-lists-3/#marker-pseudo

TAG review
A TAG review doesn't seem necessary. It's a minor feature and Firefox and Safari already shipped it.

Summary
The ::marker pseudo-element represents the automatically generated marker box of a list item.

Like ::before and ::after, ::marker is a tree-abiding pseudo-element, so it always fit within the box tree.

But unlike ::before and ::after, currently it only accepts a small subset of safe properties,
because the marker box layout is mostly undefined.

Note this intent only covers ::marker, not ::before::marker nor ::after::marker (see crbug.com/1097992).
These would need more work in the style resolver, and are not supported on Firefox nor Safari.

Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8v7pouXxxAc

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Debuggability
Like ::before and ::after, ::marker appears in the Elements panel of the DevTools,
as the first child of every list-item element.

Risks
Interoperability and Compatibility
Low interoperability risk
Already shipped by Firefox and Safari

Low compatibility risk
This feature only adds a new CSS pseudo-element, which is unlikely to break any web content.

Gecko: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=205202)

WebKit: Shipped (https://bugs.webkit.org/show_bug.cgi?id=141477)
However, it doesn't support content, direction, unicode-bidi nor some font properties.
And it can't follow a ::slotted() selector despite being tree-abiding.

Web developers: Positive
https://www.smashingmagazine.com/2019/07/css-lists-markers-counters/
https://stackoverflow.com/questions/4572353/do-any-browsers-support-the-css3-pseudo-element-marker

Ergonomics
This feature will be frequently used in tandem with display:list-item.
It may also be used together with ::before and ::after as an extra way
to display contents inside an element without including them in the DOM.

This feature is less customizable than ::before and ::after,
so the performance impact won't be worse than for these.

Activation
It won't be challenging for developers to take advantage of ::marker,
they only need to include a rule in their stylesheet with the ::marker selector,
and specify the desired style declarations.
Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/css/css-pseudo?q=marker
https://wpt.fyi/results/css/css-lists?q=nested-marker

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6710566854852608


Chris Harrelson

unread,
Jul 8, 2020, 11:10:38 AM7/8/20
to Oriol Brufau, blink-dev
LGTM1!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/679984af-0c1f-315c-07cf-d1fc66087eea%40igalia.com.

PhistucK

unread,
Jul 8, 2020, 11:18:10 AM7/8/20
to Oriol Brufau, blink-dev
I would say there is a moderate interoperability risk if Chrome supports more/less properties than others, which, as you indicated, is the case.
These differences are very annoying and surprising to developers and it would be best if you could work with the others so that the supported properties are aligned.

Also (but much less important or concerning), since ::marker will be valid, it means entire selectors that include it that were previously ignored will become valid, right (or maybe Chrome never invalidated entire selectors?)? Regardless, this is a form of user agent detection and so I do not mind. :)

PhistucK


Domenic Denicola

unread,
Jul 8, 2020, 2:03:30 PM7/8/20
to Oriol Brufau, blink-dev

Does this intent include supporting ::marker for <details> elements, as I believe Firefox does?

Oriol Brufau

unread,
Jul 8, 2020, 2:11:01 PM7/8/20
to PhistucK, blink-dev
I would say there is a moderate interoperability risk if Chrome supports more/less properties than others, which, as you indicated, is the case.
These differences are very annoying and surprising to developers and it would be best if you could work with the others so that the supported properties are aligned.
The spec lists the properties allowed in ::marker, https://drafts.csswg.org/css-pseudo-4/#marker-pseudo

Firefox supports the properties listed in the spec, except for white-space, which was added later.
It also has a layout.css.marker.restricted flag, defaulting to true, which when set to false allows arbitrary properties.
However, some properties don't work well when the ::marker has content:normal.

Chrome supports these properties and also white-space, animation-* and transition-*.
animation-* and transition-* are not yet in the spec, but there is a CSSWG resolution to add them, so I included them.
white-space only works for inside markers, otherwise the style adjuster enforces white-space:pre.
However, in legacy layout, some properties don't work well when the ::marker has content:normal.

WebKit is more limited, it only supports color and font-* properties.
The reason is that when it was implemented, the spec only listed these properties, and text-combine-upright.
Also, supporting properties like content would require some big refactorings.

The text-combine-upright property is kind of a special case. It should work according to the spec, but:
  • WebKit doesn't allow it in ::marker
  • Chromium theoretically allows it, but it doesn't actually work due to bug 1060007. It only forces legacy layout.
  • Firefox theoretically allows it, but it only works when the ::marker doesn't have content:normal.
So effectively there are some differences, but I don't think it's a blocker for the feature.
Implementations are not completely interoperable regarding marker layout, even without using the ::marker selector.
Even Chromium legacy and Chromium NG already have multiple behavior differences!

Also (but much less important or concerning), since ::marker will be valid, it means entire selectors that include it that were previously ignored will become valid, right (or maybe Chrome never invalidated entire selectors?)? Regardless, this is a form of user agent detection and so I do not mind. :)
That's right, a rule like
div, :not(*)::marker {
  color: blue;
}
has no effect right now on Chrome, but it will make all divs blue when I ship ::marker.
But I don't think this will break sites, otherwise Firefox and WebKit would have had this problem too.

-- Oriol Brufau

Oriol Brufau

unread,
Jul 8, 2020, 2:19:48 PM7/8/20
to Domenic Denicola, blink-dev

No, that's bug 590014

For now <summary> will continue having a ::-webkit-details-marker rather than a ::marker

I think that bug has 3 requirements:
  • Shipping ::marker
  • Implementing the disclosure-open and disclosure-closed values for the list-style-type property
  • Implementing the list-item automatic counter as a real counter (instead of magic)

So this is just the 1st step :)

-- Oriol Brufau

El 8/7/20 a les 20:03, Domenic Denicola ha escrit:

fantasai

unread,
Jul 8, 2020, 8:03:15 PM7/8/20
to blin...@chromium.org
On 7/8/20 11:10 AM, Oriol Brufau wrote:
>
> The spec lists the properties allowed in |::marker|,
> https://drafts.csswg.org/css-pseudo-4/#marker-pseudo
>
> Firefox supports the properties listed in the spec, except for |white-space|,
> which was added later.
> It also has a |layout.css.marker.restricted| flag, defaulting to true, which
> when set to false allows arbitrary properties.
> However, some properties don't work well when the |::marker| has |content:normal|.
>
> Chrome supports these properties and also |white-space|, |animation-*| and
> |transition-*|.
> |animation-*| and |transition-*| are not yet in the spec, but there is a CSSWG
> resolution to add them, so I included them.
> |white-space| only works for inside markers, otherwise the style adjuster
> enforces |white-space:pre|.
> However, in legacy layout, some properties don't work well when the |::marker|
> has |content:normal|.

Sorry, was behind on edits. Spec should be up-to-date with resolutions now.
https://www.w3.org/TR/css-lists-3/

In general, feel free to poke me if I'm slacking on the edits for something
you're working on. :)

~fantasai

Rick Byers

unread,
Jul 9, 2020, 10:55:47 AM7/9/20
to fantasai, blink-dev
LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Daniel Bratell

unread,
Jul 9, 2020, 2:08:44 PM7/9/20
to Rick Byers, fantasai, blink-dev

PhistucK

unread,
Jul 9, 2020, 5:56:17 PM7/9/20
to Daniel Bratell, Rick Byers, fantasai, blink-dev
Thank you for the detailed explanation.
I guess being the superset of the properties rather than the subset is a better place to be in, pushing others to implement more.
However, we should make sure we are not a subset in any way...

Self-interoperability is crucial. I personally find it unacceptable that the same browser supports one or more properties in a certain layout structure and not in another (legacy versus LayoutNG). This is extremely unpredictable and very, very bad for developers.
Sometimes a single property change on the ancestor would lead to legacy/LayoutNG being used and suddenly a property no longer applies to ::marker.
In my opinion, it would be best to disable the properties that are not supported across either of the layout engines and only keep the intersection supported for now. This is not Internet Explorer 6.

PhistucK


Oriol Brufau

unread,
Jul 11, 2020, 6:57:19 PM7/11/20
to blink-dev, phis...@gmail.com
Yes, Chromium will support more properties than the other browsers, except for 'text-combine-upright' in some cases.
Firefox may catch up with animation and transition properties in https://bugzilla.mozilla.org/show_bug.cgi?id=1637532

I agree that not supporting some properties in legacy is not optimal, actually shipping ::marker was delayed quite a bit because I made sure to support 'content' in legacy, which was not trivial.
Basically, the LayoutListMarker class was too simple, and I had to add new LayoutInsideListMarker and LayoutOutsideListmarker classes, based on LayoutInline and LayoutBlockFlow.
But it's true that some properties like 'unicode-bidi' or 'white-space' still won't work well with 'content: normal' in legacy layout.

My initial intention was removing LayoutListMarker completely, in favor of the new classes.
This would have made legacy markers behave much closer to LayoutNG ones, but would have had some performance cost, so keeping LayoutListMarker for 'content: normal' was deemed safer.

You are right that this makes the behavior more unpredictable, but this was already the case for list markers before introducing ::marker.
For example, if you set 'text-transform' or 'white-space' in the list item, it will affect the marker in LayoutNG but not in legacy.
Given that the differences were already there, I don't think this should block enabling some properties in ::marker.

-- Oriol Brufau

El dijous, 9 juliol de 2020 23:56:17 UTC+2, PhistucK va escriure:
Thank you for the detailed explanation.
I guess being the superset of the properties rather than the subset is a better place to be in, pushing others to implement more.
However, we should make sure we are not a subset in any way...

Self-interoperability is crucial. I personally find it unacceptable that the same browser supports one or more properties in a certain layout structure and not in another (legacy versus LayoutNG). This is extremely unpredictable and very, very bad for developers.
Sometimes a single property change on the ancestor would lead to legacy/LayoutNG being used and suddenly a property no longer applies to ::marker.
In my opinion, it would be best to disable the properties that are not supported across either of the layout engines and only keep the intersection supported for now. This is not Internet Explorer 6.

PhistucK


On Thu, Jul 9, 2020 at 9:08 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM3

/Daniel

On 2020-07-09 16:55, Rick Byers wrote:
LGTM2

On Wed, Jul 8, 2020 at 8:03 PM fantasai <fantas...@inkedblade.net> wrote:
On 7/8/20 11:10 AM, Oriol Brufau wrote:
>
> The spec lists the properties allowed in |::marker|,
> https://drafts.csswg.org/css-pseudo-4/#marker-pseudo
>
> Firefox supports the properties listed in the spec, except for |white-space|,
> which was added later.
> It also has a |layout.css.marker.restricted| flag, defaulting to true, which
> when set to false allows arbitrary properties.
> However, some properties don't work well when the |::marker| has |content:normal|.
>
> Chrome supports these properties and also |white-space|, |animation-*| and
> |transition-*|.
> |animation-*| and |transition-*| are not yet in the spec, but there is a CSSWG
> resolution to add them, so I included them.
> |white-space| only works for inside markers, otherwise the style adjuster
> enforces |white-space:pre|.
> However, in legacy layout, some properties don't work well when the |::marker|
> has |content:normal|.

Sorry, was behind on edits. Spec should be up-to-date with resolutions now.
   https://www.w3.org/TR/css-lists-3/

In general, feel free to poke me if I'm slacking on the edits for something
you're working on. :)

~fantasai

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

PhistucK

unread,
Jul 12, 2020, 2:42:33 AM7/12/20
to Oriol Brufau, blink-dev
The fact that this is already the case is "letting your change off the hook", I agree.
The fact that this is currently the case is really awful.

PhistucK

Reply all
Reply to author
Forward
0 new messages