(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 a proposal by ChristophSauer and ChuckSmith:

During the WikiSym workshop, after we decided that a double asterisk would be best for bold, the group decided "unanimous minus two" that the hyphen would be best for bullet lists. However, at this point, ChuckSmith realized due to his research of wiki syntaxes that approximately 90% of wiki engines use asterisks for bullet lists. After the initial desigh Creole 0.1 with hyphens we decided mainly because of that to use asterisk for unnumbered lists as well, see the Talk.Lists for the story. We now have to concede that we made a mistake and accept the use of asterisk instead of hyphens for bullet lists.

It has become obvious by the RequireSpaceAfterBulletProposal that the intuition of the group at the WikiSym workshop was right, that using asterisk for both bold and unnumbered lists would create difficulties in implementing parsers, especially parsers that are based on regular expressions (see CommonWikiParsingTechniques). You will find code examples that show those problems in the BoldAndListsAmbiguity page.

Considering the facts behind 25% of list items on Wikipedia not using space after the star and 25% of lists have items starting with italics or bold[1], this combination is not an EdgeCase. This means that proposals like RequireSpaceAfterBulletProposal would make it more difficult to use Creole than necessary. Proposals like this are a sign that something in the design is wrong and accepting this proposal would only cure a symptom. That's why we ask the comunity to accept this new proposal to switch back to the original design on using hyphens for unnumbered lists.

- item 1
- item 2
-- **item 2.1**
--item 2.2
- item 3

Note that we do not require a space after the hyphens.

Disadvantages#

  • not as frequently used as asterisk in existing wiki markup variants
  • ambiguities with other use of hypens as first characters in a line:
    • horizontal lines
    • common use of two dashes for signatures.
    • common use of double-hyphen to indicate m-dash in text, although this is not really a disadvantage because m-dashes are never used at the beginning of a line of text. (there's a distinction between hyphens and dashes)

Advantages#

  • no BoldAndListsAmbiguity, therefore easier to implement
  • usually the first guess of endusers, (look into your mailbox for the usage of lists, see Line Break Case Studies)
  • looks better (why have we put so much thought into avoiding '''' when we now introduce a similar root of confusion * ** )
  • hyphens are easy to type (usually easier than asterisk)
  • hardly any collisions with existing markup
  • not new (see PukiWiki, SnipSnap, XWiki)

Ambiguities Resolution#

In the following section we will show solutions for the abiguities already discussed on the Talk.Lists page involved with hyphens. Opposed to the bold as the first formatting in a list item, we consider these combinations as root for ambiguities as EdgeCases.

Horizontal Lines and Signatures#

In general a unnumbered list alway has to start with one hyphen. Horizontal rules are on a line by themselves. One could check for four ore more hyphens with nothing else behind it (only space and line break).

----

The same is true for signatures.

-- HomerSimpson, 21-Feb-2007

Please use the ListsAndHorizontalLinesSingaturesAmbiguity page to discuss the issues and solutions.

Using Minus as first Char in Lines#

This is an EdgeCase. For those cases we should introduce a general escape Character other than space , because we want to allow spaces in front of lists.

   5
- 10
====
- 5

This example shows that using a character like a hyphen as a first char has actually the same problem as using a equal sign as the first character. While we do not loose a word about the headings so far there has been concerns about minus as a first character (see Talk.Lists). Both have to be handled anyway. Therefore we would like to suggest general escape character other than space, see EscapeCharacterProposal.

   5
~- 10
~====
~- 5

If we would use space as a escape character we would not be able to allow space in front of lists for example anymore.

Remaining Problems Identified in Discussions#

Real users are breaking the line hard.#

A hard line break is a line break that is saved explicitly in the text by putting in a linebreak character, that is not visible to human readers, but will be used by parsers. A human user inserts this invisible character when he hits return.

The ListMarkupLinebreakArgument shows that there remains the issue that users might do hard linebreaks before hyphens. This is not a problem special to list markup with hypens, this also affects all other markup characters that indicate special meaning at the beginning of a line.

 **START** I think these are realistic examples 
- either using simple hyphens as here - or the 
-- much nicer -- n/m-dash way of writing.
And the minus sign (like
-1) even must be placed there. Finally, whereas 
in English only trailing hyphen-constructs like 
sub- and superclass are common, in German also 
leading hyphen-constructs occur, e.g. subclass and
-property. **END**

Here's an example text, using equal signs (headings) and number signs (numbered list).

 **START** I think these are also realistic 
examples using #1 equals signs, or #2 number
signs in normal text. Where #2 might be frequent,
#1 not as frequent. Also someone could use 
equals signs in texts. Since we allow one 
= equal sign to be a valid header. Therefore 
this also causes trouble. So someone could use
an example in an exercise where he uses
-2 as some value and tells someone should multiply
it with a value so that the end result 
=4. Someone also migt use stars as regular 
footnote markers, etc.. **END**

It is true, that the first example in with hyphens is more frequent as the second example.

Mystic Software breaking the line hard.#

It was stated above that that users might do hard line breaks. In the ListMarkupLinebreakArgument it was assumed that there is software that also inserts hard line breaks:

Note that the line-breaking may come from line- wrapping software, so it is not a question where you would put the dash.

If you turn on line wrap in an editor, the editor will visually wrap the line. You will find this behavior in almost all editors. Those editors however do NOT insert hard line breaks, that could be confused by parsers so that they make the errors above -- they only do it visually. So far no one has brought up examples of such an editor, or editor option, that inserts hard line breaks into text. Therefore this is considered as an irrelevant argument unless someone provides an example of an editor that is relevant in practice.

Gregor: This is getting polemic. The mystic software might be a simple Internet Explorer, see http://de.selfhtml.org/html/formulare/eingabe.htm#bereiche_umbruch. Of course this is under control of Wiki software, so it could be changed. More relevant is my experience in TWiki discussion (TWiki does not insert hard breaks), where a lot of participants responded by hard-wrapped paragraphs. I don't know whether there is a browser setting overriding, or whether they simply copy-pasted into their editor forth and back. The only editor I use is my email program, which supports reformatting text to a given width.

Implications#

A user that breaks the line hard (hitting return) has to be aware that he should not use markup charachters as first charachters in the next line, that have meaning as a first character in a line (no matter if this proposal will be accepted or not).
  • Equal Signs (Headings)
  • Number Signs (Numbered Lists)
  • Hyphens (Unnumbered Lists, if this proposal is accepted)
  • ..

[#1] For reference, RadomirDopieralski wrote the following on Talk.Require Space After Bullet Proposal on 2007-02-09: BulletListOnWikipediaResearch

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 19-Apr-2007 21:57 by GregorHagedorn.