Page MenuHomePhabricator

Implement <section> natively in Parsoid, possibly as plain HTML5 content
Closed, DeclinedPublic


<section> extensions get parsed as plain text on which then causes them to be wrapped in nowiki-tags on save if any paragraph with this tag is edited.

Bug report: /mnt/bugs/2013-05-01T14:00:52.600Z-Echo_(Notifications)%2Fstatus

Version: unspecified
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:27 AM
bzimport added a project: Parsoid.
bzimport set Reference to bz47936.

<section> is an HTML5 element, so is currently not considered as a potential extension tag in the tokenizer. We can easily consider it as an extension tag (similar to <source>), but then its content will only be editable as wikitext unless we implement custom rendering for this extension tag that exposes its content as editable HTML. Since sections are large parts of the page, I'd suggest to only treat this as an extension once we have specialized editing support for its content.

[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]

  • Bug 52252 has been marked as a duplicate of this bug. ***

The problem with treating it as native HTML <section> element is that it doesn't really use HTML-like syntax.

As noted at, the syntax uses what looks like self-closing tags, with the real content in between:

<section begin=chapter1 />this is a chapter<section end=chapter1 />

This is not how an HTML5 section tag (, or really any HTML tag, works.

See also my comment (based on a real example) and link at bug 52252.

It could still probably be mapped to a real section tag, similar to how other wikitext syntax is (e.g. == Heading == is more or less mapped to <h2>Heading</h2>).

(In reply to comment #5)

It could still probably be mapped to a real section tag, similar to how other
wikitext syntax is (e.g. == Heading == is more or less mapped to

It should not be hard to perform this mapping in Parsoid while converting from wikitext to HTML. We will also need to map custom extension attributes to valid HTML attributes.

Arlolra set Security to None.

There are already various issues with HTML constructs which mirror native wiki constructs, like <hX> and <li>: they don't mix well -- <h2> doesn't show up in the ToC like a native wikitext heading would, <li> items don't get integrated into native wikitext lists, etc. So I'm not sure I'm a fan of adding yet another HTML mirror for a native wikitext construct. If we were to do this, we'd want to *very* carefully think through how the embedded HTML tags interact with the native wikitext section wrapping, which is already quite complicated.

So I'd vote WONT FIX for this -- I think it's more trouble than it's worth, and doesn't have a compelling use case at this time.