As described in my Wikimania 2015 talk https://wikimania2015.wikimedia.org/wiki/Submissions/Templates_are_dead!_Long_live_templates! (starting at slide 31 https://wikimania2015.wikimedia.org/w/index.php?title=File:Templates_are_dead!_Long_live_templates!.pdf&page=31), the existing template argument syntax offers a number of traps for the unwary (for example, with the characters `=`, `|`, etc). As a result, it is difficult to easily move large blocks of text into templates.

As a result, we often have constructs such as: ``` {{tablestart|class="shiny"}} | Hello || world {{tableend}} ``` which pose a number of issues:

1. There is no mechanism to ensure `{{tablestart}}` and `{{tableend}}` are properly matched. 2. Both `{{tablestart}}` and `{{tableend}}` emit unbalanced HTML, which complicates work on efficiently updating the parser cache after template changes. 3. Due to the tag matching issues, this whole block is uneditable by Visual Editor.

***Hygienic arguments*** provide a new form of template invocation which avoids these issues.

The above example would be written as: ``` {{>Table|class="shiny"}} | Hello || world {{< Table}} ``` and the contents between the template start `{{>...}}` and template end ` {{<...}}` are passed as (WLOG) the first positional argument of the template. Named arguments (like `class` in this example) can be passed using the existing argument syntax as before. The new `Template:Table` can now emit properly balanced HTML, with both `<table>` and `</table>` generated by the same template (instead of by two separate templates). Visual Editor can now edit this block as a single template invocation, invoking itself recursively to edit the template arguments as it does now.

Further, there are no special characters or odd escape rules in the argument when expressed this way. The only "special" construct inside the argument is `{{<...}}` and any of those characters can be replaced by an html entity to allow that character sequence to be included literally if needed. That is, we don't need special `{{!}}`, `{{=}}`, etc escapes.

Another example, from Brion Vibber's talk on citations https://wikimania2015.wikimedia.org/wiki/Submissions/Future_of_structured_documents:_VisualEditor,_Citations_and_Wikidata,_oh_my! : ``` {{>cite|id=“32412”}} First person plural pronouns in Isthmus-Mecayapan Nahuat:

:''nejamēn'' ({{IPA|[nehameːn]}}) "We, but not you" (= me & them) :''tejamēn'' ({{IPA|[tehameːn]}}) "We along with you" (= me & you & them) {{<cite}} ``` Note that it was easy to surround the entire text covered by the citation into the `{{cite}}` template, since I didn't need to worry about the fact that the text included the special character `=`.

***Additional arguments*** (optional extension)

From experience with mustache templates https://mustache.github.io/ which

have a similar construct https://mustache.github.io/mustache.5.html#Sections (well, actually with the spacebars https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md equivalent, which shares a concern that template contents be well-balanced), it seems that a large number of use cases can be satisfied with only one or two "block arguments".

But let's say we want to allow more generality. We could support: ``` {{>Foo|namedArg=bar|anotherNamedArg=bat}} This first block goes in argument "1". {{else}} Now this goes in argument "2". {{else}} Now this goes in argument "3". It's a little more natural if there are only one or two arguments, but we could keep going if we wanted. {{<Foo}} ``` Additional proposals for this syntax welcome, I'm just trying to avoid too many crazy new constructs.

***Keeping things terse*** We might allow `{{<}}` as a shortcut to end the block argument, instead of requiring the author to repeat the name of the template. Some folks will like the brevity, others may prefer the more explicit error messages provided when you spell out the name of the template you intend to close.

**Strict start-of-line constraints** For ease of parsing (and reading) we can enforce the constraint that the ` {{>...}}` and `{{<...}}` tags must be alone on their line, and that the newline following the `{{>...}}` and `{{<...}}` tags is not copied into the output.

We could enforce start-of-line context on the result to avoid the T14974/T2529 hacks and make behavior consistent. (More thought welcome here.)

***Migrating template use*** We might allow configuring details of the parameter name(s) used for the block argument(s) via `TemplateData`, to more easily use the new syntax with existing templates.

Phabricator task for this RFC: https://phabricator.wikimedia.org/T114432 --scott