On Sun, Sep 20, 2009 at 10:04 AM, David Gerard <dgerard(a)gmail.com> wrote:
2009/9/20 Robert Rohde <rarohde(a)gmail.com>om>:
However, since this is parser behavior going back
to the dawn of time
(first reported in MW 1.4), I wanted to ask if there are known use
cases where the current behavior is actually the expected behavior?
In other words, are there any use cases in the current code base or
extensions that would necessarily break if the parser were changed to
allow nested tags? I can't think of any right now, but I wouldn't
want to modify an old parser quirk without giving it a good look. For
the record, my particular interest is related to nested refs.
What's the actual use case for nested refs? (Do you have an example
page or two where they're useful and there's no way to do it right
without nesting the refs?)
There is a workaround (of sorts) using #tag which has been recommended
for nesting refs on enwiki for two years [1]. So, nested refs will
exist in the wild in some fashion whether we like them or not. I'd
like to fully support nested refs IF it isn't going to break other
things. If it is likely to be a major mess to change this piece of
the parser, then I wouldn't try.
The most common use case seems to be when someone wants to have a note
on a reference or a reference on a note (where each is broken up into
different sections using ref's group attribute). It is still very
rare to use ref nesting though. Some examples are at [2][3][4].
-Robert Rohde
[1]