Preview is valuable because it produces *exactly* the
output that the
wiki does. A JavaScript work-alike parser is unlikely to work exactly
the same even in the best case, and isn't going to provide for
extensions at all without invoking the PHP parser on the server.
I never intended this to be a replacement for the current preview as
it simply is impossible to provide a feature-complete preview without
invoking server-side processing. On the contrary, this is just an
extension for people who understands the limitations of using such an
alternative. For those people I believe this could prove to be very
useful.
Having two parallel parsers is also a bad practice,
introducing extra
work in maintaining them both and keeping them in sync. Someday we may
have a real working 'alternate' parser, but if so it's going to have to
prove itself worth the effort of maintaining it; as it is we have enough
trouble with sloppily-written pages not working when copied to another
wiki that's not running with tidy to clean up HTML kinks, and that's
just a post-processing phase rather than the parser itself.
Now, I don't even pretend this to become integrated with the current
software, I don't even see the need for it as long as there are ways
of customizing one's wiki (namely with monobook.js). Of course not
everyone would understand the difference between server-side and
client-side previews, so having this enabled by default would be a big
mistake.
So, in other words, I want this to be some sort of plug-in which
particular users could install for themselves _if_ they want to. I'm
sure there's nothing wrong with that. What's more, I think MediaWiki
could do with some more ways of customizing user interfaces.
There's some experimental code in 1.5 for fetching
previews via an
XmlHTTPRequest, which avoids the skin rendering overhead (and in many
cases should avoid message cache initialization overhead) required for a
full HTML page submission while letting the PHP parser return real
rendering results. Most of the time spent in rendering non-trivial pages
is concentrated in a few hotspots (particularly title normalization,
link checking, and link generation) and IMO optimization effort would be
better spent on these.
Sounds really interesting. I'm really for that kind of a approaches.
Look at GMail for instance, I think it's amazing. MediaWiki could take
great advatange from that kind of techniques.
This is not to say that a JavaScript wikitext parser
is useless; but I
don't think we would be able to use it for things like previews.
Hm... since I can't fully agree here I can only hope I stated my view
clearly. In the meanwhile I will continue to enhance and extend the
script to support as many features as possible.
Regards,
-Pedro