On 03/05/11 04:25, Brion Vibber wrote: > The most fundamental problem with Wikia's editor remains its fallback > behavior when some structure is unsupported: > > "Source mode required > > Rich text editing has been disabled because the page contains complex > code."
I don't think that's a fundamental problem, I think it's a quick hack added to reduce the development time devoted to rare wikitext constructs, while maintaining round-trip safety. Like you said further down in your post, it can be handled more elegantly by replacing the complex code with a placeholder. Why not just do that? CKEditor makes adding such placeholders really easy. The RTE source has a long list of such client-side modules, added to support various Wikia extensions. > Here's an example of unsupported code, the presence of which makes a page > permanently uneditable by the rich editor until it's removed: > > <table> > <tr><td>a</td></tr> > </table> > > You can try this out now at http://communitytest.wikia.com/ Works for me. http://communitytest.wikia.com/wiki/Brion%27s_table > Beyond that let's flip the question the other way -- what do we *want* out > of WYSIWYG editing, and can that tool provide it or what else do we need? > I've written up some notes a few weeks ago, which need some more collation & > updating from the preliminary experiments I'm doing, and I would strongly > appreciate more feedback from you Tim and from everyone else who's been > poking about in parser & editing land: > > http://www.mediawiki.org/wiki/Wikitext.next Some people in this thread have expressed concerns about the tiny breakages in wikitext backwards compatibility introduced by RTE, despite the fact that RTE has aimed for, and largely achieved, precise backwards compatibility with legacy wikitext. I find it hard to believe that those people would be comfortable with a project which has as its goal a broad reform of wikitext syntax. Perhaps there are good arguments for wikitext syntax reform, but I have trouble believing that WYSIWYG support is one of them, since the problem appears to have been solved already by RTE, without any reform. > Another goal beyond editing itself is normalizing the world of 'alternate > parsers'. There've been several announced recently, and we've got such a > large array now of them available, all a little different. We even use mwlib > ourselves in the PDF/ODF export deployment, and while we don't maintain that > engine we need to coordinate a little with the people who do so that new > extensions and structures get handled. I know that there is a camp of data reusers who like to write their own parsers. I think there are more people who have written a wikitext parser from scratch than have contributed even a small change to the MediaWiki core parser. They have a lot of influence, because they go to conferences and ask for things face-to-face. Now that we have HipHop support, we have the ability to turn MediaWiki's core parser into a fast, reusable library. The performance reasons for limiting the amount of abstraction in the core parser will disappear. How many wikitext parsers does the world really need? -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
