Introduction

There are a variety of WikiText constructs which can only occur on a single line. For example tables and list entries cannot have multi-line items within them. Currently there is no way to work around this without inserting WikiTalk into the WikiText.

In discussing ways to fix this, the idea was raised of using some new syntax to provide a "container" for multi-line text. This container could be processed without "breaking the line" and could thus be used to extend tables or list entries.

We currently have the following syntax for specific types of containers:

• The multi-line property syntax (PropertyName:[ ... \n])
• The escape sequence for inserting unformatted WikiText into a document ({@ ... }@)
• The formatting delimiters (%red% ... %%)
• A WikiTalk statement (@@ ... @@)
• The double-quote escape sequence

But each applies its own rules. Properties are formatted in a particular way, must be named, and are indexed and accessible through WikiTalk. Properties also cannot be started in the middle of a line, so they could not be used as is to extend things like table cells. The unformatted text delimiters also must begin and end on their own lines. WikTalk statements must be valid WikiTalk and would slow down page rendering (though the results can be intelligently cached) and are less accessible than other aspects of the WikiText syntax.

These are useful for specific purposes, but none provides a generic mechanism for containing text.

Features

(this is my pass at requirements, based mostly on what i'd said on the mailing list. Feel free to add, revise, delete, etc... as the discussion progresses)

• The syntax should allow the editor to make a container around an arbitrary range of WikiText
• Within a single line of text, or spanning multiple lines
• Containers cannot intersect unless one is a subset of the other.
• Multi-Line containers act do not act as a line break - rather they cause the starting line to continue to the ending line.
• Containers can be named or unnamed.
• Containers can carry formatting instructions with them.
• These could be CSS styles or simple %...% style instructions, or could follow the syntax for table formatting.
• Containers should become HTML blocks within the rendered HTML.
• Named containers could then become the the target of DOM operations.

• Containers should not invent some new format. They should reuse an existing WikiText format, or borrow from an existing well-known domain like XML/HTML.

Additional ideas:

• Containers can be visible or invisible like properties.
• This would probably be a style thing (assuming HTML allows it) so that you could have content on a page which was initially invisible and then use some on-page script to make it visible again.

Ideally the other types of containers could be implemented as more specific versions of the generic container. Properties, for example, would be named containers which carried the property CSS formatting class with them, and which had some special internal attribute that made them accessible through WikiTalk. {@ ... }@ blocks would be unnamed containers that were marked as unformatted text. etc...

Comments