TikiText is a text formatting notation and engine that I've been using myself and have decided to release to the public to vet further. In addition to the Text::Tiki module, this package includes a MovableType plugin that hooks the Tiki module into MT with a text formatting plugin and container tag. It also includes an alpha of a command-line tool for coverting TikiText.
Download: .ZIP | .GZ | Reference Guide
UPDATE: More on TikiText here.
UPDATE 2: Version 0.50 is now available here.
Background
Despite the notion of a universal canvas, rich authoring of content through
Web browsers is still rather poor and laborious to do. There have been attempts to create
WYSIWYG editor widgets to rectify this, however none of these
tools are reliable cross-platform and cross-browser not and often lack the flexiblity of its
read-only counterparts. This is unfortunate and nothing one person will be able to fix any
time soon leaving us to cope with brain dead <textarea> and plain text.
TikiText is an attempt to work with what we have and minimize (not completely solve) these shortcomings.
Recently I was faced with the task of architecting a way for non-developer non-markup saavy business
user who where previously using FrontPage to publish writings to the Web. Plain text (with no
formatting) was not going to cut it. Nor was teaching them XHTML language. I did an intensive
study of different structured text formatting notations that have been developed in the past.
these notations included a few different Wiki implements such as UseMod Wiki, MoinMoin Wiki,
Text::WikiFormat, in addition to Zope's Structured Text and HTML::FromText and Textile.
For one reason one reasons or another these notions fell short of my requirements. So in scratching my own itch I developed a notionation I call TikiText (Tiki said tee-kee not tick-E like wiki that its name pays some homage to) based on my observations and key learnings. I defined the design goals for TikiText are as follows:
- Leverage existing text formatting notions.
- Least amount of characters from plain text.
- Use more intuitive and common plain text email conventions.
- Abstract users from needing to know or understand markup when ever possible.
- Make valid and semantical XHTML markup easy.
- Easy to learn the basics. Richer functionality for those who want to dive in.
Caveats: While this code is quite usable it should be used with the understanding that it is
still somewhat experimental and is just being tested and properly documented. Feedback, bug
fixes, and feature implementations are appreciated. Furthermore, I realized this format is less
then perfect and falls short of its design goals. My hope is that it will be refined an tweaked
over time to optimize its effectiveness.
<p><cite>TikiText</cite> is a text formatting notation and engine that I've been using myself and have decided to release to the public to vet further. In addition to the <code>Text::Tiki</code> module, this package includes a MovableType plugin that hooks the Tiki module into <acronym title="MovableType">MT</acronym> with a text formatting plugin and container tag. It also includes an alpha of a command-line tool for coverting TikiText.</p>
<p>Download: <a href="http://www.timaoutloud.org/projects/tiki/tiki.zip">.ZIP</a> | <a href="http://www.timaoutloud.org/projects/tiki/tiki.tar.gz">.GZ</a> | <a href="http://www.timaoutloud.org/projects/tiki/docs016.html">Reference Guide</a></p>
<p><strong>UPDATE:</strong> More on TikiText <a href="http://www.timaoutloud.org/archives/000218.html">here</a>.</p>
<p><strong>UPDATE 2:</strong> Version 0.50 is now available <a href="http://www.timaoutloud.org/archives/000224.html">here</a>.</p>
<h3><a id="Background"></a>Background</h3>
<p>Despite the notion of a <a href="http://udell.roninhouse.com/bytecols/2001-06-06.html">universal canvas</a>, rich authoring of content through<br />Web browsers is still rather poor and laborious to do. There have been attempts to create <br /><acronym title="What You See Is What You Get">WYSIWYG</acronym> editor widgets to rectify this, however none of these <br />tools are reliable cross-platform and cross-browser not and often lack the flexiblity of its <br />read-only counterparts. This is unfortunate and nothing one person will be able to fix any <br />time soon leaving us to cope with brain dead <textarea> and plain text.</p>
<p>TikiText is an attempt to work with what we have and minimize (not completely solve) these shortcomings. </p>
<p>Recently I was faced with the task of architecting a way for non-developer non-markup saavy business <br />user who where previously using FrontPage to publish writings to the Web. Plain text (with no <br />formatting) was not going to cut it. Nor was teaching them XHTML language. I did an intensive <br />study of different structured text formatting notations that have been developed in the past. <br />these notations included a few different Wiki implements such as <a href="http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki">UseMod Wiki</a>, <a href="http://moin.sf.net/">MoinMoin Wiki</a>,<br /><a href="http://search.cpan.org/author/CHROMATIC/Text-WikiFormat-0.5/lib/Text/WikiFormat.pm">Text::WikiFormat</a>, in addition to <a href="http://www.zope.org/Documentation/Articles/STX">Zope's Structured Text</a> and <a href="http://search.cpan.org/src/GDR/HTML-FromText-1.005/README">HTML::FromText</a> and <a href="http://www.textism.com/tools/textile/">Textile</a>.</p>
<p>For one reason one reasons or another these notions fell short of my requirements. So in scratching my own itch I developed a notionation I call <cite>TikiText</cite> (Tiki said <em>tee-kee</em> not <em>tick-E</em> like wiki that its name pays some homage to) based on my observations and key learnings. I defined the design goals for TikiText are as follows:</p>
<ul>
<li>Leverage existing text formatting notions.</li>
<li>Least amount of characters from plain text.</li>
<li>Use more intuitive and common plain text email conventions.</li>
<li>Abstract users from needing to know or understand markup when ever possible.</li>
<li>Make valid and semantical XHTML markup easy.</li>
<li>Easy to learn the basics. Richer functionality for those who want to dive in.</li>
</ul>
<p><strong>Caveats:</strong> While this code is quite usable it should be used with the understanding that it is <br />still somewhat experimental and is just being tested and properly documented. Feedback, bug <br />fixes, and feature implementations are appreciated. Furthermore, I realized this format is less <br />then perfect and falls short of its design goals. My hope is that it will be refined an tweaked <br />over time to optimize its effectiveness.</p>
This is a comment Todd Larason tried to post before I realized I blew it.<tim/>
---
Tables: I suspect they won't get use much on weblogs, but a simple table syntax is *essential* for some other uses TikiText might otherwise be nice for (see for example
http://www.molehill.org/twiki/bin/view/Replay/GuideSnapshotHeader -- I chose TWiki for that site based largely on its table syntax, since I
have dozens and dozens of pages like that).
Images: easy image linking is one of my must-haves for a system like this. Things I'm wanting to count as 'easy': automatically adding width & height elements; having a simple way to set both title and alt (okay with me if they're always the same thing); converting filenames that are relative to the text file into absolute URLs, even though the
text files may be accessible only through a cgi-script and the image files may be accessible only directly (I'd be okay if rather than supporting full 'relative filenames' it only supported 'current
directory', and it took one config item for normal URL prefix and one for image URL prefix, with the second defaulting to the first for most
people).
Possible syntax that works okay with the rest of the TikiSyntax: {alt-caption-title-text}:filename that requires setting the alt/caption/title to include an image, at least explicitely using an empty one. That could be considered a plus, though, to encourage good alt use.
A generalized syntax for classes would give all the benefit of an img-specific syntax for positioning, and a whole whole lot more. I
don't have any good suggestions for what that syntax should be -- it's okay for it to be somewhat more complex than the normal syntax, since
most people won't use it most of the time. having it there for times you do need it could turn this syntax into something that can *always*
be used, I think.
A syntax for div and span would be nice too, for similar reasons.
I don't know if should turn off tiki formatting, but there does need to be a way to do it, to allow cutting & pasting from legacy html
docs.
there needs to be a setting for whether to generate xhtml or html, for those of us who haven't made the xhtml leap but do care about validating and staying in browsers' strict modes.
a file inclusion feature might be useful, or might just be outside scope. I tried fitting it into Textile and couldn't make it fit very naturally -- it needed ways to include both before and after other
processing to be useful. I suspect I'd be just as happy using an m4 plugin for the cases where I actually need that.
Here is a comment Anil Dash posted[1] in the mt-dev[2] forum. <tim/>
---
These sample formatting options look good, certainly better than Textile. I was talking about these ideas re: Textile with Jason Kottke, and the conclusion we came to was that none of the HREF syntaxes (for example) were better than actually teaching people the full <a
href="url">link text</a> syntax to just use themselves.
Similarly, the only people I've ever seen use *bold* or /ital/ or even _underline or ital_ inline text tags in real life were geeks who use plain text email all the time anyway.
That being said, these are social problems, not technical ones. Nothing short of WYSIWYG would please some users, and until that's viable, I think you've come as close as is possible to making such things intuitive.
What I'd love is to have ALL CAPS on a line by itself recognized as a header, but I have no idea how you'd be able to assign what numeric header would be attributed to it. ALL CAPS INLINE could be <strong>, though.
Anyway, this is just thinking out loud, hope it's of use to you. Nice work on the plugin.
---
[1] http://groups.yahoo.com/group/mt-dev/message/135
[2] http://groups.yahoo.com/group/mt-dev/
Another piece of feedback sent via personal email. <tim/>
---
With regards to the issue of adding a class attribute to tags (of which there was some discussion in the blosxom mail list. If Tiki is designed to approach the notion of a universal canvas, then it needs to be as powerful as possible. I have two ideas to suggest:
1) Right after the hint symbol that informs the parser what kind of tag to insert, support the optional "<classname>" parameter, where classname is the value of the class attribute to be set for that tag. For example:
><greenquote> The quick brown fox jumped over the lazy dog.
would translate to
<blockquote class="greenquote"> The quick brown fox jumped over the
lazy dog.</blockquote>
But I don't like that solution quite as much as this one:
2) For every hint symbol, allow an optional # parameter. The thinking there is that maybe this parameter would pre map to a set of predefined attributes, so they can be used anywhere. These predefined attributes are defined by the guy setting up the Tiki engine on his own site This leads to the following:
> means blockquote (as usual)
0 => class="greenquote" (Defined in some external config file)
1 => class="redquote"
>0 The quick brown fox jumped over the lazy dog.
would translate to
<blockquote class="greenquote"> The quick brown fox jumped over the
lazy dog.</blockquote>
>1 The quick brown fox jumped over the lazy dog.
would translate to
<blockquote class="redquote"> The quick brown fox jumped over the lazy
dog.</blockquote>
Of course, this may mean that we need a paragraph symbol. The reason why I say "may" is because I don't think it should be required if you're not going to append a set of attributes to it. I'm not sure what punctuation you could use in it's place, though.
This could lead to such abuses as having 100 or more different possible parameter values, but that is for the developer to abuse, not you. Better still, it's an optional parameter, so if you don't need that power, you won't get it.
...you know, it just occurred to me that maybe there's some synergy between this and the acronym feature - build acronyms that expand to sets of attributes.
I'm still mulling the image one. I'm not sure how to hint at what an image would be, but the justification could be done by using <, |, or > (for left, center, or right justification) as a hint right after the filename. I'm assuming, of course, that the sizes are automatically calculated.
As far as table support goes, keep it simple. In my mind, the whole point of this exercise isn't to build new web pages from scratch - for example, I don't see any support for form elements in TikiText - but to help maintain content within a more complicated table structure (I'm old school that way)
well, I've babbled enough... ;) but I'm looking forward to using this in Blosxom.
I'm also looking forward to seeing it implemented in C for maximum speed... I'm a *very* junior C programmer, so it would be quite a task for me to attempt, but I might try after the spec settles down a bit.
Hi,
TikiText = cool idea.
I agree with Robert that complicated table stuff is probably going to be a headache. At least, the attempts I've seen to implement tables in Wiki markup are headaches, but I haven't looked at the Twiki markup that Todd mentions above. I'm uncommited on that issue, since I don't need tables myself (but of course, with my luck I'll need them in spades tomorrow \(*_*)/ ).
Personally I think of TikiText filling a niche closer to what's done with BBCode -- it's almost like setting up a bunch of vi macros, except that you don't have to see the actual expansions in your text until you're ready to render, just readable text.
One thing that's important to me is being able to paste in code. That's a problem with PHPWiki, for instance, and one of the reasons I wanted to start a wiki was to exchange bits of code.
Anyway, I look forward to tracking this... glad the forum is working now :-)
pat, fieldmethods.net - nlp & stuff.
By the way, I needed a table in my weblog today.
:)
This TikiText is pretty nifty.
I've been playing with the Tiki plugin for Blosxom, and I think I found a bug ... or it could be completely my fault for not using it correctly :-)
According to the doc, "multiple consecutive lines with the same starting format are treated as part of the same block". But when I do this (example: two consecutive lines, both beginning with a ' ' for a preformatted block), the resulting text is all smushed together on one line.
Aha! Just tried something else, and it seems like a *nix specific bug. It works just fine when the file is saved in DOS format (\r\n at the end of each line) instead of UNIX format (just a \n).
Not sure yet if this something in the blosxom plugin or in Text::Tiki...
Is writing out tags not allowed in TikiText or is it something with the Blosxom plugin that's causing link tags to show up in the final output of the text?
Larcher: Glad you like it. Let me know what you find. The TikiText engine shouldn't have a problem with *nix linebreaks. If anything I'd expect the reverse -- DOS has issues but Unix is fine. Let me know wha tyou find.
Tamaracks: Markup is disallowed in TikiText and assumed to be sample code.