Semantic text editors and Wikis

Most text editors nowadays (including Microsoft Word) provide a huge range of different styles for the user to present their documents - bold, alignment, indent, border, background-color, spacing, font color, and many more.

As a result, their range of semantic elements is poor. As Ian Hixie says, "People think visually. Trying to ask a Web designer to think in terms of (e.g.) headers instead of font sizes is just something that WYSIWYG implementers and UI researchers simply haven't solved yet."

Too much style, too little semantics

This doesn't matter too much in a stand-alone Word Document. But in a collaborative environment - like a corporate portal, or a web community - it's much more important. It enforces a consistent look and feel, it allows for re-styling of the entire site if required, it reduces storage size, and it aids search engines.

The solution may be the Wiki. The Wiki designer selects site-wide CSS styles for each HTML element, with some options where necessary. For example, they may select:

• standard paragraph font type, color, size
• three types of <emp> element, with bold, italic and underline
• standard header elements
• standard list types
• various different table options, e.g. header rows and cells, data rows and cells

Then end users must choose the relevant elements, rather than using arbitrary styling. By removing unnecessary options - for example, enforcing the Arial font - Wikis are also actually easier to use.

The semantic text editor is an old vision. But new ideas about content management and user collaboration - specifically, Wikis, which will grow massively in usage - offer a solution.

Functional Animation, revisited

Since my blog post on Functional Animation, there's been some movement towards the idea of setting DOM nodes to equal functions of other (potentially varying) nodes.

In fact, this idea already exists in XSL - see the code below, where the second paragraph is set to contain the same text as the first paragraph.

<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml/" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<body>
<p id="p1">p1 content</p>
<p id="p2" title="{//p[@id='p1']}">
          <xsl:value-of select="//p[@id='p1']"/>
</p>
<a href="javascript:document.getElementById('p1').textContent 
  = 'test'">Test</a>
</body>
</html>

When you click on the "Test" link, the value of p1 is changed - and p2 should automatically update too (both its content and its title attribute).

Unfortunately, p2 doesn't update - it seems that browser makers don't automatically re-execute XSL stylesheets. Interestingly, CSS stylesheets do re-execute when you add or change nodes, and there's no mention of what should happen in the XSL spec. I don't see why browser makers couldn't extend their code.

An idea whose time has come

This idea of Functional Animation is so useful and intuitive - probably replacing most awkward DOM Events code - that it's a real shame there aren't any widescale implementations.

Having said that, I recently saw the idea cropping up in several places:

• the bind keyword in Java FX scripts
• the "{ }" binders in Flex 2
• Functional Reactive Programming
• the <output> form element in HTML 5
• the <bind> element in XFoms

Personally, I like the XSL approach with inline XPath, because it's much more natural at selectors. On the other hand, some might prefer javascript due to its familiarity and extra features (e.g. Math and String functions).

Either way, it's clearly an idea whose time has come!

REST, Ajax, and personalization

I didn't realise it until recently, but if you follow REST principles, then you're pretty much forced towards Ajax - the two come together. That's due to page personalization.

When I navigate to www.amazon.com, several parts of the page are personalized. It says "Hello, Chris Jay" at the top, and offers recommendations for me, presumably based on purchases I've made in the past.

Although it's a very nice touch, this bothers me. At first glance, following REST, shouldn't the URL www.amazon.com be the same for everyone? Otherwise it can't be cached!

Option 1: Separate URLs for everyone

One option would be to redirect me immediately to something like www.amazon.com/ChrisJay/, containing my personalized homepage. This would require permissions, as set by the cookie - otherwise, other people could access this URL too. But that also holds for the current Amazon site.

There are several benefits to this approach. Amazon and my ISP can now both cache my homepage, so when I access it again, I see it much more quickly. And it's obvious from the URL that the page is personalized.

Unfortunately, following this option, the main body of the page - the bit that's not personalized - is not cached separately. It has to be produced again for every user.

Option 2: Same URLs for everyone, use Ajax

Another approach would be to keep using www.amazon.com for everyone, but include some Ajax that scans the HTTP header, reads the current user id, uses it to GET another REST URL (e.g. /recommendations/ChrisJay), and displays it inline.

That way, the homepage can be cached for anyone (including the Ajax code), the personalized bits can also be cached separately, and the REST architecture is still followed.

For this reason, Option 2 is the better approach.

Designing your URLs

The first step to building REST sites is to select your URLs.

You might think the rule is "one URL for every page". But that's not necessarily true, as Option 2 shows, especially if you're offering personalized sections to a page.

A better rule would be "one URL for every page and for every personalized section".

Then you can use Ajax to tie the two up.