Csswg-drafts: [css-lists][css-pseudo] the 'content' property should apply to ::marker

[MatsPalmgren]

The spec for the content property says that it applies to tree-abiding pseudo-elements. ::marker is a tree-abiding pseudo-element, however it explicitly excludes the content property.

I think this is a mistake, the ::marker pseudo would be much more useful if content could be used on it. Making ::marker more like ::before/::after would also make it easier to understand, to specify and implement, since it wouldn't need to be treated specially. I think this would benefit all stake holders:

• spec authors: could stop duplicating parts of content in list-style-image and list-style-type and instead share more spec text for ::marker/::before/::after.
• implementors: instead of writing a lot of specialized code for "list markers", we could re-use the code we already have for ::before/::afterto also handle ::marker. This means less code to write and maintain.
• authors: adding support for the content property would make ::marker significantly more powerful.
• end users: hopefully, the improvements in all levels above will result in richer content and less buggy and more compatible browsers for users to enjoy.

[frivoal]

WFM. And then we just define that the content: normal (which is the initial value) computes to do the right thing based on the list-style-* properties.

[emilio]

FWIW there's a precedent for content not applying to tree-abiding pseudos, like ::placeholder.

[patrickdark]

As an author, I'd expect ::placeholder to default to content: attr(placeholder); (for input elements) after attr() values are supported at which point it'd have to support the content property.

[ExE-Boss]

In all current major browsers, string attr() values are fully supported on the content property.

It’s the fallback value and typed attr() values that are unsupported.

[patrickdark]

Hmm... I was thinking of https://bugzilla.mozilla.org/show_bug.cgi?id=1481150, where content: attr() should generally work on everything.

[fantasai]

The current spec for ::marker was intentionally limited to make it easier to implement and to not be dependent on fully defining marker layout. We do intend that it will eventually apply. However the Lists and Generated Content modules are in a pretty rough state at the moment.

[fantasai]

@MatsPalmgren If you have this implemented, I'm happy to add it to the spec. But let me know if you think it'll add a hard dependency on defining marker layout? In which case maybe I'd suggest adding it as a note of future expectations for when we actually have a definition of marker layout...

[MatsPalmgren]

@fantasai we've implemented it by following the same code path as for ::before/::after in box construction / layout (when content is specified). We've added a few tweaks for list-style-position:outside to make it compatible with our old layout that we should specify (in css-lists). We haven't implemented position:marker at all and I believe it wouldn't be web-compatible as currently specified because "counts as absolutely positioned" would give it the wrong stacking level for painting. We also haven't implemented the marker-side property (yet). I'll file a separate spec issue with the details on how we do layout for outside. Layout for inside should work pretty much exactly as for ::before/::after.

If content isn't specified, then we still use our legacy layout code (aka nsBulletFrame). We've only updated it to use the new list-item counter and use ::marker styles. My goal for the future is to generate a content node from list-style-type etc and then use the same code for everything (and then remove nsBulletFrame).

I don't think you need to block this on layout details for list-style-position:outside since that's under-specified anyway at the moment and the tweaks we added are fairly minor and not really related to the content property per se.

[fantasai]

@MatsPalmgren Yeah, position: marker and marker-side are quite explicitly marked as DO NOT IMPLEMENT in the spec. :) https://www.w3.org/TR/css-lists-3/#positioning-markers https://drafts.csswg.org/css-lists-3/#positioning They'll probably be deferred to L4 for the next publication...

[MatsPalmgren]

@fantasai I filed #3771 with some more details on our new list-style-position:outside layout and some thoughts on position:marker.

[fantasai]

@MatsPalmgren - Tab and I cleaned up the Lists spec last week and defined the content interaction more precisely in https://drafts.csswg.org/css-lists-3/#content-property so I think this should be pretty straightforward to add now. Agenda+ to confirm incorporating it into that section and adding it to the list of properties in css-pseudo-4.

[css-meeting-bot]

The CSS Working Group just discussed the 'content' property should apply to ::marker, and agreed to the following:

• RESOLVED: the 'content' property should apply to ::marker

The full IRC log of that discussion

<dael> Topic: the 'content' property should apply to ::marker

<dael> github: https://github.com/w3c/csswg-drafts/issues/3499

<dael> fantasai: Moz has impl of this. TabAtkins and I cleaned up lists spec so what it needs to do with content interaction should be well defined. Proposal is to add the conten property back into pseudo elements applying to ::marker

<dael> AmeliaBR: Content still set auto based on list prop?

<dael> fantasai: Yes. Initial value is normal and thattakes content from list style prop

<dael> AmeliaBR: So an author wouldn't have ot set content prop for marker to be rendered but could override it if want to do something special

<dael> fantasai: Yes

<dael> AmeliaBR: Makes sense to me

<dael> fantasai: Any objections?

<dael> plinss: Objections?

<dael> gregwhitworth: Curious about use case. If they're in disc mode they'd replace with a new disc type?

<dael> fantasai: background and display don't apply to markers. Case is I have an <ol> and I might want to change to include the chapter number or I might decide I want outside list marker styling and turn my headers into list items. You could do those kind of things

<dael> gregwhitworth: How different then increment stuff?

<dael> fantasai: You can say I want to use this piece of text. May or may not include a counter. More flexibility in terms of what you want in terms of things like punct

<dael> AmeliaBR: Lots of use cases <ol> 20-1 but 3 2 1 are bronze/silver/gold

<dael> fantasai: multipart listing is one of the biggest use cases. We should put an example in spec

<dael> plinss: Objections?

<dael> RESOLVED: the 'content' property should apply to ::marker

[fantasai]

Was also noted that we should definitely add some examples to the spec for common cases like 2.4.7 list numbering.