* Brion Vibber brion@pobox.com [Tue, 4 Jan 2011 13:39:28 -0800]:
On Tue, Jan 4, 2011 at 1:27 PM, Dirk Riehle dirk@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