(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 the first draft, feel free to amend it. If certain suggested markup is dubious, we can just remove the suggestion or the markup. All of the markup mentioned here is optional, and can be made into totally different things -- this is up to the developer. This is not a specification.

-- RadomirDopieralski, 2007-01-27

Thanks Radomir for taking the categories I suggested under consideration (you did take them from my page, didn't you?). I think that it would be nice to separate the spec in the same way.

-- EricChartre, 2007-01-30

When preparing this list, I was considering the point of view of a wiki developer who needs to extend Creole with certain feature his community misses -- thus he has to find markup that doesn't conflict with existing Creole rules and that is relatively unlike to conflict with other wikis.

I don't think that we need to also support the "well, I feel like extending Creole today, wonder what new feature I could add" point of view.

Btw, not signing contribution on the main pages will allow others to modify the text.

-- RadomirDopieralski, 2007-02-06

I like this approach for standardizing some of the markup, and for making the block and inline markup consistent. I am working on a plugin strategy for my wiki and need to solve the plugin markup problem. My first cut was to use the remainder of the line after the pre-formatted open marker as a place to set up plugin controls, but this means other wiki engines will confuse this with vanilla plain pre-formatted material. So, I changed to the tripple angle bracket (not double - it gets hard to parse a block with C++ code in it!).

-- RoieBlack 2007-04-13 (Yikes - Friday!)

I would like to state here that the categorization of block markup vs. inline markup and its implications hinder the usability of markup. The basic statement is, that this categorization should not imply the number of characters we use for a certain element. This should be solely decided by the frequency of usage of the element in practice. Less handwriting in practice should be given priority over making markup consistent based on a blurry categorization of block and inline markup. I'll try to explain my point in BlockMarkupNotionCriticism. Please discuss this issue with me there.

-- ChristophSauer, 2007-Jun-03 10:28 (CEST)

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 03-Jun-2007 10:28 by ChristophSauer.