- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 23:06:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `improve styling of <details>/<summary> elements`, and agreed to the following:
* `RESOLVED: Expose the <details> contents slot as either a pseudo or a ::part, as decided in a joint meeting with WHATWG`
* `RESOLVED: We desire to have no restrictions on the stylability of the display of <details> and <summary>`
<details><summary>The full IRC log of that discussion</summary>
<dbaron> https://github.com/w3c/csswg-drafts/issues/9879#issuecomment-1936179742<br>
<fantasai> dbaron: Most of what I'll say here is in that comment ^<br>
<fantasai> dbaron: We discussed in Cupertino, and I did some prototyping since then.<br>
<fantasai> dbaron: Seemed people were more comfortable with pseudo-element approach than others<br>
<fantasai> dbaron: I prototyped that, also prototyped changes that allow more flexibility in what the display value of details and summary can be<br>
<fantasai> dbaron: one of the major problems is that brosers restrict the display values of one or both<br>
<fantasai> dbaron: restrictions on details are in the HTML spec actually<br>
<fantasai> dbaron: Bramus took some passes building demos, various ways that design systems use for disclosure widgets, so that you can do those with details + CSS<br>
<fantasai> dbaron: The pieces that were important to the demos were these six things<br>
<fantasai> dbaron: some we've already resolved on, but not yet shipping in all engines<br>
<fantasai> dbaron: 1. Changing display on details and summary<br>
<fantasai> dbaron: that's technically an HTML spec problem, maybe we can record an agreement on changing<br>
<fantasai> dbaron: 2. Specifying the styles that create the disclosure triangle<br>
<fantasai> dbaron: this is not interoperable: chrome and firefox do one thing, and webkit does something different<br>
<fantasai> dbaron: 3. Styling pieces of the widget that weren't addressable<br>
<fantasai> dbaron: I prototyped 2 pseudo-elements, ::details-summary and ::details-content<br>
<fantasai> dbaron: these address pieces already described in HTML spec<br>
<fantasai> dbaron: I removed ::details-summary, because it wasn't useful and was just confusing<br>
<fantasai> dbaron: since there's already an element there<br>
<fantasai> dbaron: ::details-content wraps the rest of the content<br>
<fantasai> dbaron: I hope we can resolve to add<br>
<emilio> q+<br>
<fantasai> dbaron: Next is 3 pieces related to animation, super common<br>
<fantasai> dbaron: When Bramus built demos, two features from Transitions L2 and Interop 2024 are well on the path of shipping<br>
<fantasai> dbaron: transition-behavior property<br>
<fantasai> dbaron: Last piece resolved to draft into Values 5, transition to/from `auto` heights<br>
<fantasai> dbaron: was hoping to show a prototype, but not quite done<br>
<fantasai> dbaron: People have wanted this in many contexts for over a decade<br>
<fantasai> dbaron: separate problem that's large, not in Bramus's demos, but important piece of the puzzle<br>
<astearns> ack emilio<br>
<fantasai> emilio: Is ::details-content pseudo-element just the <slot> ?<br>
<Rossen_> q?<br>
<nicole> q+<br>
<fantasai> emilio: alternative would be that the author wraps a bunch of stuff<br>
<fantasai> dbaron: yes, and ability to write generic styles, I think it's better if author doesn't have to write extra markup<br>
<fantasai> emilio: given spec uses shadow DOM, maybe use ::part<br>
<fantasai> dbaron: that's the discussion from Cupertion<br>
<astearns> ack nicole<br>
<fantasai> s/tion/tino/<br>
<fantasai> nicole: Do other engines have a good way to do transitions to/from auto?<br>
<fantasai> dbaron: of the 6 things on the list, that's the proposal in the earliest stage<br>
<fantasai> dbaron: we drafted into the ED last Friday, and prototyping now<br>
<fantasai> dbaron: There are a bunch of things that we need to experiment with as part of prototyping<br>
<oriol> q+<br>
<fantasai> dbaron: Don't want to discourage other implementations trying, but currently just trying to figure things out with the prototype now<br>
<fantasai> iank_: probably doable but slightly more work in other engines, but not 10x factor, maybe 2-3x factor<br>
<fantasai> dbaron: layout side requires some refactoring of existing height calculation code<br>
<fantasai> dbaron: Chromium's engine was recently written, so maybe other engines need more refactoring<br>
<fantasai> nicole: ...<br>
<fantasai> emilio: Everything is doable...<br>
<fantasai> emilio: Whatever people do for disclosure widgets now to transition to/from `auto`, I guess you can do with JS as well<br>
<fantasai> emilio: so open the thing, measure it, then close it and animate to what you measured<br>
<fantasai> nicole: or slide it down so it looks like growing but not<br>
<fantasai> emilio: can do it now with JS<br>
<fantasai> dbaron: make it easier to do<br>
<fantasai> emilio: The first 3 things are not possible even without JS, so those are more important to me in terms of relative priority<br>
<fantasai> nicole: a lot of developers won't use a thing that can't be animated<br>
<fantasai> emilio: but already can animate as well as you can animate other things<br>
<fantasai> dbaron: these things are somewhat separable, they are pieces of the puzzle to make styling these better<br>
<fantasai> dbaron: some more necessary than others<br>
<fantasai> emilio: first 3 things give you the static styling that you want<br>
<fantasai> emilio: 4-5-6 allow declarative animations, but even now could use JS<br>
<fantasai> emilio: 1-2-3 gives you what you can build right now by yourself, but with better a11y and interaction behavior<br>
<fantasai> emilio: 4-5-6 just makes it easier to do animations<br>
<astearns> ack oriol<br>
<fantasai> oriol: Wrt ::details-summary, you thought it wasn't useful, but the <summary> element can be eliminated<br>
<fantasai> oriol: and then automatically generated<br>
<bkardell_> q+<br>
<fantasai> oriol: then might need it?<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<fantasai> dbaron: Yes, but I can't convince myself that omitting <summary> is a good practice that we should design around.<br>
<fantasai> bramus: If you add some padding onto ::details-summary, doesn't work because display: contents<br>
<fantasai> bramus: depending on what you do, have to target ::details-summary or summary<br>
<astearns> ack bkardell_<br>
<fantasai> fantasai: I think I agree with dbaron that this isn't necessary, so if we all agree, let's not go into the details.<br>
<fantasai> bkardell_: The ::details-content pseudo-element, wondering if you could use it to force it open in certain layouts<br>
<fantasai> dbaron: you could<br>
<fantasai> dbaron: need ::details-content { display: block; content-visibility: initial; } but can force it open that way<br>
<bkardell_> 🔥<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<fantasai> bramus: I used 1,3,4,6 for my demos<br>
<fantasai> bramus: wrt disclosure triange, I think authors would want to be able to pick the content that they want for that triangle<br>
<fantasai> emilio: couldn't you use list-style: <image><br>
<fantasai> dbaron: in Gecko/Blink yes; not WebKit<br>
<fantasai> emilio: I think per spec you're supposed to have `display: list-item` so you can style the marker<br>
<fantasai> emilio: webKit has it's own weird pseudo<br>
<fantasai> +1<br>
<fantasai> bramus: I haven't explored that part, I explored can we animate the details when it opens and closes<br>
<fantasai> bramus: wrt basics, I tried changing layout, e.g. using flex/grid<br>
<fantasai> bramus: [shows off some flexbox styles]<br>
<fantasai> bramus: [shows off demo of a rectangle like [ * I am the summary | ... blank ... ] which then grows taller and fills in sevreal paragraphs in the right half<br>
<fantasai> florian: if line-clamp worked, you could make it visible and clamp it<br>
<fantasai> emilio: I think this should be possible to do without fixed height<br>
<fantasai> bramus: Also tried grid, using grid templates<br>
<fantasai> bramus: it was really nice to use<br>
<fantasai> bramus: Then I added animation, and things go tinteresting<br>
<fantasai> bramus: First styling and animating the pseudo element<br>
<fantasai> bramus: gave it some transition of the border between the summary and details, as well as expanding and contracting the content<br>
<fantasai> bramus: might need step-end/step-start<br>
<fantasai> bramus: Then I needed to transition `content-visibility`, needed allow-discrete<br>
<fantasai> bramus: I wanted padding around the content as 1em, but can only add that when the element is open<br>
<fantasai> dbaron: This is the difference between content-visibity and display<br>
<fantasai> emilio: WebKit and Gecko use display to hide the details content, and blink uses content-visibility (which is what the spec says)<br>
<fantasai> emilio: seems to me that we should get interop there relatively soon<br>
<fantasai> fantasai: why content-visiblity?<br>
<fantasai> emilio: so you can search its contents<br>
<dholbert> scribe+<br>
<dholbert> fantasai (IRC): content-visibility naming is not great for this<br>
<dholbert> fantasai (IRC): ideally this would use content-visibility:collapse or something, if that existed<br>
<fantasai> s/visibility/display/<br>
<fantasai> bramus shows the jump when the intervening border gets removed<br>
<fantasai> bramus: Also tried animating with a div instead of the pseudo<br>
<fantasai> bramus: but there was a glitch towards the end<br>
<fantasai> bramus: because content-visibility, I needed to force it to be visible when it's open to change the padding/height<br>
<fantasai> emilio: isn't that just ecause you're using box-sizing: content-box<br>
<fantasai> dbaron: even then, you still can't set it so that the content-box height is smaller than zero<br>
<fantasai> bramus: another approach I styled the div, and animated the pseudo, so the pseudo acts like a curtain over the DIV<br>
<fantasai> bramus: this gives the desired effect<br>
<fantasai> bramus: [shows off UIKit style demo]<br>
<fantasai> bramus: I was able to do this by styling the DIV and animating the pseudo on top of it<br>
<fantasai> bramus: essentially same animation code throughout all the demos<br>
<fantasai> bramus: [shows off horizontal accordion]<br>
<fantasai> bramus: Demo for half-opened disclosure widget for "read more" / "read less"<br>
<fantasai> bramus: To summarize this, setting different display modes on display/summary allows us to build out a lot of use cases<br>
<fantasai> bramus: the ::details-content pseudo is necessary to make the animations, but it's kind weird<br>
<fantasai> bramus: I also found it necessary to add an extra DIV to make it work<br>
<fantasai> bramus: transition-behavior works nicely, and transitions to/from auto would help<br>
<bramus> Links<br>
<bramus> https://goo.gle/styling-details-exploration<br>
<Rossen_> q?<br>
<bramus> https://goo.gle/styling-details-demos<br>
<fantasai> dbaron: If no one on the queue, then I will propose some resolutions!<br>
<fantasai> dbaron: Propose to add ::details-content pseudo-element. No opinion about the name, but seemed reasonable<br>
<emilio> q+<br>
<fantasai> dbaron: In some ways I think pseudo-elements are different from pseudo-classes, because with pseudo-classes there is more value in having things common across multiple features<br>
<fantasai> dbaron: but for pseudo-elements, we will want more specific names for the things we're introducing<br>
<fantasai> dbaron: that's what led to the proposed name<br>
<fantasai> dbaron: it's something specific to <details><br>
<astearns> ack emilio<br>
<fantasai> nicole_: harder to be meaningful if too generic of a name<br>
<fantasai> emilio: can we resolve on pseudo-element vs ::part?<br>
<fantasai> emilio: seems clear that HTML spec is using shadow DOM, and if you use ::part can just do ::part(content) and don't need to be too specific<br>
<fantasai> emilio: less special-casing<br>
<nicole> q+<br>
<fantasai> emilio: idk if we had that discussion<br>
<fantasai> dbaron: we didn't resolve in Cupertino, but seemed Apple was against using ::part<br>
<fantasai> dbaron: my memory was also the HTML spec editors weren't happy either<br>
<fantasai> nicole: Yes, that discussion happened. There was a sense of exposing an implementation detail.<br>
<fantasai> TabAtkins: we already expose that there's a shadow DOM because it has one already from the UA<br>
<fantasai> dbaron: The idea was using ::part() for author-controlled shadow DOM, not for UA stuff<br>
<emilio> chrishtr: html editors said that ::part() is for authors<br>
<TabAtkins> chrishtr: I think the HTML editor's concern was about ::part() being an author namespace that we didn't want to get into<br>
<fantasai> nicole: We would support the proposal of pseudo-elements, but not ::part()<br>
<fantasai> matthieud: we don't want to expose the shadow DOM<br>
<TabAtkins> TabAtkins: But there's no namespace collision issues here. Each individual shadow is its own namespace; the UA controls that shadow, so they control the parts too.<br>
<fantasai> emilio: you're already exposing that information, e.g. you need to override `content-visibility` which is set on the slotp<br>
<fantasai> nicole: It is unusual though. Form controls might use web components, but they don't expose their parts that way<br>
<TabAtkins> TabAtkins: Plus if it's a ::part(), you can export it to your own component. Like `<my-widget><::shadow><details exportparts=content>...`, then `my-widget::part(content)` works<br>
<fantasai> chrishtr: Consistency with the other parts of the platform is also reasonable to have<br>
<fantasai> emilio: My understanding from OpenUI was the idea of exposing components<br>
<TabAtkins> (But with a custom pseudo-element, `my-widget::part(details)::details-content` does not work.)<br>
<fantasai> chrishtr: OpenUI did go in that direction, and WHATWG editors didn't like it<br>
<fantasai> chrishtr: to distinguish pseudo-elements provided by UA vs author<br>
<fantasai> TabAtkins: We need to push back on that idea<br>
<fantasai> astearns: [missed]<br>
<TabAtkins> TabAtkins: If that is an accurate summary of their position, then they were making decisions based on some incorrect assumptions.<br>
<fantasai> emilio: part attribute needs to be set by the engine, because it's a closed shadow tree<br>
<fantasai> emilio: It's not available to authors, but it's defined in HTML spec<br>
<fantasai> dbaron: I didn't try it because the discussion in Cupertino seemed so strongly against<br>
<fantasai> emilio: Can we resolve to add some syntax for it, and bring ::part vs pseudo to the HTML editors/<br>
<fantasai> chrishtr: We need to align on a design pattern, but how do we come to an agremeent?<br>
<astearns> ack nicole<br>
<fantasai> emilio: ::part is superior here in complexity and functionality<br>
<fantasai> emilio: I understand being reluctant on form controls, because those left more undefined<br>
<fantasai> [general confusion how to make decisions]<br>
<TabAtkins> fantasai: I think I agree with Chris that it's nice to be consistent about these sorts of features.<br>
<dbaron> [how to make decisions where WHATWG HTML, CSS, and OpenUI CG disagree]<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: It's clear that form controls won't use ::part(), so I think it makes sense from consistency to provide a ccustom pseudo-element here too, even if you could have expressed it with ::part()<br>
<emilio> q+<br>
<astearns> ack dbaron<br>
<TabAtkins> dbaron: I think the assumption taht form controls won't do it iwth ::part() isn't necessarily true<br>
<fantasai> dbaron: Assumption that form controls don't do that isn't necessarily true, ongoing work in Open UI to build interoperable styleable form controls<br>
<fantasai> dbaron: which might end up exposing ::part<br>
<fantasai> dbaron: most advanced discussions are on <select>, which has evolved a lot in the last 6 months<br>
<astearns> ack emilio<br>
<fantasai> emilio: fact that form controls don't use ::part is because we didn't have ::part when form controls were implemented<br>
<fantasai> emilio: in fact, WebKit implementation itself uses a different attribute to do what part does<br>
<dbaron> s/last 6 months/last 6 months, although maybe in a direction where that one in particular doesn't depend on this decision/<br>
<fantasai> nicole: Fundamentally, how web developers are meant to interact with creating web content, and is there difference in built-in controls vs those created by authors<br>
<fantasai> nicole: Seems clear to me that built-in controls should have simple interface, and not expose things under the shadow surface<br>
<fantasai> emilio: if we do ::part, needs to be in HTML spec, so we should bring it up and get consensus there<br>
<fantasai> chrishtr: So should we say that we defer to WHATWG?<br>
<fantasai> astearns: We need consensus among all the implementers<br>
<fantasai> emilio: We can agree on exposing the slot as either a pseudo or ::part<br>
<fantasai> emilio: I don't get the argument Nicole makes, because you need to be aware of the styling of the shadow DOM in order to style these widgets<br>
<fantasai> astearns: Let's resolve on exposing this as a pseudo or a ::part depending on the WHATWG discussion<br>
<fantasai> emilio: it would be great to have both groups aligned<br>
<fantasai> TabAtkins: I'll open an issue to centralize this discussion<br>
<fantasai> emilio: Especially since this may impact future decisions as well, so we need to be clear why we're doing X rather than Y<br>
<fantasai> PROPOSED: Expose the slot as either a pseudo or a ::part, depending on the WHATWG discussions<br>
<fantasai> chrishtr: Let's make it clear that we'll decide in that group, and invite anyone who wants to participate<br>
<fantasai> florian: Are we deferring or having a joint session?<br>
<fantasai> PROPOSED: Expose the details slot as either a pseudo or a ::part, as decided in a joint meeting with WHATWG<br>
<fantasai> s/slot/contents slot/<br>
<fantasai> RESOLVED: Expose the <details> contents slot as either a pseudo or a ::part, as decided in a joint meeting with WHATWG<br>
<fantasai> dbaron: We would like display of details and summary to be as styleable as possible<br>
<fantasai> Various: Yes, please.<br>
<emilio> q+<br>
<fantasai> chrishtr: As far as you see, there should be no restriction?<br>
<fantasai> dbaron: I don't see any reason for restrictions. We might find Web-compat reasons.<br>
<astearns> ack emilio<br>
<fantasai> dbaron: I don't think any technical reasons other than compat<br>
<fantasai> emilio: Ironically, the reason for this restriction was because not all implementations were not using shadow DOM<br>
<emilio> TabAtkins: yeah, flex would expose the number of child elements of the details and so on<br>
<emilio> PROPOSED: We desire to have no restrictions on the stylability of the display of <details> and <summary><br>
<emilio> RESOLVED: We desire to have no restrictions on the stylability of the display of <details> and <summary><br>
<fantasai> dbaron: A few things to note about the demos, that we might want to solve<br>
<fantasai> dbaron: One thing that was awkward was always needing to add `display: block` to the slot<br>
<fantasai> dbaron: it is possible that we might want to make it the default<br>
<emilio> q+<br>
<fantasai> dbaron: yes, <slot> is display: contents; but maybe for <details> element maybe we make it `display: block`<br>
<astearns> ack emilio<br>
<fantasai> emilio: I think we should decide on this soon<br>
<fantasai> emilio: if you had a flex details, that changes the number of flex items<br>
<fantasai> emilio: so we should go one way or the other before we ship unrestricted display<br>
<fantasai> emilio: would be ironic if it's needed for compat<br>
<fantasai> emilio: I'm not opposed, might be use cases for turning back to `display: contents`<br>
<fantasai> chrishtr: he's not proposing to require, just change the default<br>
<fantasai> bramus: for authors it'll be less surprising<br>
<fantasai> emilio: we need to ship content-visibility details first<br>
<fantasai> dbaron: I think all engines do it in terms of shadow DOM, and <slot> defaults to `display: contents`<br>
<fantasai> emilio: ...<br>
<fantasai> dbaron: I should look into whether this is changeable<br>
<fantasai> dbaron: Another issue was border and padding messing up the animation. I don't have an answer, but it seemed annoying repeatedly<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9879#issuecomment-1942785500 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 23:06:10 UTC