Thanks everyone for weighing in - specifically:
Thanks Brion for explaining how template braces are interpreted - that was very helpful.
Thanks Rob for reiterating that at this time I'm not proposing any changes to the way things work now - just trying to get a feel for how things may operate in a world free of BC worries.
It isn't my intent to create a new template-language specification, the wikitext template language is familiar to a lot of people and reasonably succinct. Its use of consecutive curly braces is convenient since these are not used (afaik) in other popular light-markup languages, so there's low risk of a clash.
I'll get started using the principle Brion explained - that the longest pair sticks, with tightest pairs after that. The "spec" that I'm going to use for my templating adventure is as follows:
* Parameter definition: {{{param|default}}} * Template call definition: {{template|arg|named_arg=val}} * Function call definition: {{#function:arg1|arg2|arg3}} * Nesting rule: Longest, tightest pair wins
Regarding the call for a specification - maybe this task might be easier if it were broken into chunks? For example:
* Template and parameter syntax * Bullets and numbering * Tables * Links (internal and external)
I shudder to continue because such a list can get very long very fast (I had to stop myself, for example, from making a level under Links for Images and Categories). But you get the idea. IMO, a partial spec in any of the above areas would be better than none at all (and in several of those cases, a spec may already exist)
One final observation: template calls which are built from the results of other calls are not themselves executed.
Consider: * [[Template:left_braces]] = {{ * [[Template:right_braces]] = }} * [[Some Page]] = {{left braces}}a{{right braces}}
The resulting content on [[Some Page]] will be {{a}}, not the result of calling Template:A. This effect is similar to what makes the {{!}} template work, which makes it possible to supply table definitions inside template arguments.
The decision not to reparse restricts what's possible with template inclusion, but the alternative would appear to be worse. Recursion becomes a nasty problem if you allow the rendered results to be re-rendered, so I'm going to follow MW's lead and not re-parse text following template inclusion.
The reason I bring this up is that it's probably worth mentioning in the Template Spec - when such a document becomes available.
I realize that parts of this discussion may have moved outside the realm of applicability to the list, and I appreciate everyone's input. :)
-- Jim
On 7/3/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Sooner or later, we are going to have to define the parser behaviour once and for all. When that happens, there will, no doubt, be some backwards-incompatible changes in edge cases. This is unavoidable.
Indeed. And the longer we wait, the more there will be.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l