David Baron :dbaron: Reporter
	Description • 9 years ago

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?

	David Baron :dbaron: Reporter
	Comment 1 • 9 years ago

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

	Xidorn Quan [:xidorn] UTC+11
	Comment 2 • 9 years ago

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

	Xidorn Quan [:xidorn] UTC+11
	Comment 3 • 9 years ago

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

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 4 • 8 years ago

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

	Xidorn Quan [:xidorn] UTC+11
	Comment 5 • 8 years ago

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

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 6 • 8 years ago

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

	David Baron :dbaron: Reporter
	Comment 7 • 8 years ago

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

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 8 • 8 years ago

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

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 9 • 8 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 8 years ago

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.

	Karl Dubost💡 :karlcow
	Comment 11 • 8 years ago

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

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 12 • 8 years ago

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

	Stephan Sokolow
	Comment 13 • 6 years ago

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.

	Stephan Sokolow
	Comment 14 • 6 years ago

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.

	Ting-Yu Lin [:TYLin] (UTC-8)
	Comment 15 • 6 years ago

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

	Stephan Sokolow
	Comment 16 • 6 years ago

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