Wikitax

Remark: The following is a proposal for large changes in Wikimedia's markup. Just because it is stored in Wikipedia doesn't mean that it is supported by the community or that it will ever be used for Wikipedia. On Wikitext syntax it's said that it is unlikely that this proposal will ever be implemented.

We are undergoing the finalization and standardization of Wikitax, a rich markup targetted for use by laypeople in effectively contributing to next-generation Internet-based collaborative, community, and content management interfaces. This specification was originally drafted by Derek P. Moore in conjunction with his work on the next generation of codebases for w:Independent Media Centers. We're in a sort of request for comments stage with Wikitax right now. We all need to just brainstorm and tweak.

See simple ideology of Wikitax to wax philosophical on the broad issues of usability and simplicity.

The resulting ideas, dialog, discussion, and|or specification may influence the development of w:Wikipedia:Software Phase IV.

If you wish to contribute to, comment on, or pose suggestions about the following draft specification, simply edit this page and break the text where you wish to comment with:

</nowiki></pre>
:Your comments, suggestions, ideas, contributions, critiques go here.
<pre><nowiki>

Or head over to Talk:Wikitax and discuss this page.

See also: http://www.piclab.com/cgi-bin/wiki.pl?Wikipedia_Text_Syntax

And so on with the fun:

#!/bin/sh vim - <<END_of_Multiline_Text Wikitax: a plaintext markup syntax to indicate semantical, display, and formatting information for text in CMSes, wikies, and blogs. Text may also include much of HTML, etc., if users wish to use HTML instead of the Wikitax equivalent. [?: what limits to impose, etc.] Technical notation [wb] = word boundary [sp] = space X <<: Y strict set inclusion: X is included in Y, but not equal to Y X /<<: Y strict set non-inclusion: not(X <<: Y) TODO (ideas that I need to flesh out more): * <big> and <small> [?: are equivalents to these necessary or desirable] * and other missing tags for text formatting [?: what am I missing] * aligned text and objects (maybe via some <div> or <span> equivalent) * headings <h1> .. <h6> ('-= h1 =-', '-=== h3 ===-', '-===== h5 =====-' [?]) + headings also create an anchor of '#heading-name' + headings also create sections, which are closed with something similar to: '[[:end-section: "Ogg Vorbis"]]', assuming a heading of '-== Ogg Vorbis ==-' I'd like to encourage consideration of a heading markup that is the same length for all heading levels, and explicitly includes the heading level. For example (building on my TWiki background): "---+1" for Level 1 thru "---+6" for Level 6. The reasons relate to my attempts to create (single heading) fold macros for editing TWiki files with Nedit, and the difficulty of doing that because Nedit RE's (at least) do not allow a variable multiplier. I.e., I'd like to do something like search for "---\+{1,a}?{?= }" inside a loop where a is decremented from 5 to 1 (along with some other processing). See [[1]] for a little more information and links to even more (I hope).</nowiki> Software should follow the syntax not the other way round. But you can regexp wikitax into your syntax and vice versa, this should solve the problem. I agree that I could convert between syntaxes, it's just extra steps that could be avoided. While "Software should follow the syntax not the other way round" might be (probably is) a reasonable rule of thumb under most circumstances, the request should be considered on its merits and the specific situation. * definition lists [?: what would the best syntax be] * cf. <http://www.wikipedia.org/wiki/Wikipedia%3AHow_does_one_edit_a_page> * cf. <http://docutils.sourceforge.net/rst.html> -= Text formatting =- The following table gives an overview of the [/basic/] text formatting features of Wikitax: Syntax Translation ------ ----------- [*bold text*] <b>bold text</b> [/italicized text/] <i>italicized text</i> [=monospaced text=] <code>monospaced text</code> [_underlined text_] <u>underlined text</u> [-striked text-] <s>striked text</s> [+emphasized+] <em>emphasized</em> [++strongly emphasized++] <strong>strongly emphasized</strong> [+++very strongly emphasized+++] <em><strong>very strongly emphasized</strong></em> [^superscripted text^] <sup>superscripted text</sup> [,subscripted text,] <sub>subscripted text</sub> [%literal text, [/not evaluated/]%] literal text, [/not evaluated/] The various markups for text formatting can be applied in whatever combinations you wish. For example: [*[/bold and italicized/]*] [/[=italicized monospace ([-striked-])=]; not monospaced, still italicized/] [_underlined text with [^superscripted^] and [*bold*] words_] Are there any combinations that should be explicitly defined as illegal? Should overlap like '[=monospaced, [/plus italics=], still italicized/]' be considered legal and rendered into the target language properly, e.g., '<code>monospaced, <i>plus italics</i></code><i>, still italicized</i>'? The [bracketing] is very cumbersome. This needs to be seriously looked at. Why not just *bold* for bold? Bracketing should only be used for the below (i.e. to encompass blocks of multi-paragraph text). Also, monospaced text overrides h1. It should be something like: |monospaced|. Moreover, what's wrong with the current '''bold'''? I like it. It's easy. And it combines well into '''''bold italics'''''. Emphasis markers are obsolete. No one really uses the HTML emphasis over more direct bold and italics. --w:User:Alfakim <nowiki> -== Formatting in blocks ==- Text can be formatted inline—as we've already seen—but we'd probably also run into cases where it'd be helpful if the text could be formatted by blocks. If a line contains only markup codes, and no other text, the interpreter should know to expect a block. The block is closed by the corresponding closing tags being on their own line at the end of a block. For example, [* This paragraph. And this paragraph, too. Are bold. *] Or, something that might be useful in the collaborative editing of documents, [/[- This block of text is italicized and striked because maybe it should be removed. There are several paragraphs o' junk here. We're better off without it. -]/] One of the inline markups that would function specially in block mode is the monospace markup, [= ... =]. As this syntax provides for technical-looking text inline, it sort of follows that in block mode it would provide for monospaced, preformatted text—i.e., equivalent to <pre> ... . Markup inside a preformatted block [*is*] evaluated. For preformatted, literal (non-evaluated) text, [=[% All the text in this block is to appear /exactly/ as it does in plaintext, with no evaluation of markup, etc. Ampersands, angle brackets, and other special characters should be translated into their character entities, though, so they're rendered properly in browsers. This should behave like in Wikipedia markup. [*All*] Wikitax markup within this block [/is not/] rendered.  %]=] Blocks of text might require other forms of formatting that don't occur on an inline basis; e.g., indentation, etc. For indentation, the following syntax is proposed: [> This block of text is indented, similar to <blockquote>. <] Possibly you want different levels of indention (on the left or right side of justification), etc. Other possibilities may be [>> This block is indented two levels, on both the left and right sides of the page. <<] ... Or ... [>> This block is indented two levels on the left, but one level on the right. <] ... Or ... [>>> This block is indented three levels on the left, but fully justified to the right. |] ... And things such as the following would prove useful: [| This block is fully justified on the left, but indented three levels on the right. <<<] Can anybody think of any other block-mode-only formatting that might be required? Yes, two things: [>> This text is indented two levels on the left, and inherits default right-hand formatting #] ...and... [{ This text is contained within a left-floating div. {] Question: Would implementing markup attributes be too much? E.g., what if you want to specify the width of a left-floating div? -Nathan 21:48, 14 December 2005 (UTC) -= Wiki links =- Syntax Translation ------ ----------- [[Wiki Link]] <a href="...?$1">$1</a> <a href="...?Wiki_Link">Wiki Link</a> [[link->Wiki Link]] <a href="...?$2">$1</a> <a href="...?Wiki_Link">link</a> Wiki links are a means of creating links to wiki-style content. Text surrounded in double square brackets, [[ ... ]], constitutes a wiki link. For example, in this sentence, the phrase [[Wiki Links]] is surrounded by square brackets. In your normal wiki-style setting, the phrase 'Wiki Links' in that sentence would become linked to the article entitled 'Wiki Links'. What I refer to as wiki links in this document are sometimes referred to as 'free links'. Say we wanted to create a wiki link that points to the 'Wiki Links' article, but we want the text of the link to read 'free links'. This is illustrated in the following sentence: Wiki Links are sometimes referred to as [[free links->Wiki Links]]. The [[ ... -> ... ]] syntax is perfect for some situations, but far too verbose in others. Say we are talking about governments, and we want the word 'governments' to point to the article on 'government'. In cases similar to this, it's quite ridiculous to write '[[governments->government]]', when '[[government]]s' is much more concise and straight-forward. This suffix syntax for Wiki Links is often quite useful, as you can imagine. Suffix syntax should also work with other popular suffixes, e.g., -ing, [[cater]]ing; -ed, [[retard]]ed; -'d, [[GPL]]'d; -'s, [[Derek P. Moore]]'s; -s', [[people]]s'; -', [[General Motors]]'; -es, [[wiki]]es; -es', [[wiki]]es'; etc. The possessive noun suffix, -', might conflict with times when you want to surround a wiki link in single quotes, e.g., '[[quote]]'. Having the parser figure out when a single quote is the end of a quote or alone may be difficult, so maybe it should just check to see whether wiki link ends in an 's'. Very much dislike -> as unintuitive. Although for a reader it looks intuitive what it does, for a (first time) editor there is nothing intuitive about ->. They might remember it was an arrow, but then that could be: =>, ==>, -->, >>>, >, etc. MUCH more intuitive would be =. So: [[link text = Namespace:Article]] Even this is mildly unintuitive. Suggest completely new: [link text [Namespace:Article]] interchangable: [[Namespace:Article] link text] This would be followed by a reduction of wikilinking to [Namespace:Article], and an introduction of [text <whatever>] to create a caption of "text" around <whatever>. --w:User:Alfakim. -== Linking with URIs and email addresses ==- Syntax Translation ------ ----------- {{http://hackunix.org/}} &lt;<a href="$1">$1</a>&gt; <http://hackunix.org/> {{derekm@hackunix.org}} &lt;<a href="mailto:$1">$1</a>&gt; <derekm@hackunix.org> {{hackunix->http://hackunix.org/}} <a href="$2">$1</a> <a href="http://hackunix.org/">hackunix</a> {{email me->derekm@hackunix.org}} <a href="mailto:$2">$1</a> <a href="mailto:derekm@hackunix.org">email me</a> -== Linking to other wikies ==- Sometimes it may be necessary to link to other wikies. Suppose you're writing an article about anarchism, and you wish to create a simple link to Wikipedia's immaculate section on the topic. Instead of using {{ ... }} and linking to the absolute URL (which may change in the future), you could use: [[Wikipedia::Anarchism]] Or if you wish to define alternate text for the link, [[learn about anarchy->Wikipedia::Anarchism]] . Should the URLs to Wikipedia's content change, you won't have to hunt through all your articles searching for affected links. You can easily fix everything with one change where ever the configuration of inter-wiki link keywords takes place. The syntax for linking inter-wiki is very similar to the syntax for accessing namespaces (which we'll get to below). However, to differentiate it from the namespaces syntax, inter-wiki links use the double colon (::). Where the inter-wiki links syntax is wiki - colon - colon - article-identifier [[wiki::article identifier]] . The namespaces syntax is namespace - colon - article-identifier [[namespace:article identifier]] . The inter-wiki namespaces syntax becomes wiki - colon - colon - namespace - colon - article-identifier [[wiki::namespace:article identifier]] . And, while we're at it, the advanced features syntax is colon - keyword - colon - space - arguments-delimented-by-spaces [[:keyword: arg1 arg2 arg3 ...]] . This was done so advanced feature keywords won't conflict with inter-wiki link keywords. -== Namespaces and wiki links ==- It may be desirable to have support for namespaces in wiki links and inter-wiki links. Namespaces would be useful for accessing special system pages, special content categories, etc. These links would be similar to normal wiki links or inter-wiki links, except having a colon (:) separating the namespace from the article identifier. For example: [[namespace:article identifier]] [[special:site statistics]] [[Wikipedia::user:jizzbug]] [[discuss Wikitax->Metapedia::Talk:Wikitax]] There are no spaces between namespace, colon (:), and article identifier. This is to allow article identifiers in the likes of: [[Magic: The Gathering]] [[Wikipedia::2001: A Space Odyssey]] -= Advanced wiki links =- When developing a plaintext markup language such as this, one sometimes desires much more advanced features; such as embedding media (images, audio, video, etc.) within article bodies or linking to that media within the text. Fortunately, the wiki link double-square-brackets syntax lends itself to this purpose quite naturally. Instead of creating another syntax for users to remember, we can employ square brackets to access the more advanced features that we require. The syntax for accessing these advanced features is [[:keyword: variables ...]] . Say we've attached an image to our article. Including that image at some point in our article, scaling it down 30%, and having it floated to the right for the text to wrap around it, might look like [[:media: image.png scale="30%" align="right"]] . Or suppose that instead of embedding the image somewhere in the body of the article and having the text flow around it, we wanted to provide a text link to that image. This might be achieved with [[an image in PNG format->:media: image.png]] . A precise syntax for this advanced features markup still needs to be fleshed out. What fundamental keywords would be needed or useful? What should the exact syntax be for the :media: keyword? Et cetera. Regardless of which keywords should be standardized and what their arguments should be, this syntax for accessing advanced features is very useful. It provides a simple markup that is easy to understand and is easily extensible for application specific needs. Think about a syntax of [[wiki:::keyword: args ...]] for accessing advanced portions of other wikies. For example, [[Wikipedia:::media: /upload/d/d6/Lisbon_sisters.jpg align="left"]] or [[Wikipedia:::media: Portland.jpg scale="125%" align="right"]] . Would these types of advanced inter-wiki links be desirable or necessary? Both desirable and necessary for a good Web 2.0 implementation like we've been discussing :) -Nathan 21:48, 14 December 2005 (UTC) -== Proposed syntax for :media: keyword ==- [[:media: filename variables ...]] [[link text->:media: filename variables ...]] filename If filename is specified as solely the filename, e.g. image.png, the media item is assumed to have been attached to the article itself, and it is found by checking the filenames of attached media items. If filename is relative, e.g. /images/logo.png, the media item is assumed to be found at that relative path on the HTTP server. If filename is absolute, e.g. ftp://ibiblio.org/pub/multimedia/pictures/historic-computing/pdp8_1.jpg or http://w3.org/Icons/w3c_home.png, the media item is assumed to be found at that location, optionally to be cached locally. height Specified as a pixel value or percentage. width Specified as a pixel value or percentage. scale Specified as a percentage, much simpler and more straight-forward than specifying both height and width. Especially since height and width percentages are relative not to the natural size of the media, but to the available space within which to render the media (see <http://www.w3.org/TR/html4/struct/objects.html#visual>). caption Values of "on", "yes", or "1" would format the rendering of the embedded media to include a caption. The caption would most likely come from a field in the database entry for that piece of media. Values of "off", "no", or "0" would turn off the rendering of the caption text. Any other values, that value becomes the caption; e.g., caption="My favorite (and now dead) cat, Moorefield." Another possibility is that captions are off by default. If 'caption' is given as an argument, captions are turned on for that media item, and the caption is pulled from the database. If 'caption=' is given as an argument, captions are turned on for that media item, and the caption text is specified in quotes ("...") after the equal sign. alt [?] To specify alt text. But would this really be necessary? Couldn't alt just be populated with the caption text from the database, or from the caption text specified via 'caption='? align A value of "right" will "float" the media justified to the right with text wrapping around it. A value of "left" will "float" the media justified to the left with text wrapping around it. A value of "center" will center justify the media; text will not wrap, but will be split above and below the media at that point. If this variable is not specified, the media is displayed "inline" with text. This is the same as specifying a value of "bottom". A value of "bottom" will vertically align the bottom of the media with the current baseline. This is the default behavior in most UAs when alignment values are not specified. A value of "middle" will vertically align the center of the media with the current baseline. A value of "top" will vertically align the top of the media with the top of the current text line. type To specify the content type of the media; e.g., text/plain, image/png, or application/mpeg. Most people probably wouldn't need to use this argument, but it's included for completeness. If link text is specified, no variables need be specified, as their purpose is only served when the media is to be rendered within in the article body. What arguments might be useful if the media are audio or video data, etc.? -== Redirects ==- As sites evolve and grow, content gets shuffled around. To keep these activities from breaking old links, a means of redirecting browsers from one location to another is needed. Conforming this idea to the advanced features syntax is fairly straight forward: [[:redirect: "article identifier"]] Ideally, the redirect tag would be the only thing contained within the body of the article. At the very least, it should be at the very top of the body. If it occurs anywhere else, it ought to be ignored. -== Includes ==- Similar in nature to redirects, but inverting the concept somewhat, are includes. To avoid unnecessary replication/duplication of content, it might sometimes be useful to provide authors with the ability to include other content or sections of content. Authors should be able to either include the entire content, or a section of the content: [[:include: "article identifier" {section="section-name"}]] -== Table of contents ==- Dynamically generated tables of content would be very useful for making large articles more readable and navigable. The software could analyze the sections or headings of documents on the fly to create tables of content when it sees: [[:toc:]] -== Proposed advanced feature for page breaks or form feeds ==- It might be useful to provide authors with the functionality of being able to break up their articles into multiple pages. But what should the syntax for this feature be? [[:page-break:]]? [[:form-feed:]]? [[:pgbr:]]? [[:pb:]]? [[:ff:]]? all of the above? -= Other stuff I need to write more about =- Syntax Translation ------ ----------- item 1 <ul><li/>item 1 item 1.1 <ul><li/>item 1.1</ul> item 2 <li/>item 2</ul> item 1 <ol type="1"><li/>item 1 item 1.1 <ol type="1"><li/>item 1.1</ol> item 2 <li/>item 2</ol> @ item A <ol type="A"><li/>item A @@ item A.a <ol type="a"><li/>item A.a</ol> @ item B <li/>item B</ol> % item I <ol type="I"><li/>item I %% item I.i <ol type="i"><li/>item I.i</ol> % item II <li/>item II</ol> + item I <ol type="I"><li/>item I ++ item I.A <ol type="A"><li/>item I.A ++ item I.B <li/>item I.B +++ item I.B.1 <ol type="1"><li/>item I.B.1 +++ item I.B.2 <li/>item I.B.2</ol></ol> + item II <li/>item II ++ item II.A <ol type="A"><li/>item II.A +++ item II.A.1 <ol type="1"><li/>item II.A.1 ++++ item II.A.1.a <ol type="a"><li/>item II.A.1.a</ol> +++ item II.A.2 <li/>item II.A.2 ++++ item II.A.2.a <ol type="a"><li/>item II.A.2.a +++++ item II.A.2.a.i <ol type="i"><li/>item II.A.2.a.i +++++ item II.A.2.a.ii <li/>item II.A.2.a.ii</ol> ++++ item II.A.2.b <li/>item II.A.2.b</ol></ol></ol> + item III <li/>item III</ol> ---- <hr/> [wb][sp]--[sp][wb] [wb][sp]&mdash;[sp][wb] [wb][sp]-[sp][wb] [wb][sp]&mdash;[sp][wb] [wb]--[wb] [wb]&mdash;[wb] & (when '&' /<<: character entity) &amp; < (when '<' /<<: markup tag) &lt; > (when '>' /<<: markup tag) &gt; -= Other stuff to think about more =- Some suggest that syntaxes similar to '[[ ... | ... ]]' and '{{http://ls/ weird}}' are not intuitive. This criticism is valid, so we should all think about the matter. A nice alternative that has been suggested is employing pointers. Instead of the alternate text coming after the target, it comes before, with a nice lil' arrow pointing to the target: [[learn about anarchy->anarchism]] [[learn about anarchy from Wikipedia->:Wikipedia::Anarchism]] [[look at this picture of my cat->:media: moorefield.jpg]] [[my profile at Wikipedia->:Wikipedia::user:jizzbug]] {{check out Indymedia->http://www.indymedia.org/}} Is this more intuitive? Do we likey? END_of_Multiline_Text

I like it because in addition to whatever benefits you see, those lines can be (more easily) sorted (for example, in alphabetic order) based on what the reader sees vs. the address of the link. --SomeoneElse