Z-order of absolute div in <details> and <summary> #603

aethanyc · 2016-02-02T13:23:58Z

File this issue per request in Bug 591737 comment 234.

The question was the z-ordering of two absolutely positioned elements, where one is a child of the

and one is a child of the

that comes before

in the DOM (assuming neither

nor

are absolute containing blocks)

The test case is here. https://jsfiddle.net/aethanyc/mk2fd

Currently, both Chrome and Firefox implementation in progress in Bug 591737 put the absolute div in

in the back. It might be good to note the z-order of the children in

.

foolip · 2016-02-02T15:40:44Z

How is this implemented in Chrome and Firefox? Presumably there's no special casing of <details> or <summary>, but there's simply some default style that yields this computed style and layout?

@upsuper @bzbarsky

bzbarsky · 2016-02-02T16:27:28Z

There is totally special-casing of <details> and <summary> deep in the rendering engine at least in the Firefox implementation, because of the rendering requirement that this markup:

<details>
  <div>Hello</div>
  <summary>I am first!</summary>

put the summary before the "Hello" text in terms of what the user sees.

So specifically, here's the testcase under consideration:

<!DOCTYPE html>
<style>
  div { width: 100px; height: 100px; position: absolute; top: 0; left: 0 }
</style>
<body style="margin-top: 200px">
  <details open>
    <div style="background: purple"></div>
    <summary>
      <div style="background: yellow"></div>
    </summary>
  </details>
</body>

which shows a purple square in Chrome. This conceptually-similar testcase:

<!DOCTYPE html>
<style>
  .abspos { width: 100px; height: 100px; position: absolute; top: 0; left: 0 }
</style>
<body style="margin-top: 200px">
  <div>
    <div class="abspos" style="background: purple"></div>
    <div>
      <div class="abspos" style="background: yellow"></div>
    </div>
  </div>
</body>

shows a yellow box instead.

If you just look at rendering as defined by CSS, then per https://www.w3.org/TR/CSS21/zindex.html#painting-order step 8 the purple and yellow box should be painted in "tree order", where "tree order" refers to the rendering tree, not the DOM tree, per https://www.w3.org/TR/CSS21/zindex.html#stacking-defs

So the upshot is that the HTML spec needs to be explicit about the rendering tree produced by <details> and <summary>. Which is extra fun, because CSS doesn't really define the rendering tree so much last I checked.

Anyway, I looked at Chrome's implementation and it seems to be using a non-public shadow tree with an insertion point up front for the <summary> to do the reordering, which basically causes it to behave as if things were reordered in the DOM to start with (because in the flattened tree they are).

foolip · 2016-02-02T17:04:14Z

In https://html.spec.whatwg.org/#the-details-element-2 we have

The element's shadow tree is expected to take the element's first child summary element, 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.

The term "shadow tree" isn't linked to anything so this isn't well defined, but it sure sounds a lot like your description of Chrome's implementation.

bzbarsky · 2016-02-02T17:07:35Z

It's not clear to me that it matches the Chrome implementation in the specifics (e.g. I'm not seeing two separate containers), and it's not clear to me that it would match the actual behavior if those anonymous blocks are in fact not present in browsers. I'd have to think a bit about whether the anonymous blocks are observable...

Is there a reason to require the extra anonymous blocks?

foolip · 2016-02-03T08:07:34Z

I guess these anonymous 'block' box containers would be observable if all of the details element's children have display:inline, as only changing the order wouldn't introduce any block containers?

Taking a step back, is reordering of the first summary child really a good idea, and important part of this feature? The feature as a whole seems like something easily implemented using a library, but unfortunately it's already [https://www.chromestatus.com/metrics/feature/timeline/popularity/480](being used), so we can't just axe it.

bzbarsky · 2016-02-03T13:37:39Z

would be observable if all of the details element's children have display:inline

Ah, good catch. @aethanyc, what does your new Gecko implementation do in this case?

is reordering of the first summary child really a good idea

It's basically how <legend> works for fieldset...

foolip · 2016-02-03T15:18:09Z

Right, this isn't the only case of reordering for layout/rendering, another is thead discussed tangentially in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29018 (mostly about the rows collection)

If implementations already have shared and robust infrastructure for layout reordering I guess it's fine to have it all over the place, but if it's actually implemented on a per-case basis then it seems like a legacy things we should avoid adding more of. How is looking in the ongoing Gecko implementation?

bzbarsky · 2016-02-03T15:30:10Z

Gecko's stuff here is all pretty ad-hoc and likely buggy as hell once you start poking at it in any interesting way. For example, the current implementation doesn't support columns on summary, probably fails at correctly paginating overflow:scroll details elements, and likely other issues that I haven't thought of. It does support non-visible overflow on details and summary and columns on details, but those had to be specially hacked in by hand.

It looks to me like Blink has a nicer infrastructure for this stuff. I can't speak for other engines.

bzbarsky · 2016-02-03T15:31:16Z

I mean, I would be all in favor of not doing the reordering, if you can get WebKit and Blink to change their implementation...

aethanyc · 2016-02-03T17:22:13Z

@bzbarsky, here is the example that all the children of details are inline. https://jsfiddle.net/aethanyc/gtxetmbc/ In my implementation for Firefox, there's no block container for the summary, all the text is in one block. It's interesting to see that Safari has the same behavior with my implementation while Chrome's summary is on its own block.

I must admit that when I implement details & summary in Firefox, I do not notice spec says there must be an anonymous block to contain summary, and another block to contain all the other children of details until I see this discussion.

The original WIP by @heycam did have the two anonymous blocks. However I found that it's hard to get the correct layout if details has children with percentage height like this example. https://jsfiddle.net/aethanyc/ax6bep3d/ Thus, I remove the two anonymous blocks to get the height correct since the children will get correct css height calculation from their details parent, not the anonymous block.
Both Firefox and Safari will get the layout correctly while Chrome will have wrong "Div: 60% height".

bzbarsky · 2016-02-03T17:26:00Z

Oh, right, percentage heights are the reason introducing random anonymous blocks around block-level content causes problems... So I think we should not do that in this case, no matter what we do with the ordering of summary. And we should file a bug on Blink accordingly...

aethanyc · 2016-02-03T17:29:51Z

Gecko's stuff here is all pretty ad-hoc and likely buggy as hell once you start poking at it in any interesting way. For example, the current implementation doesn't support columns on summary, probably fails at correctly paginating overflow:scroll details elements, and likely other issues that I haven't thought of. It does support non-visible overflow on details and summary and columns on details, but those had to be specially hacked in by hand.

In gecko, it is hard to implementation the correct layout of details and summary with the combination of various css properties since I cannot easily reuse the code path which constructs normal block frame for details and summary. Perhaps it's a good time for some refactoring ...

sbesselsen · 2017-12-08T12:33:47Z

Hi all, I realize that this is an old issue and that I am not a browser developer, but I wanted to chime in and say that Chrome creating a shadow DOM div around the content of a details element is causing some real-world problems. I cannot use flexbox on a details element, for instance, because the DOM parent-child relation is lost. I understand the complexity but the current solution feels wrong. I understand that it's an edge case but I just wanted to keep this issue alive, if at all possible.

annevk · 2017-12-08T12:52:01Z

@sbesselsen that sounds like a separate issue to me. It also sounds like an implementation bug you can file at https://crbug.com/new. An element having a closed shadow tree attached does not affect the relationship with its children and should definitely not impact flexbox.

sbesselsen · 2017-12-11T09:58:57Z

@annevk Alright, I'll file the bug! Thanks for the reply.

Chrome, Safari, and Firefox pass. Edge hasn't implemented yet. The test still holds for the proposed new spec text in whatwg/html#3686 This scenario is discussed at the end of whatwg/html#603 but the conclusion drawn appears (to me) to be opposite what Chrome, Safari, and Firefox do. Related other issues: w3c/csswg-drafts#2084 whatwg/html#1839 Bug: 635282 Change-Id: Ice95225b3c9d5d90b80c657643d036490fd2e1b2

Chrome, Safari, and Firefox pass. Edge hasn't implemented yet. The test still holds for the proposed new spec text in whatwg/html#3686 This scenario is discussed at the end of whatwg/html#603 but the conclusion drawn appears (to me) to be opposite what Chrome, Safari, and Firefox do. Related other issues: w3c/csswg-drafts#2084 whatwg/html#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}

…of <details> is ignored, a=testonly Automatic update from web-platform-testsAdd 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 whatwg/html#3686 This scenario is discussed at the end of whatwg/html#603 but the conclusion drawn appears (to me) to be opposite what Chrome, Safari, and Firefox do. Related other issues: w3c/csswg-drafts#2084 whatwg/html#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} -- wpt-commits: 9d5d9aa80785d9726ed0a5eaab1a8d144fd4b560 wpt-pr: 12218

…of <details> is ignored, a=testonly Automatic update from web-platform-testsAdd 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 whatwg/html#3686 This scenario is discussed at the end of whatwg/html#603 but the conclusion drawn appears (to me) to be opposite what Chrome, Safari, and Firefox do. Related other issues: w3c/csswg-drafts#2084 whatwg/html#1839 Bug: 635282 Change-Id: Ice95225b3c9d5d90b80c657643d036490fd2e1b2 Reviewed-on: https://chromium-review.googlesource.com/1153651 Commit-Queue: David Grogan <dgroganchromium.org> Reviewed-by: Christian Biesinger <cbiesingerchromium.org> Cr-Commit-Position: refs/heads/master{#589388} -- wpt-commits: 9d5d9aa80785d9726ed0a5eaab1a8d144fd4b560 wpt-pr: 12218 UltraBlame original commit: 3e84907d855160d165c2989d9cdd7f53f9ab16d7

foolip added the clarification Standard could be clearer label Feb 3, 2016

annevk added the topic: rendering label Mar 29, 2016

chromium-wpt-export-bot mentioned this issue Aug 3, 2018

Add test asserting the display property of <details> is ignored web-platform-tests/wpt#12218

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Z-order of absolute div in <details> and <summary> #603

Z-order of absolute div in <details> and <summary> #603

aethanyc commented Feb 2, 2016

foolip commented Feb 2, 2016

bzbarsky commented Feb 2, 2016

foolip commented Feb 2, 2016

bzbarsky commented Feb 2, 2016

foolip commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

foolip commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

aethanyc commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

aethanyc commented Feb 3, 2016

sbesselsen commented Dec 8, 2017 •

edited

Loading

annevk commented Dec 8, 2017

sbesselsen commented Dec 11, 2017

Z-order of absolute div in <details> and <summary> #603

Z-order of absolute div in <details> and <summary> #603

Comments

aethanyc commented Feb 2, 2016

foolip commented Feb 2, 2016

bzbarsky commented Feb 2, 2016

foolip commented Feb 2, 2016

bzbarsky commented Feb 2, 2016

foolip commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

foolip commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

aethanyc commented Feb 3, 2016

bzbarsky commented Feb 3, 2016

aethanyc commented Feb 3, 2016

sbesselsen commented Dec 8, 2017 • edited Loading

annevk commented Dec 8, 2017

sbesselsen commented Dec 11, 2017

sbesselsen commented Dec 8, 2017 •

edited

Loading