New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 12 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 457718

Sign in to add a comment

Issue 590014: Implement <details>/<summary> disclosure triangle as a list item with ::marker

Reported by, Feb 25 2016 Project Member

Issue description

Firefox is implementing <details> and raised a question on the spec of what the styles should be for <summary> and how to allow the disclosure triangle to be overridden:

The conclusion, guided by the CSS experts Tab and Fantasai, is that summary should have the user agent styles

summary {
  display: list-item;
  list-style: disclosure-closed;
details[open] > summary {
  list-style: disclosure-open;

This will create a ::marker pseudo element per which would make the marker stylable/hidable/etc. by authors.

I wanted to file this bug for two purposes:

1. To find out ASAP if Blink has any objections to this direction for the spec and for Firefox.
2. To eventually get this setup implemented in Blink (which maybe depends on other work around ::marker and such).

If there are any objections, please let us know in as soon as possible. Otherwise, I imagine this might not be too high priority, but it's probably good to have a bug tracking aligning with Firefox and (soon) the spec.

Comment 1 by, Feb 26 2016

Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)
The proposed change sounds nice.

Comment 2 by, Feb 26 2016

+1, but I don't count as I suggested it. ^_^

This does not rely on us implementing ::marker at all.  You can style the <summary> marker the same way you style the <li> marker, ::marker just makes that a bit easier.

The one potential issue is that if there's a significant amount of code that currently sets <summary> to display:block, us adopting this will mean those pages will lose their disclosure triangle.

Comment 3 by, Jul 4 2016

Labels: -Pri-3 -OS-All OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows Pri-2
Some discussion on GitHub and Twitter about Chrome not picking up this spec change yet: Mentions this related FF bug:

Naively counting display: block for summary will not be useful; that is the way our UA stylesheet has it. If we count this, we need to count summaries with display overriding the UA stylesheet. FWIW, GitHub appears to have some framework with reset CSS which sets summary to display: block explicitly.

Chrome's details shadow wraps things in an additional summary element which picks up the UA styles and display: block again, so this needs some untangling.

Comment 4 by, Jul 4 2016

Status: Started (was: Available)
I've pinged timloh for advice on how to count this style. Seems necessary to hook StyleResolver or ElementRuleCollector or something.

Comment 5 by, Jul 4 2016

I've uploaded a patch for the summary/display: block author rule counter at This is not 100% comprehensive but should put a lower bound on how prevalent this is.

Comment 6 by, Jul 6 2016

Project Member
The following revision refers to this bug:

commit 14ef05cd9985903f9d239853dd0b2479aa70914c
Author: dominicc <>
Date: Wed Jul 06 04:02:57 2016

Add a use counter for author rules setting display: block on summary.

The HTML spec says to use list-item rendering to display the summary
element. This lets authors control how the disclosure triangle is
rendered with list-style-type, etc.

Today, Chromium uses display: block for the summary element. Changing
to list-item would mean authors who set display: block on summary will
not see the disclosure triangle any more.

This patch adds a use counter for pages which set display: block on
summary in author rules.


Cr-Commit-Position: refs/heads/master@{#403848}


Comment 7 by, Jul 6 2016

Labels: -Type-Feature Hotlist-Interop Type-Bug
OK, now we wait to collect counter data.

If setting display: block SUMMARY is not common I will start changing how DETAILS/SUMMARY are styled in the Earth northern hemisphere fall.

Do you think I should measure any other display: values?

Comment 8 by, Jul 6 2016

display:block on <summary> is unfortunately pretty common, as it's been in normalize.css since February 2012 [1]. The issue should be corrected soonish, though [2].


Comment 9 by, Jul 12 2016

Thanks for the pointers!

Comment 10 by, Jul 12 2016

FWIW here is the use counter; it's collecting data:

We need to wait until M54 is in stable to get an idea of how prevalent this is. If I had to guess I think it is going to come in between 0.002 and 0.01% and we'll be able to fix this.

Comment 11 by, Sep 20 2016

This has been collecting data for a while now and it looks like we can safely make this change. display: block is applied to SUMMARY on 0.00020% of page loads.

Comment 12 by, Sep 20 2016

Issue 457718 is to implement ::marker. (Note that we're not blocked on that.)

Tab, should I add a use counter to the ::-webkit-details-marker pseudoselector before removing it? We looked at how often people are setting display: block on summary but not how often they're styling the marker.

Comment 13 by, Sep 20 2016

I'm okay with not doing that, and just assuming it's safe to remove - I see very little mention of details-triangle styling in the wild.  People will probably ask for that information when the "Intent to Remove" is filed, tho. ^_^

Comment 14 by, Jan 24 2017

Is there any current update on the work going on here? I see the stats peaked at 0.035% of page loads for the author setting display block. However it has gone back down over time. Not sure if the peak offsets the chances that these changes will get made.

Comment 15 by, Jan 25 2017

Labels: Hotlist-GoodFirstBug
Status: Assigned (was: Started)
We'd like this to happen, but we haven't had a chance to make it happen. If someone can help out, I can guide what needs to be done. Rough plan:

1. Send an Intent to Deprecate and Remove to blink-dev
2. Add a deprecation warning when the CSS parser sees rules like that
3. Hang out in hammocks with beverage of choice for one release
4. Change the default UA stylesheet and use generated content for the marker; find or add web platform tests for it, etc.

Comment 16 by, Mar 15 2017

This is a fairly large project on the style team and layout tree side, meade@ and eae@ would need to prioritize the work to use LayoutListItem for this purpose.

The UseCounter is also measuring the wrong thing, it's checking specifically for block:
toCSSIdentifierValue(*value).getValueID() == CSSValueBlock

but authors set the summary element to all kinds of display values, and indeed we support that inside HTMLSummaryElement::createLayoutObject:

if (display == EDisplay::Flex || display == EDisplay::InlineFlex ||
      display == EDisplay::Grid || display == EDisplay::InlineGrid)
    return LayoutObject::createObject(this, style);

and making the <summary> not support being flexbox is a regression over the fix that landed here:

which fixed this bug:

and indeed losing the disclosure triangle whenever you want to arrange the things inside the <summary> using flex feels unfortunate.

Comment 17 by, Mar 15 2017


Good point; I suppose that use counter should be counting various display values. Which ones? All of them except display: list-item?

I'm curious about your use of the word "is" in "making the <summary> not support being flexbox is a regression." This did not happen yet, right? "is" is the present tense of "to be". So if we did this, then it /would be/ a regression.

"making the <summary> not support being flexbox" also sounds like a bit of an exaggeration. In practice wouldn't this just mean you don't see the disclosure triangles if you style it that way? This seems like the typical backwards compatibility/interop/conformance question.


It looks like we need to synchronize state with other vendors. We measured the use of display: block on summary and it is not used much; but we're not sure about other values of display and need to investigate. Users noticed that flexbox did not work with summary, for example. We'd like to know if any browsers made this change and if they're seeing complaints about the summary triangles not appearing.

Comment 18 by, Mar 15 2017

Firefox has implemented this quite a while ago. I can try to get them to comment here.

Comment 19 by, Mar 16 2017

Firefox has been using "display: list-item" for <summary> to render the triangle since we shipped the feature, but we don't support ::marker yet.

The UA for <details> and <summary>:

I am not aware of any bug filed complaining about the summary triangle disappearing on other display values.

Comment 20 by, Aug 22 2017

Owner: ----
Status: Available (was: Assigned)
Bulk disowning per sshruthi's email about bug triage best practices.

Comment 21 by, Oct 23 2017

Blockedon: 457718

Comment 22 by, Oct 23

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit - Your friendly Sheriffbot

Comment 23 by, Oct 28

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment