Replace STEP 1 by this:

Create a details element and set 'display: flex' for it


Sorry

Thanks for the report.Able to reproduce the issue on Mac 10.11.6,Win 7 and Ubuntu 14.04 using latest stable 52.0.2743.116 and canary 54.0.2822.0.
This is a non-regression issue since 29.0.1535.0.

Note : Its working fine on FireFox 48.0.

 Issue 635284  has been merged into this issue.

I made two different issues:  Issue 635284  and this one, since I am not sure they are equivalent: details tag can be toggled, summary tag can't.

It didn't work for me on Firefox 48.0 (on Kubuntu 14.04), although I have enabled the details property (about:config > details)

<summary> was previously filed as  bug 603928 

The underlying issue is similar for the two of them:
LayoutObject* HTMLDetailsElement::createLayoutObject(const ComputedStyle&)
{
    return new LayoutBlockFlow(this);

Should check the style and create flexbox (or grid) if necessary.

Hello
I have started creating a patch for this one!

That's great! When you're ready, I am happy to review, unless you already have someone else in mind.

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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 795217  has been merged into this issue.

I'm not sure we want to change <details>. From https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements :

The details element is expected to render as a block box. The element's shadow tree is expected to take the element's first summary element child, if any, and place it in a first block box container, and then take the element's remaining descendants, if any, and place them in a second block box container.

That would seem to mean that

<details>
  <summary>text<div>text in a block</div></summary>
  <p>thing 1</p>
  <aside>thing 2</aside>
</details>

would render as

<div display:block>
  <div display:block>
    <summary>text<div>text in a block</div></summary>
  </div>
  <div display:block>
    <p>thing 1</p>
    <aside>thing 2</aside>
  </div>
</div>

Aside from showing a marker, that's roughly what Blink and FF do today, at least with respect to <details> (They do different things for <summary display:inline>, and Edge doesn't implement these elements at all yet.)

"Roughly" because <details display:inline> creates what I think is an atomic inline-level box, not a block box.

But there is an open issue about allowing <details> to honor the display property: https://github.com/whatwg/html/issues/1839

So, what we have now matches FF and at least mostly matches the spec, so we should probably leave it alone.

Oops, scratch the github link from comment 12. It's about <summary>, not <details>

+Tab, fantasai for input on comment 12

I think generally that any time HTML creates some kind of magical display that can't be replicated with CSS, we run into problems. See, e.g. FIELDSET and LEGEND, which gives everyone a headache: implementers and authors both.

I don't understand why DETAILS requires these anonymous boxes, other than the HTML spec for some reason thought it was necessary to create the second one in order to hide the contents when DETAILS is collapsed... I think it would make more sense to just pull that content from the rendering tree (using magic if necessary at that level), but otherwise let DETAILS and its contents render as a normal CSS box.

fatansai -- so you're basically saying that <details style="display:flex"> should work, and make it be a flex container?

Thanks for weighing in.

We might have compat problems honoring display, esp since FF, Safari and Chrome all ignore it.

Ideally, yes. I think authors like being able to style things however they want, and the chief role of HTML is semantics and behavior, not visual layout--that's CSS’s job.

No idea what the web compat would be, but changing 'display' is typically not done with blanket selectors so it might be okay.

A fairly straightforward underlying model would be that the relevant SUMMARY element is shifted to be first in the box tree, and then everything else is essentially given 'display: none' (or whatever) when the DETAILS is closed. We can't actually replicate this with CSS, since block layout doesn't honor the 'order' property and because we can't select text nodes and assign them style rules that make them hidden--but at least this way everything in the box tree is fully addressable and styleable by the author.

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

commit 183998281461800a8278bfa54ce69ee389e8b7ec
Author: David Grogan <dgrogan@chromium.org>
Date: Fri Sep 07 00:51:14 2018

Add test asserting the display property of <details> is ignored

Chrome, Safari, and Firefox pass. Edge hasn't implemented yet.

The test still holds for the proposed new spec text in
https://github.com/whatwg/html/pull/3686

This scenario is discussed at the end of
https://github.com/whatwg/html/issues/603 but the conclusion drawn
appears (to me) to be opposite what Chrome, Safari, and Firefox do.

Related other issues:
https://github.com/w3c/csswg-drafts/issues/2084
https://github.com/whatwg/html/issues/1839

Bug: 635282
Change-Id: Ice95225b3c9d5d90b80c657643d036490fd2e1b2
Reviewed-on: https://chromium-review.googlesource.com/1153651
Commit-Queue: David Grogan <dgrogan@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589388}
[add] https://crrev.com/183998281461800a8278bfa54ce69ee389e8b7ec/third_party/WebKit/LayoutTests/external/wpt/html/rendering/the-details-element/details-display-property-is-ignored-ref.html
[add] https://crrev.com/183998281461800a8278bfa54ce69ee389e8b7ec/third_party/WebKit/LayoutTests/external/wpt/html/rendering/the-details-element/details-display-property-is-ignored.html