https://bugzilla.wikimedia.org/show_bug.cgi?id=31374
--- Comment #16 from Brion Vibber <br...@wikimedia.org> 2011-10-05 23:28:47 UTC
---
(In reply to comment #14)
> I strongly urge rejecting any patches that make the current hacks more
> acceptable. From memory:
>
> * Nested refs are currently not supported.
> * People implemented a hack using {{#tag:ref}} to get around this.
> * As expected, a software upgrade has broken this hack.
>
> The solution here is to add proper support for nesting references (bug 16330).
> Further fiddling with the parser to maintain bad hacks should be avoided at
> all
> costs, in my opinion.
In theory you should be able to nest as much as you like using {{#tag}}, eg:
{{#tag:ref|blah blah blah{{#tag:ref|blah2}}}}
and indeed this seems to render fine on 1.17.
The main limitation against nesting tags in the <xmlish> tag form is that our
parser since way back is oversimplified: it takes the shortest match and
doesn't assume ahead of time that the contents would be meaningful wikitext;
kinda like how <textarea> and <script> in HTML aren't allowed to contain
</textarea> or </script>, because they have character data content models so a
nested <textarea> or <script> opener would seem invisible to the HTML parser.
The curly brace syntax however is quite explicitly ok to nest, as the internals
are treated like wikitext and get brace expansion pre-done inside before the
hook gets them.
What seems to be the problem with that? Is there internals crud in Cite itself
that makes nesting situations particularly perilous? Or does it just seem like
a poor practice for Cite/ref in particular because it sounds like an odd usage
pattern?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
