(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]

Sign your name under each item with which you agree and write how strongly you feel about this issue, and your reasons. If you want to see the earlier proposal for this poll, please see Creole 0.6 Poll Archive.

List markup character (- or *)#

List markup character should be - #

  • ChuckSmith: avoids conflicts with bold, was more used before wikis for lists
  • Axel Rauschmayer: weakly, I can live with any solution that has been proposed so far. Still: Asterisks look "fat" and unnatural for lists. Single dashes look good and feel natural (admittedly, multiple dashes do not look so good). The solution I'm using in my wiki is whitespace plus '-' (ListMarkupAlternatives) and I found that usability only suffers in extreme cases, while basic cases look really nice (and can be pasted into an email without confusing the recipient).

List markup character should be * #

  • Radomir Dopieralski: asterisks are massively more popular on wikis and are not as confusing when used to form nested lists
  • Gregor Hagedorn: asterisks are massively more popular on wikis and feel natural. And I still do not understand why the problem of leading double-asterisks also being bold can be solved by using list-hyphens, which have the problem of leading double (signature, m-dash) and quadruple hyphen (horizontal rule). I feel the problem largely goes aways by requiring a blank after bullets, and disallowing a blank after opening bold/strong (e.g. TWiki works that way, and it works well). But I am not a programmer.

Space required after character (Y or N)?#

Space required after character#

  • RadomirDopieralski: many users do not use a space after the character and this lack of requirement would make Creole potentially confusing and non-user-friendly by inviting unreadable markup
  • Gregor Hagedorn: strongly Wikis are about ease of use. Blank after bullets is readable, no-blank looks like Perl-code. Introducing two alternative markups, which really look different and which every user must learn (because not only personal preference counts, also other peoples preference counts) makes markup learning curve significantly steeper.

Space NOT required after character#

  • ChuckSmith: strongly, many users do not use a space after the character and this extra requirement would make Creole potentially confusing and non-user-friendly
  • Axel Rauschmayer: weakly, I always use a space and don't see why users shouldn't be guided towards nicer markup. Furthermore, if using dashes, the space is essential for disambiguating with negative numbers.

Escape character desired (Y or N)?#

Escape character desired#

  • ChuckSmith: weakly, this would help considerably in discussions revolving around code issues
  • Gregor Hagedorn: moderately Wikis are about ease of use. Wikis supporting CamelCase will absolutely require a single-character escape. Nowiki markup is quite laborious, when one has to remove all the wrongly-interpreted markup from a page. In my experience, e.g. technical xml-schema discussions running on TWiki easily will have a few dozens on a page that need to be escaped (both CamelCase, and html-enabled, thus all xml/html reserved characters must be escaped or replaced with entity. JSPWiki with CamelCase and html turned off is much better of course.

Escape character NOT desired#

  • RadomirDopieralski: strongly, escape character is a complicated geek solution, InvisibleMarkup, invites ugly markup rules in all the rest of Creole
  • Axel Rauschmayer: strongly, complicates things, Creole should stay simple and nowiki can be used here.

Escape character (or \)?#

Escape character should be ~#

  • ChuckSmith: strongly, does not conflict with line breaks, and is not likely to be in text already

Escape character should be \#

  • RadomirDopieralski: if an escape character is used at all, it should be the traditional one, with the traditional behavior.

Monospace and nowiki#

(Problem with Poll: Where has the pre-block gone to? Gregor)

nowiki is monospace in in-line and block#

nowiki is only monospace in block#

  • ChuckSmith: if you want in-line nowiki, you probably do not want monospace, whereas block nowiki typically depicts something that should be displayed in monospace

nowiki is always (inline + block) monospace, use other construct (double braces?) for inline plain-text nowiki#

  • Axel Rauschmayer: weakly, this would look more consistent. We do need inline plain nowiki, so my 2nd-favorite solution is "nowiki is only monospace in block".
  • Gregor Hagedorn:
    • (a) strongly Call the block nowiki-monospace "pre", because by preserving whitespace it has additional properties.
    • (b) moderately Use same markup (e.g. triple braces) for inline nowiki-monospace (e.g. xhtml:tt). So far like Creole 0.5. This seems more consistent than switching to different formatting here.
    • (c) strongly provide content authors with a solution for dealing with their problems that their content is erroneously considered markup by wiki - I believe there is too much discussion here what programmers think the expected content will look like, what they "probably" want. I believe it won't work, the world is bigger! Do you know what field codes ecologists invent and want to talk about? The important need here will be to allow formatting running through the part erroneously escaped
      • (c1) I prefer an easily memorizable solution, i.e. reserving double-brace for non-formatting no-wiki
      • (c2) I prefer an additional escape character for ease of use, based on my experience with Wikis.
      • (c3) I can live with either an inline non-formatting nowiki, or an escape character (rather than both).

nowiki is never monospace#

Monospace font style desired (Y or N)?#

Monospace font style desired#

  • Axel Rauschmayer: weakly, I used this font style frequently when writing about code, but can live with (ab)using a monospace version of nowiki here.
  • Gregor Hagedorn: weakly - but together with a general solution for advanced formatting options like super/subscript, color, highlighting, etc.

Monospace font style NOT desired#

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 11-Apr-2007 23:12 by Gregor Hagedorn.