Updated bug summary & fields to clarify this is an enhancement request for supporting HTML 5 draft elements in wiki body text:

http://www.w3.org/TR/html5/interactive-elements.html#the-details-element

http://www.w3.org/TR/html5/interactive-elements.html#the-summary-element

These would presumably be nice ways to implement various sorts of hidable sections, though user-agent support is likely to be lacking or inconsistent at this stage.

I would not recommend adding any explicit support at this stage, but it should be taken a look at some day.

Going to resolve this as LATER; when UA support is more consistent reopen w/ current info. (The things we do use like <video> are easier to detect and define, and don't duplicate behavior we already deal with w/ JavaScript and some standard class names.)

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.