Alternative Text Formatting Rules

(This page once argued for uniformity in the WikiMarkupLanguage conventions. The proposal has since been removed by the original author.)

See WebDav for an alternative.

I once had a similar reaction, but I came to realize that whilst there are minor drawbacks, there is also a major advantage in that readers are gently introduced to wiki ways without even knowing that that is what is happening. -- VickiKerr

One is gently persuaded to read the pages about wiki, a recommended (and beneficial) activity.

Suppose you wanted to build a place like wiki, where what mattered was the content. There needs to be some typography, so that people can make their work readable. But suppose what you cared about was the content. What would be some good ways to make increasingly elegant typography less and less valuable, keeping the focus on substance, not form?

It is worth noting that previously on this page there are precisely (if I count right) three pieces of formatting.

There is a bold phrase in one entry.
There is a bar line between comments.
And a number of double single quote thingies that produce the effect? (sorry I forget, that gets italics)

The wiki way seems to be working as suggested and is minimising focus on form and promoting content. Yes I would like a simpler formatting system, but no, I might lose focus on the point if pretty was too cheap.

The idea of WikiMarkup seems partly to make it more "intuitive", partly to make the plain text look suggestive of the intended HTML, partly to be safe, and partly to be less "noisy" (note - these intents are partly overlapping!)

How about using "/" to surround italics, "*" to surround bold, "_" to surround underline, and using hanging indents to resolve levels of lists. Let's also not use tabs. Or use []'s to surround WikiNames to save pressing shift all the time.

There are problems with using "/" as a markup because it is a common character used in file paths (*nix) and URLs. Perhaps six slashes could be used to get around that *grin*. Seriously, why not use the "\" to tell wiki to leave the next character as-is?

Well, of course, it's all moot, since, as is commented above, the existing system works and causes very little (although constant) irritation.

What about using something people are used to in email and other prose?

I would like to see Wiki use *asterisks* around a word for bold and _underscore_ for italics as this is common, easy to adapt to and does not get in the way of the creative process. Admittedly, it would lead to requiring something new for lists - perhaps # or = at start of column 1 - or better yet how about leaving it to context (no *bold* at start of a sentence?) -- MarcelCunnington?

I would also like to see something like this, although there is a problem that there isn't really an accepted standard for formatting. However, something like:

*bold*
_underline_
/italics/

: This is exactly the formatting used in GikiWiki (and probably others). * and # at the beginning of a line are used for bulleted and enumerated lists, and *bold*, /italic/, and _underline_ all do what you'd expect. I tried to use email conventions whenever possible, so indented paragraphs are offset by spaces, and preformatted text uses {{{ and }}}. I've these FormattingRules? are very easy for newbies to learn and remember. -- NealePickett

Most of the time you just want to make one word bold or italic; in these cases you shouldn't be required to "close" the bold or italic tag. example: *thisshouldbebold

Any paragraph that is completely enclosed in quotes could be automatically turned into a blockquote. A single line with an equal number of dashes under it could be turned into a title. Named links could be written as the link text followed by the URL in brackets, which I think would be perfectly natural to type if writing in PlainText, eg: textweb (http://www.tulrich.com/geekstuff/textweb.html) would become a named link.

Other formatting rules could no doubt be worked out for other things (although admittedly a formatting rule for tables would be difficult).

But the aim for all of these rules is to end up with a markup which is just as obvious and readable as PlainText as it is when converted to HTML by the WikiEngine.

(Moved from WikiMarkupLanguage)

Here is my pet variation of WikiMarkupLanguage:

Italics: {...} (I don't like the quote approach, too hard to see)
Bold: {{...}}
Literal: $ at begginging of each literal line (as opposed to indent to avoid white-space problems)
Blockquote: ":" at begining of line
Half separator: ---- (Such as <HR WIDTH="50%">)
Full separator: ====
Wiki link: [...] (To allow spaces in wiki-name, double to escape to single)
HTTP link: [http://....]
Colon at start to indicate indent.

Those not mentioned, such as asterisks, are assumed the same as C2 conventions.

Here's another variation that I find potentially more intuitive due to the shape of the wrapping characters. It's semi-WysiWyg. Squiggly somewhat visually matches italics and right angles represent underline (line):

{{italics}}
[[underline]]
((bold))
[wiki-link] - However, this occurs too often in regular text.

-- top

Italics are squiggly??? Italics lean. Wouldn't something like //italics// be more appropriate?

They have extra "flair". But I suppose WysiWyg may also depend on personal WetWare. "//" is an interesting suggestion, however Windows and HTTP paths may accidentally trigger it.

CategoryWikiEditing