(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-12) was last changed on 16-Jul-2007 23:40 by 24.84.42.88  

This page was created on 05-Feb-2007 17:20 by 142.177.76.130

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed one line
This is very bad reasoning that misses all the important points about the problem and seems to assume that all the problems that will ever exist in wiki markup or extensions to it are known now. It's nabbing symbols left and right to overload for trivial purposes when there are dead serious purposes like use in URLs that a user has to learn in order to use the net at all. It's defying perfectly good conventions that there's no reason at all to defy, and which can be combined in very useful ways.
There's a strong argument to [[MakeTheMachineWorkHarder]] and avoid specifying the exact type of emphasis used, falling back to specifying things like "this is a quote", and "this is an alternate title" rather than "this is bold" or italic.
At line 3 added 4 lines
In most well-run wikis, typefaces have clear meaning. In Wikipedia articles for instance you can expect meta or editors notes in italics, alternate titles in bold, and so on. When converting these it would be better to figure out their semantics.
Even if that's not possible, [[BoldAndItalicsReasoning]] doesn't hold up - it misses all the important points about the problem and seems to assume that all the problems that will ever exist in wiki markup or extensions to it are known now. It's nabbing symbols left and right to overload for trivial purposes when there are dead serious purposes like use in URLs that a user has to learn in order to use the net at all. It's defying perfectly good conventions that there's no reason at all to defy, and which can be combined in very useful ways.
At line 7 changed one line
It's unwise in the extreme to overload a character that is already widely used for a wholly different reason at an entirely different semantic level. At least overloading stars to mean "bold" and "list item" was arguably both syntatic. A bad convention like use of slash for italics would prevent its use in extensions of Creole that wanted to add say semantic links or embedded content or whatever. Such usage would extend the user's existing understanding of a slash, which is, to refer to a more specialized version or included item. ''See also [[colon]].''
It's unwise in the extreme to overload a character that is already widely used for a wholly different reason at an entirely different semantic level. At least overloading stars to mean "bold" and "list item" was arguably both syntatic. A bad convention like use of slash for italics would prevent its use in extensions of Creole that wanted to add say semantic links or embedded content or whatever. Such usage would extend the user's existing understanding of a slash, which is, to refer to a more specialized version or included item in a hierarchy. They would realize that they shouldn't try to use slashes unless they knew that hierarchy, exactly as they know for URLs. Above all, they wouldn't get confused about the "//" that ALREADY EXISTS AT THE FRONT OF ALL URLS where it separates the [[protocol]] from the [[domain]]. ''See also [[colon]].''
At line 11 changed one line
The mediawiki use of single quotes for emphasis, so that '''bold''', ''italic'' and '''''bold italic''''' all use the same symbol, is perfectly acceptable. The tikiwiki convention of __bold__ is better for alternate titles, since there are reasons to bold things sometimes that are not alternate titles. Therefore use of the __title__ convention could imply some reasonable default behaviour like to automatically create [[redirect page]]s to that page with the alternate titles, or notify the user that pages with those titles already existed.
The mediawiki use of single quotes for emphasis, so that '''bold''', ''italic'' and '''''bold italic''''' all use the same symbol, is perfectly acceptable. The tikiwiki convention of __bold__ remains useful for alternate titles even if the mediawiki usage is retained, since there are reasons to bold things sometimes that are not alternate titles. Therefore use of the __title__ convention could imply some reasonable default behaviour like to automatically create [[redirect page]]s to that page with the alternate titles, or notify the user that pages with those titles already existed.
At line 13 changed one line
The logic that "the underscore (_) was not chosen, because that could be confused for underlining" is absurd, since links normally appear underlined, and the title is exactly the text that does normally appear underlined in a link to that page.
The logic that "the underscore (_) was not chosen, because that could be confused for underlining" is absurd, since links normally appear underlined, and the title is exactly the text that does normally appear underlined in a link to that page. This proposal does not even dealing with [[underline]]. If it did, it would have to deal also with the fact that an {{{ ___alternate title__ }}} could and should be both bolded (to signal it as a title) and underlined or linked (usually also therefore underlined) to the redirect directive itself (so it can be changed or its talk page accessed).
At line 15 changed one line
Using one symbol for all font/style choice is very wise, and it works well enough in mediawiki.
Using one symbol (the [[single quote]]) for the font/style choice works well enough in mediawiki and it avoids overloading symbols. There's no reason not to support the mediawiki and tikiwiki syntax in parallel for those who object very strongly to the use of [[slash]] and [[star]] to specify types of emphasis, and don't want this damage in their data.
----
I have not time to write a rhetorical argument in support of the above. The previous one makes it clear (as do the discussions on Meatball and elsewhere) that / is a poor choice for italics. I won't support it in the parser I am currently working on.
Forgot to mention: irc://freenode.net/socialtext and irc://freenode.net/mediawiki present a not-atypical "collision". ({{{irc://freenode.net/socialtext and irc://freenode.net/mediawiki}}})
----
Re: slash precedence -- I've seen it since 1995 (when I got online) on the web, on usenet, on irc, and in personal communications. In plain text it reminds one of italics, and as those are commonly used for emphasis, it's appropriate syntactually. Semantically, it is also used for article titles and similar.
----
Though it breaks the doubled-operator convention, why not {{{*emphasis (aka italics)*}}} and {{{**strong emphasis (aka bold)**}}}?
----
Well, I've been online since 1985 and I've never seen it in use for the above. <shrug> But did you notice the use of {{{//}}} causes a collision //within// the Creole 1.0 specification for linking urls? http://www.wikicreole.org/wiki/BoldAndItalicsReasoning states the double slash does not collide with any wiki, yet it collides with the use of free url links. In short, it collides with *every* wiki.
Version Date Modified Size Author Changes ... Change note
12 16-Jul-2007 23:40 5.63 kB 24.84.42.88 to previous
11 16-Jul-2007 23:39 5.59 kB 24.84.42.88 to previous | to last
10 16-Jul-2007 06:33 5.216 kB 68.13.197.86 to previous | to last
9 16-Jul-2007 05:58 5.074 kB 68.13.197.86 to previous | to last
8 15-Jul-2007 01:31 4.753 kB 24.84.42.88 to previous | to last
7 15-Jul-2007 01:30 4.682 kB 24.84.42.88 to previous | to last graphic example
6 15-Jul-2007 01:18 4.561 kB 24.84.42.88 to previous | to last Two bits.
5 05-Feb-2007 19:57 4.301 kB 142.177.76.130 to previous | to last noting possibility of making the machine work harder
4 05-Feb-2007 17:39 3.499 kB 142.177.76.130 to previous | to last slashes denote hierarchy and specialization in URLs, thus everywhere
3 05-Feb-2007 17:35 3.205 kB 142.177.76.130 to previous | to last deal with underline and alternate titles before setting this in stone
2 05-Feb-2007 17:32 2.811 kB 142.177.76.130 to previous | to last slash is like colon... not like quotes...
1 05-Feb-2007 17:20 2.648 kB 142.177.76.130 to last utter nonsense; __title__ '''bold''' ''italic'' work perfectly and combine well
« This page (revision-12) was last changed on 16-Jul-2007 23:40 by 24.84.42.88