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: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 457718



Sign in to add a comment

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

Project Member Reported by domenic@chromium.org, Feb 25 2016

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: https://github.com/whatwg/html/issues/722

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 https://drafts.csswg.org/css-lists-3/#marker-pseudo-element 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 https://github.com/whatwg/html/issues/722 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 tkent@chromium.org, Feb 26 2016

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

+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.
Cc: dominicc@chromium.org
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: https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d Mentions this related FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1283989

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.
Cc: timloh@chromium.org
Owner: dominicc@chromium.org
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.
I've uploaded a patch for the summary/display: block author rule counter at https://codereview.chromium.org/2122613002 This is not 100% comprehensive but should put a lower bound on how prevalent this is.
Project Member

Comment 6 by bugdroid1@chromium.org, Jul 6 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14ef05cd9985903f9d239853dd0b2479aa70914c

commit 14ef05cd9985903f9d239853dd0b2479aa70914c
Author: dominicc <dominicc@chromium.org>
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.

BUG=590014

Review-Url: https://codereview.chromium.org/2122613002
Cr-Commit-Position: refs/heads/master@{#403848}

[add] https://crrev.com/14ef05cd9985903f9d239853dd0b2479aa70914c/third_party/WebKit/LayoutTests/fast/css/usecounter-summary-display-block.html
[modify] https://crrev.com/14ef05cd9985903f9d239853dd0b2479aa70914c/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp
[modify] https://crrev.com/14ef05cd9985903f9d239853dd0b2479aa70914c/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/14ef05cd9985903f9d239853dd0b2479aa70914c/tools/metrics/histograms/histograms.xml

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?
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].

[1] https://github.com/necolas/normalize.css/commit/5e5496c026a0211ac2fdfd62cb59e25455dced55
[2] https://github.com/necolas/normalize.css/issues/604
Thanks for the pointers!
FWIW here is the use counter; it's collecting data:

https://www.chromestatus.com/metrics/feature/timeline/popularity/1434

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.
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.
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.
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. ^_^
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.
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.
Cc: -timloh@chromium.org meade@chromium.org e...@chromium.org
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:
https://codereview.chromium.org/2373963002

which fixed this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=603928

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

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.

@domenic:

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.
Firefox has implemented this quite a while ago. I can try to get them to comment here.

Comment 19 by t...@mozilla.com, 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>: https://dxr.mozilla.org/mozilla-central/rev/8dd496fd015a2b6e99573070279d9d1593836ea9/layout/style/res/html.css#792-806

I am not aware of any bug filed complaining about the summary triangle disappearing on other display values.
Owner: ----
Status: Available (was: Assigned)
Bulk disowning per sshruthi's email about bug triage best practices.

Comment 21 by kochi@chromium.org, Oct 23 2017

Blockedon: 457718

Sign in to add a comment