* Brion Vibber <brion(a)pobox.com> [Tue, 4 Jan 2011 13:39:28 -0800]:
On Tue, Jan 4, 2011 at 1:27 PM, Dirk Riehle
<dirk(a)riehle.org> wrote:
Wikis started out as *very* lightly formatted plaintext. The point was
to be
fast and easy -- in the context of web browsers which only offered
plaintext
editing, lightweight markup for bold/italics and a standard convention
for
link naming was about as close as you could get to WYSIWYG / WYSIYM.
It is still faster to type link address in square brackets than clicking
"add link" icon then typing the link name or selecting it from a
drop-down list. Even '' is a bit faster than Ctrl+I (italics via the
mouse will be even slower than that).
As browsers have modernised and now offer pretty
decent rich-text
editing in
native HTML, web apps can actually make use of that to provide
formatting &
embedding of images and other structural elements. In this context,
why
should we spend more than 10 seconds thinking about
how to devise a
syntax
for links or tables? We already have a perfectly good language for
this
stuff, which is machine-parseable: HTML. (Serialize it
as XML to make
it
even more machine-friendly!)
If the web browsers of 1995 had had native HTML editing, I rather
suspect
there would never have been series-of-single-quotes to represent
italics
and
bold...
Native HTML usually is a horrible bloat of tags, their attributes and
css styles. Not really a well-readable and easily processable thing.
Even XML, processed via XSLT would be much more compact and better
readable. HTML is poor at separating of semantics and presentation. HTML
also invites page editor to abuse all of these features, while wikitext
encourages the editor to concentrate the efforts on the quality of
content.
Let's hope that wikitext won't be completely abandoned in MediaWiki 2.0.
Dmitriy