https://bugzilla.wikimedia.org/show_bug.cgi?id=31374
--- Comment #20 from MZMcBride <[email protected]> 2011-10-06 02:15:26 UTC --- (In reply to comment #16) > (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? Putting the {{{{{{{{{}}}}}}}}} madness issues aside, the use-case isn't {{#tag:ref|{{#tag:ref}}}}, it's {{#tag:ref|<ref></ref>}} (see comment 0). Accommodating (and encouraging) syntax like this is exactly what got the parser into the shape it's in now. Haphazard hacks get ingrained into the code and then suddenly everyone else is expected to be able to deal with them, rather than implementing a proper solution when the issues are obvious. That was largely my point, but it seems to be rather moot now. A considered decision to change or update ref syntax would be a Good Thing. Implementing "solutions" like this that put a band-aid on the problem and make it more difficult to resolve issues down the line is a Bad Thing. -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
