{"id":146,"date":"2003-10-13T22:27:15","date_gmt":"2003-10-13T22:27:15","guid":{"rendered":"tag:owlfish.com,2004:colinweblog.20031013222715"},"modified":"2003-10-14T05:33:31","modified_gmt":"2003-10-14T05:33:31","slug":"13102003","status":"publish","type":"post","link":"https:\/\/www.owlfish.com\/weblog\/2003\/10\/13102003\/","title":{"rendered":"Writing content for web pages"},"content":{"rendered":"

Last week I wrote a short article on the importance of a template based solution for web page<\/a> maintenance, and the sort of innovations that could be made to ease template design. At the end of that article I noted two other problems with web publication tools today: markup of the content, and the handling of non-journal style pages. This article addresses some thoughts I’ve had on the first of these two problems.<\/p>\n

The most popular template based systems today are those provided by blogging software. They allow an author to enter new web content either using a web browser (thin client) or a small application (fat client). When the author decides to include a link, make some text bold, or apply some other markup the most common solution is to have them enter HTML codes.<\/p>\n

Alternatives to entering the HTML manually include utilising IE specific enhanced textarea widgets, using a different markup language such as Textile<\/a>, or providing buttons that automatically insert the HTML tags.<\/p>\n

The markup in which an author’s content is written, and the markup in which it is published, must be treated separately, even if they happen to be the same. The reason for this is that an evolving web also means evolving markup for web pages, for example the transistion between HTML4 and XHTML1. When an author of a site chooses to move their pages from HTML to XHTML the software they use needs to be able to rebuild old pages using XHTML.<\/p>\n

For software to be able to perform transformations of markup from one language to another it needs to be able to parse the original markup perfectly. If the original markup is HTML this poses two problems: writing and parsing correct HTML programmatically is fairly difficult, and if users enter markup by hand then there will<\/b> be errors in it. The inability to convert cleanly to a new publishing markup language is a major defect in all of the blogging tools today that store and accept content using HTML markup. It is a hole that can be coded out of, but never in a 100% satisfactory way.<\/p>\n

The solution to this problem requires a combination of three things:<\/p>\n

    \n
  1. The adoption of a strict, easy to parse, format for authoring content.<\/li>\n
  2. The rejection of any content which does not adhere completely to this strict format.<\/li>\n
  3. The use of tools, rather than users, to generate this strict format.<\/li>\n<\/ol>\n

    The critical piece missing today of these three items is the third one: a GUI tool that allows the markup of web content in a strict, easy to parse, format. The bare minimum that such a tool should be able to support includes: links, text decoration (bold, italic, etc), lists (bullet and numeric), and images. There are lots of other types of markup which would be very useful (e.g. tables), but for most web content this limited list would suffice. Today there are many weblog authors who have tools and knowledge such that they don’t use the most basic of markup in their content. A GUI application supporting these features, and whoes output is in a strict format, would be enough to bring painless, sustainable content authoring to a much wider audiance.<\/p>\n

    Writing such a tool, while not technically difficult, does take time and effort. I hope to one day soon find an open source tool to do this. In the meantime however I have a partial solution: AbiWord<\/a>.<\/p>\n

    AbiWord is an open source word processor. A word processor isn’t really the best choice of tool for editing web content, simply beacuse it has too many features that are not needed or do not apply to the web. For example AbiWord supports Mail Merge, multiple document sections with different headers and footers on the pages, and other such features that are needed for document creation, but not for editing web content. <\/p>\n

    Despite these drawbacks the use of AbiWord does bring some significant advantages:<\/p>\n