1221416 - Add support for styling the disclosure triangle of the <details> element using summary::marker

Status: RESOLVED DUPLICATE of bug 205202

(Core :: Layout, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm filing this as a separate bug (from bug 591737) on styling the disclosure triangle of the <details> element.

I talked to Ting-Yu about this a little bit on Monday, and to heycam a little bit today.

We should have a mechanism for styling the disclosure triangle that opens and closes for the <details> element.  We should consider (based on what other implementations have done) whether having such a mechanism should block shipping support for the <details> element.  (We should probably have a separate bug to track shipping it, separate from bug 591737 on implementing it.)

Apparently Blink has a pseudo-element for styling the disclosure triangle, though I don't know details, and I don't know if they shipped support for <details> prior to implementing that pseudo-element.  (Whether they did perhaps affects whether it's ok for us to ship <details> without it.)

I don't know if other engines have implemented <details>, and, if so, what they do for styling.

Another idea heycam pointed out today was to use the list-style-* properties for the triangle.  This fits reasonably well with the presence of disclosure-open and disclosure-closed counter styles (which could certainly be improved if they're not good enough visually).

There's also some question as to whether -moz-appearance:none should have an effect on any styling of the disclosure triangles (more likely turning it off entirely, although maybe just turning off platform-specific aspects of it and switching to something more generic).

Maybe Ting-Yu is interested in working on this bug after bug 591737 is landed?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://drafts.csswg.org/css-counter-styles/#simple-symbolic describes the disclosure-open and disclosure-closed counter styles

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

Styling the triangle could probably be part of the ::marker pseudo-element which is speced in https://drafts.csswg.org/css-pseudo-4/#marker-pseudo

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

We probably can map our existing ::-moz-list-bullet pseudo-element to the triangle, which would eventually be merged to ::marker.

Comment 4

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Due to the current implement, we get the ability for styling the triangle by summary::-moz-list-bullet [1] for free, but this can never be exposed to the user.

Webkit uses non-stardard pseudo-class summary::-webkit-details-marker for this.

I have sent a feedback to pseudo-elements spec as Xidorn suggested in comment #2. My message is waiting for approval. 

[1] https://dxr.mozilla.org/mozilla-central/rev/af6356a3e8c56036b74ba097395356d9c6e6c5a3/layout/reftests/details-summary/details-display-inline.html#10

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Ting-Yu Lin [:TYLin] (UTC+8) from comment #4)
> Due to the current implement, we get the ability for styling the triangle by
> summary::-moz-list-bullet [1] for free, but this can never be exposed to the
> user.

This pseudo element has been exposed to the web for long, and I think it is likely the prototype of the future ::marker.

Comment 6

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

See also the html spec issue https://github.com/whatwg/html/issues/722

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

... that spec issue has now been resolved via https://github.com/whatwg/html/pull/748 .

This is as suggested in the thread https://lists.w3.org/Archives/Public/www-style/2016Feb/thread.html#msg282 .

So I believe this is specified now.  (But if it's still unclear, you can raise further spec issues.)

Comment 8

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

This is the chromium bug for implementing the disclosure triangle as a list item with ::marker.
https://bugs.chromium.org/p/chromium/issues/detail?id=590014

Comment 9

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: Support summary::marker.

Not sure whether this patch make sense or not. It ignores li::marker and add
support only for summary::marker. Of course user won't be able to use
summar::-moz-list-bullet anymore. It's bug 205202 which needs to consider what
to do when both li::-moz-list-bullet and li::marker are specified. Luckily,
summary element does not have this backward compatibilty burden.

I would like to see that we ship details and summary with summary::marker rather
than summary::-moz-list-bullet.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8739325 [details] [diff] [review]
Support summary::marker.

This will add parsing for ::marker (e.g. in @supports rules) without actually having it work on list items, right?  That seems fairly strange to me.

Comment 11

[Karl Dubost💡 :karlcow]

So this is probably touching a Web Compatibility issue on GitHub. Maybe.

Context:

With the preview feature. They set 

    summary { display: block; } 

And this is removing the triangle widget.


The user agent stylesheet of Opera (blink) has for default.

     details { display: block; } 
     summary { display: block; } 

The user agent stylesheet for Gecko is:

     details { display: block; } 
     summary { display: block; } 
     details summary:first-of-type, 
     details summary:-moz-native-anonymous { 
            display: list-item; 
            list-style: disclosure-closed inside; } 

HTML Spec says something for `<details>` [3] but not really for `<summary>`.

The [default CSS][4] is indeed with a `display: block`

    `address, blockquote, center, div, figure, figcaption, footer, form, header, hr, legend, listing, main, p, plaintext, pre, summary, xmp { display: block; } `


[3]: https://www.w3.org/TR/html51/rendering.html#the-details-element-rendering
[4]: https://www.w3.org/TR/html51/rendering.html#non-replaced-elements-flow-content

Comment 12

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Gecko follows the latest whatwg spec to render the <summary> [1], and have changed the default style for <summary> to "display: list-item" in bug 1258657.

[1] https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements

Comment 13

[Stephan Sokolow]

What exactly does the spec require when it comes to layout interactions between the marker and the content?

...because, currently, unlike an <li> element, setting a contained <a> to "display: block" inside a <summary> to ensure it fills the full width of the parent will push it below the marker in both Firefox and Chromium.

This can be remedied in Chromium using the following CSS...

summary::-webkit-details-marker { 
  float: left; 
  padding: 0.6ex; /* Align the marker with the text */
}

...but I haven't found an equivalent for Firefox yet (given that I can't use "list-style-position: outside" because that breaks the intended highlight cue for keyboard navigation).

So far, the only candidate I can think of that would be portable would be to replace the marker entirely, since only Firefox supports disclosure-open and disclosure-closed.

Comment 14

[Stephan Sokolow]

Oh, to clarify *why* I'd want an <a> to fill the full width of the <summary> to the right of the marker, I'm building a collapsible tree of hyperlinks and I'm trying to match the look and feel of a more traditional GUI widget toolkit with as few JavaScript workarounds as possible.

That means making the <summary> element equivalent to a two-item horizontal flexbox with the marker being a fixed size and the link consuming the remaining space so that a background-color-based focus highlight looks correct.

Comment 15

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Re comment 13: 

In Firefox, perhaps you could make <summary> "display: block", and put <ul><li><a> in it like https://codepen.io/anon/pen/KxWroe

Comment 16

[Stephan Sokolow]

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #15)
> Re comment 13: 
> 
> In Firefox, perhaps you could make <summary> "display: block", and put
> <ul><li><a> in it like https://codepen.io/anon/pen/KxWroe

For now, I'll stick with hiding the marker and reinventing it using ::before.

To me, that feels like a case of "too clever for your own good" with the potential for introducing bigger headaches than it solves when things like accessibility and the potential for buggy DOM mutation code are taken into account.

Comment 17

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

We've fixed Bug 205202, so summary::marker {} is now valid.

Also, our internal details/summary tests have been updated to use summary::mark instead of summary::-moz-list-bullet in Bug 205202 Part 2. Thank you, Mats!