Revision [6131]
This is an old revision of WikkaExtensibleMarkup made by DarTar on 2005-02-18 10:22:25.
Extensible markup for Wikka formatter
See also: WantedFormatters
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:
- Distinctiveness
good markup should be distinctive enough to avoid conflicts with content:
e.g.: vv text vv is a bad solution since vv is a sequence that is likely to occur in many natural languages and hence create conflicts between content and markup;
- Expressivity
good markup should have an intuitive informational value:
e.g.: ^^ text ^^ doesn't look like a good candidate for subscript, since it seems to express the opposite;
- Ease of use
good markup should be easy to memorize:
e.g.: %)° text °(% looks pretty hard to memorize as markup;
- Availability
good markup should not make use of characters that are absent/difficult to type on certain keyboard layouts.
e.g.: €€ text €€ won't be a good option on many non-EU keyboard;
- Consistency
good markup should integrate seamlessly with the existing conventions adopted in the formatter;
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. Block markup
xx(value) text xx (generally used for formatting code blocks)
C. Pseudo-formatters
{{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:
- x should be replaced by something intuitive, for instance ::^ text ^:: could be used for suprascript, ::! text !:: could be used for uppercase text, etc.;
- the symmetry in the markup is meant to remind the user that open markup has to be closed, which is especially useful in cases of nested markup;
General-purpose block markup:
::(class) text ::
:::(class) text :::
This syntax is consistent with the existing code block formatters and could be used to format other block-oriented content.
The main difference with tag-like markup is that
- on the one hand, this markup is less intuitive since it requires the user to learn a textual tag instead of a meaningful or iconic sequence of symbols: it would be extremely user-unfriendly to use a markup like this for basic formatting rules like bold, italic, small caps etc.; it would also be difficult to make sense of what markup is being closed in the case of nested markup.
- on the other hand, this markup offers an important advantage: it can be extended and customized by the user to apply a large number of CSS classes;
Notice that I propose two distinct block 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 works in the same way as tag-like markup, i.e. it results in formatted text, while ::: results in blocks that can be positioned, 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.
CategoryDevelopment