On 8/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Some are, some aren't. Note "beyond what actually needs to be parsed beyond sanitization". Internal links must be parsed beyond sanitization, e.g., to generate what-links-here. Since they're so common, it might make sense to keep them separate from the HTML that they generate. That would be a specific decision that would have to be made. But the following can certainly all be dispensed with in favor of XHTML:
<snip> Sounds sensible.
The above list consists exclusively of things that have a one-to-one mapping with HTML tags.
We should examine this proposal in more detail, it's kind of interesting...
The problem is the complexity of the wikimarkup. Look at http://www.mediawiki.org/wiki/Markup_spec for how many rules are needed on top of the SGML parsing that we need anyway. A Javascript app that could parse all that in real time without noticeable lag would probably be very difficult to impossible to write. And it's also led pretty directly to the slowness and complexity of our current parser, too. It's all unnecessary: the markup doesn't need to be easily human-readable if we have WYSIWYG.
I think what I was proposing would not necessarily require a javascript parser. I think? Instead, it would work something like this:
1. Engine simultaneously presents rendered output and wikitext, with synchronisation points between them 2. User edits some rendered output, transforming it purely at the appearance level 3. Page sends rendered text back, engine compares it somehow with what it sent, and works out the wikitext transformations required.
Or something.
Steve