Besides new ideas for *CSS class markup, this page is dedicated to discussion of new markup enhancements.

• TimeStampMarkup
• CssSupport
• UserMarkup (freely configureable markup)
• *MarkupPluginWriting (is already in our *README.programming, but maybe some examples would be better)

General Notes

We should carefully decide, which markup to choose (yep, there is no default or standard for WikiMarkup). So it is a good idea to check out some of the existing Wiki:WikiEngines to separate good stuff out of existing evil concurrent implementations. And there are a few general rules for WikiMarkup that are very important:

• simplicity
  • markup must be intuitive, easy to remember
  • clear rules, so the parser should not guess what a use actually meant
  • I would say: as easier it is for the parser, as easier it is for users
• compatibility
  • with as much other engines as senseful
  • markup should not interfer with content (that's why I'm against single character markup)

We really do not need the best WikiMarkup on earth, but one that works well for most cases. No featuritis, but extensibility.

paragraph or line oriented

ewiki's rendering kernel (R1.00) currently works very line oriented, and can only be made into paragraph mode by using plugins/markup_paragraph. One current idea is to integrate this into the core, or to fully rewrite the rendering engine.

I think more paragraph oriented would be better but that we shouldn't sacrifice ease of use to get there. -APF

milky It is probably required for Lists only right now, because ordinay text already can be wrapped over multiple lines. This fact now leads to the no-need-for-a-new-rendering-kernel.

Update the RenderingKernelTwo is now in releases and has been for some time.

indendation using spaces

Indendation is a good thing and much more important than the <tt> text thingi. I've already seen many wikiengines allowing spaces to be used for text layout porposes. It is of course rather hard to implement, but it is nevertheless very intuitive and thus a good thing.

As TABs cannot be inserted into textareas in mainstream browsers, we'll need to use spaces.

I would suggest checking out the Wiki:TipForTypingTab. There is even some javascript you can use to make it happen for the text area.

-- Jonnay

milky can add TABs, but he now also finds SPACEs more useful, and guesses using some JS to trick browsers wouldn't work very stable. The PhpWiki solution (adding a <checkbox> "please convert my spaces into tabs") is however far more awful. So let's forget about TABs, because SPACEs are as platform-independent as Java! ;)

Headers

The default behavior for headers in EWiki is importance based, add more headers, get bigger headers. The publishing community tends to use their headers the other way around as shown in htmls H1>H2>H3 convention. MS Word also shows the same paradigm. The argument for the 'publishing' header is primarily that the common case is to insert a sub-sub-sub-sub-sub...-chapter in the middle of an existing page--which you could do by just adding another exclamation point. The exclamation mark syntax comes from our evil concurrent PhpWiki:, but there of course some Wiki:WikiEngines that use a syntax which is more HTML-like and as you described it so its not exactly a *WikiStandard.

Changing behaviour is rather major as it requires retraining users, but markup/update format will give you an action to toggle the header order. Setting $ewiki_config["wm_publishing_headers"]=1 will tell the render kernel to use the 'publishing' order for headers. I use both and find them about equal since in the 'publishing header' Wiki I start with a !!! level header.