On 5/22/06, Brion Vibber <brion(a)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:
http://www.mediawiki.org/wiki/Markup_spec
What's required before that starts? Can people just start hacking on
it, wiki style?
Steve