Textile vs (X)HTML: How They Stack Up in Textpattern

My Arvixe blog post today continues in the Textpattern CMS + Textile theme of text processing. Last time, I introduced you to some of the more straightforward Textile tags to change the appearance of text. Textile’s capabilities extend much further than that, however, and in this post I’ll show you some more examples of what it can do for you, and the (X)HTML it generates. Textile is a very stable piece of software, and as such the tags below aren’t likely to radically change in the near future. There may, of course, be minor changes and additions in future releases, so be prepared to relearn things if the situation requires it. Let’s go!

In my mind, the main reason to use Textile is the speed and simplicity it offers me. Using comparatively fewer characters, it’s pretty straightforward to construct semantically accurate (X)HTML. I am very aware this is a personal interpretation of how Textile fits into my workflow and I am sure you’ll up your own mind when you try it out. If it doesn’t work for you, then it shouldn’t be seen as a bad thing or failure; there is no requirement to learn Textile to use Textpattern properly, so don’t feel pressured.

I’ll start with some easy stuff. In each case, I’ll show you what the (X)HTML structure is, and then how you can achieve the same thing in Textile. First off, let’s cover some block-modifiers: paragraphs, headers, block quotes and pre-formatted text. All of these examples assume Textile is turned on for articles; this is the default setting for new installations, and can be toggled on or off from the administration preferences.

Textile’d paragraphs don’t need any extra characters added to them in Textpattern. Paragraphs should be separated by an empty line. Line breaks (<br />) are also respected without any additional typing. With that in mind, if you want to achieve this:

<p>This is my opening paragraph.</p>
 <p>This is a paragraph<br />
 with a single line break.</p>

…then it’s simply a case of typing the following into your article/excerpt:

This is my opening paragraph.

This is a paragraph
with a single line break.

Note the blank line between the two paragraphs and the line break splitting the second paragraph. Note also that the paragraphs don’t have any indentation before the text; if you want to disable Textile for a specific paragraph, simply insert a single space before the first character.

Headers (<h1>, <h2>, <h3> and so on) are really easy to remember. To get this markup:

<h1>This is my h1 heading</h1>
<h2>This is my h2 heading</h2>
<h3>This is my h3 heading</h3>

…use this text:

h1. This is my h1 heading

h2. This is my h2 heading

h3. This is my h3 heading

Again, note the empty lines between the headings. Line breaks are respected in headings, so leaving the empty line ensures each heading is discrete.

If you’re quoting, you may use the <blockquote> tags that (X)HTML offers. To make a passage of text into a <blockquote> with Textile, use bq. So, if you want this:

<blockquote>Lorem ipsum dolor sit amet.</blockquote>

…use this:

bq. Lorem ipsum dolor sit amet.

Easy. If you use pre-formatted text – that is, text displayed in a fixed-width font – then you can achieve this with Textile, too. Say you want to have this code in your page markup:

<pre>Some pre-formatted text.</pre>

…just use this format:

pre. Some pre-formatted text. Spaces and line breaks will be preserved, if this is important to your text.

Combining all these together, you can achieve this markup:

<h1>This is my h1 heading</h1>
<p>This is my opening paragraph.</p>
<p>This is a paragraph<br />
with a single line break.</p>
<blockquote>Lorem ipsum dolor sit amet.</blockquote>
<pre>Some pre-formatted text.</pre>

…with this code:

h1. This is my h1 heading

This is my opening paragraph.

This is a paragraph
with a single line break.

bq. Lorem ipsum dolor sit amet.

pre. Some pre-formatted text.

The winner for me is the reduced amount of typing I had to do to achieve the same result. The pure (X)HTML block of code is 216 characters, according to my text editor, while the Textile’d version is 168 – that’s about a 22% reduction in characters. Even knowing some fundamentals of Textile can save you time and effort, which for me is worth a lot. Thank you for reading about Textile. Next time we meet I’ll be expanding on what we’ve covered so far, including some new tags and how you can fine-tune the Textpattern configuration to work with Textile on your terms. I hope you’ll join me.

Looking for quality Textpattern Hosting? Look no further than Arvixe Web Hosting!

Tags: , , , , , , , , , , , , , | Posted under Textpattern | RSS 2.0

Author Spotlight

Pete Cooper

Pete Cooper

Pete Cooper has been using Textpattern since 2005. Textpattern is his preferred CMS weapon of choice. Its logical and flexible approach to content management makes Pete happy, as does its lightweight core and helpful user community. Pete's website - petecooper.org - runs on top of Textpattern and chronicles his day-to-day experiences from his home near the Atlantic in north Cornwall, United Kingdom.

2 Comments on Textile vs (X)HTML: How They Stack Up in Textpattern

  1. Ozjon says:

    Good comparison of savings for writing straight forward text files in Textpattern.

    But these days a good CMS would have a text editor in rich text format thereby eliminating the need to do any html. I use WordPress on most of my sites and it really saves me so much time in writing text/html.

    But I vote for anything that saves time and internet traffic – even if it means a few milliseconds. That is a lot in the server time specially if you’re serving pages in mass.
    The real culprits of size are really the other page properties like graphics and the shameful and process hungry Javascript, flash and all other scripts that need to be served and run on visitor browsers. Html and text rally make up a small percentage of any page.

    Cheers!

  2. Pete Cooper Pete Cooper says:

    Hi Ozjon – thanks for your comment. You raise a good point about GUI editing in any given CMS. In my experience, the lack of a core GUI editor in Textpattern hasn’t held me back, but I can absolutely see how it’s affected take-up. There are plugins to add this functionality in, but there’s a valid counter-argument that having the scaffolding in place to have plugins take care of this is most appropriate. Personally, I’ve used fckeditor, tinymce and a bunch of others – none of which were appropriate for my needs. Additionally, a content management system doesn’t necessarily mean the same thing as a blog, for example, so the remit is different. If I’m using Textpattern for a calendar/scheduling site, then I perhaps don’t need the extra overhead that a GUI editor would give me – or perhaps I do. I’d much prefer the option to have any one of a bunch than have one bestowed on me.

Leave a Reply

Your email address will not be published. Required fields are marked *


9 × 6 =

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>