(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

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.

First, it's true that "a star (*) is the most used symbol to bold text online", but it's ALSO used for unordered lists in most wikis. That said, other marks like = mean one thing at the start of a line (see headings) and something else within text, so it's not wholly impossible to do.

It's astonishing to accept that "a slash (/) looks like slanted italics, so it is intuitive", when there is no precedent for this use and the slash is universally and necessarily used for extremely semantically meaningful categorizing in URLs, including every single URL with a slash in it that ever showed up on a TV screen.

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.

Though two single quotes do look a bit like a double quote, both mediawiki and tikiwiki use this convention, and where that is true it's dangerous to defy all that data weight and try to invent a new convention.

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 pages to that page with the alternate titles, or notify the user that pages with those titles already existed.

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).

Using one symbol for all font/style choice is very wise, and it works well enough in mediawiki.

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 05-Feb-2007 17:39 by 142.177.76.130.