Revision [7208]

This is an old revision of WikkaExtensibleMarkup made by MonstoBrukes on 2005-04-12 02:33:57.

 

Extensible markup for Wikka formatter



The problem


I report here the main lines of an interesting discussion I had some weeks ago with JavaWoman and NilsLindenberg on TheLounge #wikka on the appropriate markup for a general-purpose Wikka formatter.

Extending the number of FormattingRules formatting rules to include WantedFormatters new formatters looks like a necessary step for future development. Yet, the number of available combinations of symbols that might be good candidates for future formatters is very limited. The requirement that should be met by a specific formatter are the following:


The consistency point is extremely important and I think that clarifying the state of the art might help find an appropriate solution.

The state of the art

So far we have three distinct types markup schemes used by the formatters (x is a placeholder for other symbols).

A. tag-like markup

xx text xx (generally used for formatting text)

B. Class-driven markup

xx(value) text xx (generally used for formatting code blocks)

C. Pseudo-markup

{{xxxx par="text"}}


A proposal


Given the existing conventions adopted so far in Wikka and the list of constraints about what makes markup good markup, not many options are available. Here's my proposal for an extensible syntax that draws on both A. and B.

General-purpose tag-like markup:

::x text x::

This is the syntax I propose for tag-like markup:

General-purpose class-driven markup:

::(class) text ::
:::(class) text :::

This syntax is consistent with the existing code formatters and could be used to format other customizable CSS-driven content.
The main difference with tag-like markup is that

Notice that I propose two distinct class-driven markup models, the first resulting into <span> markup, the second into <div> markup.
The choice of using :: for span's is meant to suggest that this markup produces a result similar to tag-like markup, i.e. it results in formatted text, while ::: results in blocks that can be repositioned, added a border etc.

Generally speaking, I think the above solutions complement each other pretty well, are compatible with the constraints on good markup and - last but not least - should not be difficult to implement in the formatter.


Your thoughts are welcome.




There is one comment on this page. [Display comment]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki