::marker
pseudo-element represents the
automatically generated marker box of a list item.::before
and ::after
, ::marker
is a tree-abiding pseudo-element, so it always fit within the box
tree.::before
and ::after
,
currently it only accepts a small subset of safe properties,::marker
, not ::before::marker
nor ::after::marker
(see crbug.com/1097992).::before
and ::after
, ::marker
appears in the Elements panel of the
DevTools,Interoperability and CompatibilityIs this feature fully tested by web-platform-tests?
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 supportcontent
,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 withdisplay: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.
--
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.
Does this intent include supporting ::marker for <details> elements, as I believe Firefox does?
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.
::marker
,
https://drafts.csswg.org/css-pseudo-4/#marker-pseudowhite-space
, which was added later.layout.css.marker.restricted
flag,
defaulting to true,
which when set to false allows arbitrary properties.::marker
has content:normal
.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
.::marker
has content:normal
.color
and font-*
properties.text-combine-upright
.content
would require
some big
refactorings.text-combine-upright
property is kind of a special
case. It should
work according to the spec, but:::marker
::marker
doesn't have content:normal
.::marker
selector.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. :)
div, :not(*)::marker {
color: blue;
}
has no effect right now on Chrome, but it will make all div
s
blue when I
ship ::marker
.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:
So this is just the 1st step :)
--
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/a2d5a21b-2985-57ca-6a90-4b9e9a144cb4%40inkedblade.net.
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-NWRcCR3rVeyR6t-ci1oNKB7QPHRyUDjmpfH4rFeEUnw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa5c9d71-15a0-ce6b-e248-895ec5cbf4d8%40gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2d5a21b-2985-57ca-6a90-4b9e9a144cb4%40inkedblade.net.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-NWRcCR3rVeyR6t-ci1oNKB7QPHRyUDjmpfH4rFeEUnw%40mail.gmail.com.
--
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.