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
--
(
http://cscott.net)