I'm so not impressed by the toggle implementation... How nice it could have been.
Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
Should we also put the headings in the <p> from now on?
Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid.
We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations.
Why force the hidden content to be below or above the toggle? We aren't gaining anything with this.
What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown?
How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous!
Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally.
What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
The default styling gives no clue about it being clickable?
The pointer (awkwardly called the cursor) choice is the text selection?????
Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand")
The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css.
Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working.
It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target.
Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.
"I also want my url to reflect the state of the page... It would have been great if the toggle action was implemented as a simple attribute something like toggle='element name'"
Your wishlist (state in attributes, URLs reflecting page state, anything being toggleable via simple attributes) is basically describing an architecture I've been working on called DATAOS (DOM As The Authority On State).
The core idea: instead of JS owning state and syncing to DOM, flip it. State lives in HTML attributes. JS just listens for changes and reacts. Want toggle state in the URL? The DOM attribute is the state, so serializing to URL is trivial.
It won't fix <details> being weirdly designed, but it's a pattern for building the kind of declarative, attribute-driven interactivity you're describing.
> Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing.
> If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
I think the default looks fine. But TFA clearly explains right there that it can be styled. (Specifically, by styling ::before on the summary tag.)
> The default styling gives no clue about it being clickable?
You asked what the arrow is, and then asked about the lack of indication that the summary header is clickable. The arrow is exactly that indication.
> Maybe I'm dense but I also want my url to reflect the state of the page.
If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
An element should be visible or not be visible. There shouldn't be a 3rd state. It is a new idea and it is bad. Try writing a polyfill.
Even if you insist it shouldn't be the only way to use it. There should at least be a <summary for=""> so that the clickable thing can be put wherever one likes.
The goal is to make things convenient for the user not to sacrifice usability for some semantics.
But if it was a summary is not semantically part of the details.
I don't actually care about that, I just want to use it.
A summary should be allowed to have hyperlinks. I passionately hate clickable paragraphs but if you are going to do that at least change the pointer into a hand.
I could put the <summary> under the summary the way almost everyone does but then the name makes no sense.
>I think the default looks fine.
A summary (longer than a few words) starting with an arrow looks weird.
The arrow would be reasonable UI for fold out menus but those are not summaries.
I would want some margin on the left for the <details> of the sub menu.
What I don't want is to also have padding on the parent(!) menu item. Seems like a very confused parent child relationship.
>> Maybe I'm dense but I also want my url to reflect the state of the page.
>If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
Depends, if the thing is infinite scrolling and the user needs to send a permalink it would be nice to update it.
If I have an accordion with say frequently asked questions it would be necessary to link to the items.
It often isn't needed but I can't really picture when it would be annoying.
Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.
Should we also put the headings in the <p> from now on?
Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid.
We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations.
Why force the hidden content to be below or above the toggle? We aren't gaining anything with this.
What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown?
How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous!
Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally.
What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.
The default styling gives no clue about it being clickable?
The pointer (awkwardly called the cursor) choice is the text selection?????
Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand")
The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css.
Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working.
It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target.
Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.