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