Robert Rohde wrote: > I am looking at bug 1310, which involves parser behavior such that > when given nested tag extensions, i.e.: > > <tag> > AAA > <tag>BBB</tag> > CCC > </tag> > > The parser selects the tag block as running from the first open tag to > the FIRST close tag, i.e. in the example it gives: > > AAA > <tag>BBB > > as the inner text of the first tag. It should be fairly > straightforward to modify this to handle nested tags by checking for > additional open tags in the inner string.
This syntax was chosen because originally <pre> and <nowiki> were the only such tags (I called them xmlish elements in [[mw:Preprocessor ABNF]]). Those two tags were imagined as being useful solely for escaping HTML and other wikitext, so that it is displayed literally on the page. No nesting behaviour was desirable. <math>, and then the extension interface, were added afterwards using the same syntax. There is no application for nesting with <math> since the contents are TeX. <ref> was the first tag to assume that its contents were some kind of wikitext, unfortunately this was an inefficient and ugly hack on the software side, and could have been much more easily done, with appropriate nesting behaviour, if a different syntax had been chosen. Other tags were later added, following this bad example. So if you ask me if there's a use case, I would say most likely yes, especially for <nowiki> and <pre>, and very likely for the extensions that shell out, like <math> and <lilypond>. These use cases would become especially obvious if an extension registered a short name name like <->, then the lack of a syntax for communicating this string with a shell command would become especially obvious. But it would be possible to enable or disable nesting on a per-tag basis at registration time. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
