On 5/22/06, Brion Vibber brion@pobox.com wrote:
Fancy colors aren't something we'd want to make _easy_ because they're not something we generally encourage in clean text. But they'd be _possible_ because they're possible in our markup.
Agree, and agree with not making them part of any WYSIWYG package, precisely to avoid making them more accessible than necessary.
In practice, public-ready implementation will have to hold off until the markup is defined well enough that we have reversible transformations and can 'hold out' fancy stuff like images, templates, extensions, and parser functions cleanly into WYSIWYM-friendly chunks.
Can you elaborate on what WYSIWYM means in this context? What's the distinction? Our [[WYSIWYM]] article is not helpful.
Also, why the dependency on a well-defined markup? To avoid implementing a moving target?
We will likely not have "true" WYSIWYG in the sense of it the editing view being exactly 100% one and the same as the reading view, because things like embedded data, plugins, templates etc really require some separation.
That's fine. At some stage, fine tuning will always require hand tweaking. But just basic editing, refactoring, reformatting etc would be great. Even something that displays {{templates}} and [[Category:Links]] like that would be fine, IMHO.
There'd be a slight question over how to display <nowiki> code, I suppose. True WYSIWYG would display <nowiki>[[link]]</nowiki> as simply: [[link]], but that would be conflict with my suggestion above, and would be ambiguous for the reverse transformation (<nowiki>[[</nowiki>link]] would be mapped onto the same).
I guess you already know about all these issues :)
I'd like to get a working group together to start making the specification happen soon:
What's required before that starts? Can people just start hacking on it, wiki style?
Steve