Many wikis have methods of creating expandable content using javascript which could be replaced by details/summary for browsers that support it. What would be the downsides of having those only use the javascript method for browsers that don't support <details> and <summary>?

Note: <details> and <summary> is supported in Google Chrome.

It is now 2018. Is https://caniuse.com/details acceptable user agent support?

(Was thinking about en.wiktionary's frequent use of [show]/[hide]...)

Neat! We should probably confirm the behavior is consistent, predictable, and either falls back cleanly or can be emulated sanely (eg in IE 11 if it doesn't support it). Also double check that neither tag is used as an extension. Then I probably have no further objection. :)

From caniuse it looks like IE and old Edge are the holdouts (new Chromium based edge supports it, as well as reasonably current versions of other browsers)

I'm experimenting with this locally to see if we can replace mw-collapsible, polyfilling for IE11 and retaining the majority of the functionality for divs (while dropping tables and lists).

Change 679967 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] Add HTML5 details and summary to Sanitizer

https://gerrit.wikimedia.org/r/679967

I'm currently attempting to build an infobox using the following syntax:

<details open>
<summary>(short description)</summary>
;Name
:Lorem Ipsum
</details>

Common.css:

details {
    float:right;
}

Adding a border and a (min/max) width, perhaps a background color… The result would be a simple non-template box without inline style specifications and without tables. Bonus: The box would be collapsible without any JavaScript.

That is, if MediaWiki didn't filter out details and summary HTML tags 7 years after a request to fix this was made.

@TheDJ do you know what this task is blocked on? (afaics your patch contains all the code needed to make this happen?)

@Proc It is stuck on lack of reviewers and Parsoid support, as well as a general agreement between devs that this is actually desirable to support long term inside wikitext (what was once given is hard to take back and needs eternal support).

In T31118#8015894, @TheDJ wrote:

@Proc It is stuck on lack of reviewers and Parsoid support, as well as a general agreement between devs that this is actually desirable to support long term inside wikitext (what was once given is hard to take back and needs eternal support).

@TheDJ what's the specific issue with Parsoid support?

There's a long discussion in the parent task, T25932, summarized by "wikitext is not a superset of HTML". If we want to allow markup like:

<details open>
<summary>(short description)</summary>
;Name
:Lorem Ipsum
</details>

then the best way forward (in terms of future maintainability) is not to "just" allow arbitrary use of <details> and <summary> tags in wikitext, but instead to start by adding a new parser function, say {{#details|short description|content}} which will emit the structure that you want. (The 'content' block is a good use of heredoc arguments, T114432.) That is "more semantic" in tat the wikitext author is writing a semantic description of the details box (or whatever), and it allows us the ability to change the exact markup emitted for that parser function in the future. We're not committed to emitting exactly those particular HTML tags in that particular tree structure for all time.

Change 679967 abandoned by TheDJ:

[mediawiki/core@master] Add HTML5 details and summary to Sanitizer

Reason:

https://gerrit.wikimedia.org/r/679967

Parserfunctions are the ugly side of wikitext code and in my opinion very unreadable especially when they have to contain block content. It's the xslt of wikitext.

I'd go with a custom tag, similar to <syntaxhighlight>

+1 on this request, mainly because the existing mw-collapsible function is a lot less accessible than this standard thing.

then the best way forward (in terms of future maintainability)

I do not see why. We already use <div> everywhere for encapsulating block content. This is not making anything worse.

summarized by "wikitext is not a superset of HTML"

As Izno has so elequently expressed, we are not asking wikitext to be a superset of HTML. It's just some parts of HTML makes sense for the content-writing task of Wikitext and we want them in.

In T31118#9042921, @cscott wrote:

There's a long discussion in the parent task, T25932, summarized by "wikitext is not a superset of HTML". If we want to allow markup like:

<details open>
<summary>(short description)</summary>
;Name
:Lorem Ipsum
</details>

then the best way forward (in terms of future maintainability) is not to "just" allow arbitrary use of <details> and <summary> tags in wikitext, but instead to start by adding a new parser function, say {{#details|short description|content}} which will emit the structure that you want. (The 'content' block is a good use of heredoc arguments, T114432.) That is "more semantic" in tat the wikitext author is writing a semantic description of the details box (or whatever), and it allows us the ability to change the exact markup emitted for that parser function in the future. We're not committed to emitting exactly those particular HTML tags in that particular tree structure for all time.

@cscott how would this idea work with CSS? There needs to be a way to emit <details class="xyz1 xyz2">.

For what it's worth, I do a lot of work with templates and userscripts, and the lack of <details> is woeful.

The mw-collapsible classes seem to me strictly worse and less accessible in virtually every way -- they involve running clientside javascript, which many people have disabled, and even if enabled often completely fails to load. Even when they do work, they depend on a unique special-snowflake implementation of collapsible content which only exists on MediaWiki, rather than something consistent with how other websites do this -- I am not an accessibility genius but this seems suboptimal. It's now 2024 -- isn't this basically universally supported? What browsers do we need a fallback for?

Even in the event that we DO need to write fallback support for some weird browser, it seems to me better to use that in cases where these elements aren't supported, and have it work normally everywhere else, than to have 100% of collapsible content depend on a kludgy thing which fails completely for every render that doesn't successfully load and run a bunch of JavaScript.

As Nathan Hale once said^{[citation needed]} Give me semantic HTML or give me:<br/><details><summary>List of alternatives to semantic HTML (click to expand)</summary><ul><li>Death</li></ul></details>

Bump. For all the reasons given by @jpxg. This could even be used for other things, such as wrapping requests to administrators that become too long, thus facilitating reading on small screens.

I created an extension, Details, that implements <details>/<summary> as parser tags. I made it fully compatible with mw-collapse with JS that applies the same classes, same API, and adding the Collapse/Expand button (whether this is all actually desirable, I don’t know, but I figured it eases concerns about switching over), and also added a wikicollapse class that styles it nicely.

It comes with the downside that, because it’s a parser extension, it still just doesn’t act the same as HTML output. Particularly, the prefix/postfix format used by {{Collapse top}} and {{Collapse bottom}} just doesn’t work, because the MW parser just sees the lone opening and closing tags in the templates as syntax errors. I worked around it by adding a part="head"/part="foot" attribute, and you can see it used this way e.g. here. This workaround doesn’t work with Parsoid, though.

I want to revive this conversation given the new browser support matrix for 1.43. I’ve summarised (ha) the compatibility here. All grade A - C browsers MW now targets have full support for JS-free collapsing elements, and with the exception of Safari 10.0 (added in 10.1), the toggle event for any additional JS that needs to fire when the open state changes.

There’s also a “hidden until found” concept that more recently exists in the HTML spec. The browser is able to open a closed <details> if an anchor, find in page, or text highlight result is found inside it. Only implemented by Chrome 97+ currently, which is unfortunate, but I feel this is still a valuable feature. (Maybe its use by Wikimedia can help Mozilla/Apple prioritise implementing it?) It may also be understood by search engines as being indexable content, while mw-collapse contents would not be edit: Both methods seem to work equally on Google, Bing, Yandex, and DuckDuckGo.

I don’t feel MW should do anything special with these tags. No parser functions - just allow it to be emitted to the output HTML. MW doesn’t do anything special with other block elements like <div>, and they’re very well used by templates with the parser’s limitations well understood.

It seems like the default <summary> in <details> is (of course) a shadow-DOM element, and the spec does not expose it via pseudo-elements, so styling it with CSS is not that easy at the moment. Might be quite confusing for skins or third-parties with custom styling, which saddens me given mw-collapsibles are evil.

IMO a <collapsible> tag as an abstraction over <details> with additional requirements would be much more welcome (and would satisfy the superset bit above), but parser tags are a minor annoyance in Lua and as mentioned can't be used in a prefix/postfix template scheme.

(Currently it is proposed and unimplemented, but ::details-content might exist in the future. https://css-tricks.com/almanac/selectors/d/details-content/ )

This would still be awesome.

In T31118#10060337, @Suzukaze-c wrote:

(Currently it is proposed and unimplemented, but ::details-content might exist in the future. https://css-tricks.com/almanac/selectors/d/details-content/ )

They changed the URL of this, for anyone still viewing this ticket and wondering why it's a 404: https://css-tricks.com/almanac/pseudo-selectors/d/details-content/

Edit: Also, ::details-content is seemingly supported by all Chromium-based browsers, but not Safari or Firefox yet.

Edit (29/04/2025): ::details-content is now supported by Safari and all Chromium browsers, Firefox is the only browser to not support it as of now.

Just thought I’d update regarding browser support:

• ::details-content is added in Safari 18.4 (March 2025), and is coming in Firefox 143 (this month, caniuse). Safari has an interesting caveat of “Does not support chaining pseudo-elements after ::details-content.”
• Since my last comment, hidden-until-found was added in Firefox 139 (May 2025), and Safari will have it soon (Tech Preview 225, Aug 2025)

Despite this, I want to argue it’s usable right now. Is there a reason to wait on ::details-content being more widespread? I suppose it’s solved by using a <div> - perhaps not as elegant, but there’s a huge gap between <details>/<summary> support and ::details-content support, so it would be better for graceful degradation. It’s a net positive to have the native support as it stands right now, even on the minimum Grade C browser spec.

As I said in my last comment, I would argue to not complicate it. Templates can be responsible for wrapping the content in <div> and for styling. It makes the most sense for these tags to act like fancy <div>s (because they are!), and polyfills like in my extension can mostly complete the compatibility/usability.

One of the huge advantage of <details> and <summary> is about accessibility, especially screen readers.

In T31118#9042921, @cscott wrote:

There's a long discussion in the parent task, T25932, summarized by "wikitext is not a superset of HTML". If we want to allow markup like:

<details open>
<summary>(short description)</summary>
;Name
:Lorem Ipsum
</details>

then the best way forward (in terms of future maintainability) is not to "just" allow arbitrary use of <details> and <summary> tags in wikitext, but instead to start by adding a new parser function, say {{#details|short description|content}} which will emit the structure that you want. (The 'content' block is a good use of heredoc arguments, T114432.) That is "more semantic" in tat the wikitext author is writing a semantic description of the details box (or whatever), and it allows us the ability to change the exact markup emitted for that parser function in the future. We're not committed to emitting exactly those particular HTML tags in that particular tree structure for all time.

A counter-argument could be the KISS principle.

If the only reason to use a complex {{#details}} syntax is to AVOID the HTML tag to explicitly say "we don't recognize tasks", that introduces a complexity (see unanswered question from Ioaxxere about to write classes) with a dubious cost/advantage balance.

Please be very cautious about adding support here given https://issues.chromium.org/issues/41152783 (which is a WONTFIX but still occasionally happening in Chrome). It could make whole Wikipedia pages inaccessible. Waiting on T333394: Vector 2022 should use details element instead of checkbox hack (IE11) for better accessibility and to fix issues with hover states on language button might be a good example to verify its stability before letting the genie out of the bottle.