Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't force <details> to be a block. #9830

Open
emilio opened this issue Oct 3, 2023 · 5 comments · May be fixed by #10265
Open

Don't force <details> to be a block. #9830

emilio opened this issue Oct 3, 2023 · 5 comments · May be fixed by #10265
Labels
topic: rendering

Comments

@emilio
Copy link
Contributor

emilio commented Oct 3, 2023

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements says:

The details element is expected to render as a block box.

This effectively ignores display set on the details element, so if you want to set display: flex, for example, you're out of luck.

This bites authors, even very experienced ones. The last one I'm aware of in bug 1856374.

There's no particular reason that this has to be the case. Probably it had to be the case before <details> was specified in terms of Shadow DOM, but now I'm not aware of any reason for this.

This was discussed in the CSSWG when @dbaron brought up https://github.com/dbaron/details-styling. He probably has a bunch more context on this stuff, but I think lifting this restriction should be uncontroversially better, if we can get away with it.
@pragyamishra56

This comment was marked as spam.

Sign in to view
@dbaron
Copy link
Member

dbaron commented Oct 3, 2023

I am interested in working on fixing this, as discussed in the CSS WG meeting in July -- as part of trying to make the details element more styleable. I've prototyped this change and some other changes in Chromium in https://crbug.com/1469418 , but with the intent of experimenting with what I prototyped and likely making major changes. I got a bunch of feedback from @bramus who tried to use the prototype to build a bunch of things with it, and I'm part of the way done going through that feedback (but currently sidetracked to get some other things done). Once I do that, I need to (possibly not in this order) write some major updates to https://github.com/dbaron/details-styling to reflect what it is that I've prototyped, probably try to get another round of feedback from @bramus and hopefully build a few more demos, and start making some more concrete proposals for what to change in some combination of the Open UI CG / the CSS WG / the HTML spec. I'm hoping to get back to working on that sometime later this month.

@martinthomson
Copy link

Here's an example of something I just tried to do and failed due to this (surprising) property: https://developer.mozilla.org/en-US/play?id=qbeKgiwJ2WxDjsbUmJNfYhVslwx4xw4CMyqPgebp2%2BICmuMP9DjzHQ0UcN344sA34UImTFR%2Bhg9YsIYY It would make me happy if @dbaron was able to fix this.

@dbaron
Copy link
Member

dbaron commented Feb 9, 2024

I'd like to slightly broaden this issue to cover both the <details> and <summary> elements. In at least Chromium and WebKit the <summary> element also has restrictions on its display type; I've prototyped removing both sets of restrictions behind a flag, as noted above.

I need to do some further investigation on whether those restrictions are supported by statements in the HTML spec... but if they are I'd like to remove such statements along with the statements restricting <details>.

@emilio
Copy link
Contributor Author

emilio commented Feb 9, 2024

<summary> in Gecko doesn't have such restriction, fwiw.

@dbaron dbaron mentioned this issue Feb 9, 2024
Open
dbaron added a commit to dbaron/html that referenced this issue Apr 9, 2024
@dbaron
Specify the rendering of <details> in more detail.
30c42a5 
This makes a number of related changes to specify the rendering of the
<details> element:

* It specifies the structure of the user agent shadow tree.  This
  appears largely interoperable between implementations with the
  exception of the style or link element for the default summary styles:
  Gecko uses a link element as the first child, Chromium uses a style
  element as the last child, and WebKit does not use a style element
  (see below).  This specifies a style or link as the first child.
* It specifies the existence of the default summary and the presence of
  UA dependent text inside of it.  This is present in all of Chromium,
  Gecko, and WebKit.
* It specifies the styles needed for the default summary.  These match
  Chromium and Gecko.  (These are not present in WebKit because WebKit's
  mechanism for styling the marker does not match the existing spec.)
* It removes the restriction that <details> is a block and cannot be
  changed.  This is prototyped in Chromium and Gecko.  This fixes whatwg#9830.
* It specifies that the summary element is display: block by default.
  This matches all of Chromium, Gecko, and WebKit.
* It specifies which element matches the ::details-content
  pseudo-element.  (TODO: This needs to be specified in CSS)  This is
  prototyped in Chromium.

See w3c/csswg-drafts#9879 and
w3c/csswg-drafts#9951 for more background.
@dbaron dbaron linked a pull request Apr 9, 2024 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: rendering
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Specify the rendering of <details> in more detail. dbaron/html
4 participants
@martinthomson @dbaron @emilio @pragyamishra56