In one of the earlier posts about editing a site with Typeroom there was a nice review of functionality but it missed a real-life test case. Now as we have had a really nice option to test it, here is the more specific addition to the previous article.

To test Typeroom, we took the most recent site of Swapnabhumi: The Promised Land that is the site of a film documentary about the stateless urdu-speaking or Bihari community of Bangladesh. The site is W3C standards compliant and passes XHTML Strict 1.1 and CSS Level 3.

In most parts Typeroom did its job well and at the glance everything seemed to be right as the site displayed properly. But then again it didn't pass validation any more. To be precise, it came up with 171 (!) validation errors.

So here are the flaws in detail:

Regenerated line breaks and tabs

It appears that Typeroom does not respect line breaks/proper tabbing the way expected and blocks of code will appear on one line so that

<div class="strips">
  <img title="Anwar Hossain" src="http://tekkie.flashbit.net/wp-admin/files/credits/anwar_hossain.jpg" alt="Anwar Hossain" />
  <img title="Shafiur Rahman" src="http://tekkie.flashbit.net/wp-admin/files/credits/shafiur_rahman.jpg" alt="Shafiur Rahman" />
</div>
will be converted to
<div class="strips"><img title="Anwar Hossain" src="http://tekkie.flashbit.net/a4315/files/credits/anwar_hossain.jpg" alt="Anwar Hossain" width="66" height="321" /><img title="Shafiur Rahman" src="http://tekkie.flashbit.net/a4315/files/credits/shafiur_rahman.jpg" alt="Shafiur Rahman" width="72" height="321" /></div>

Overhead of relative paths

As you can see above, the path of files/credits/anwar_hossain.jpg has been changed to ../a4315/../a4315/files/credits/anwar_hossain.jpg which is not exactly wrong, as a4315 was the subfolder, but it's surely unnecessary overhead and it exponentially overwhelming on further revisions. Each revision results in another set of ../a4315/.

This also happens to href attributes:

<a title="Digg" href="http://tekkie.flashbit.net/a4315/#digg"></a>
 

Open tags of XHTML

Image tags have been left open so Typeroom didn't consider the doctype. XHTML expects

<img alt="" />

That is the case for all the elements that do not have closing tags, e.g. meta, link, meta, input or br .

Wrapped comments

Comments like

<!-- Footer -->

will be converted to

<div><!-- Footer --></div>

or put into the paragraph which may basically break your site's layout.

Conclusion

Typeroom is probably highly awaited amongst many website owners and surely it is useful to many. Yet if the developer of a particular static solution has put a lot of effort into standards compliance, Typeroom is not going to respect that effort at this stage and there's a chance it will break a site.

Looking forward to the first stable.