Page MenuHomePhabricator

Add HTML 5 semantic elements 'details' and 'summary' to Sanitizer whitelist
Open, LowestPublic

Assigned To
None
Authored By
Yair_rand
May 23 2011, 7:19 PM
Referenced Files
None
Tokens
"Love" token, awarded by RheingoldRiver."Love" token, awarded by Daimona."Like" token, awarded by ToBeFree."Love" token, awarded by waldyrious.

Description

The HTML5 elements <details> and <summary> (used for making expandable content) are not being allowed by Mediawiki. (This might be only on Wikimedia wikis.)

https://caniuse.com/details

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:28 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz29118.
bzimport added a subscriber: Unknown Object (MLST).

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]...)

Suzukaze-c added a subscriber: brooke.

It is now 2020. Reopening per the second comment by @brion.

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

Kebap rescinded a token.
Kebap subscribed.

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).

@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.