A future for Composer

If you read last Mozilla.org staff meeting's minutes, you know that I proposed myself to maintain Composer. I did that because I do care about this product, and because I do think it has a great potential. Here is an unordered list of what I think we should do to keep this nice of piece of technology alive:

  1. We should make a standalone Composer. I spent quite a long time thinking about the pros and cons of making it an XPI for Mozilla Firebird and finally decided that it is probably not what we should do. One should be able to install and use a content editor based on Gecko without haing to install the corresponding browser. It's not an easy task, but it's mandatory.
  2. We need better support of CSS in Composer:
    1. Direct class assignment. It is proposed to resurrect bug 16255 and allow direct class assignment to an element through the hierarchical view of the selection available in the status bar of Composer. A new content menu entry should allow to pick any class "defined" in the stylesheets attached to the document, or directly edit the class attribute in a text editable field. The patch attached to the bug was a first try and we probably need better than that, for instance a proprietary extension to the DOM interface DocumentStyle allowing to retrieve a list of all classes defined in the sheets attached to the document.
    2. Direct inline styling of elements. One should be able to apply a border or an image background, margins, paddings and tutti quanti to any block-level element just like in all good text processors. CaScadeS can help, since its main dialog is made of overlays for each family of CSS properties (text, background, ...).
    3. Integrate CaScadeS. The CSS editor should be a default part of Composer.
    4. Movable objects. Users should be able to insert positioned objects wherever in the document, move them using the mouse, send them to back and bring them to front.
  3. Getting rid of useless <br>. Unfortunately, Composer needs for the moment <br> on empty lines, but we should get rid of trailing <br> in elements like list items.
  4. XHTML 1.0 support. Do I need to explain ?
  5. MathML support. There is quite a lot of user feedback about this. Could probably be done using an XPI.
  6. Forms support. Neil did a great job about it but it is still available only in the Debug menu of Composer. This should be finished and made available to all users in the Insert menu.
  7. Better source view. Composer needs to improve its source view, colouring the tags, the attributes, ...
  8. Extensions Central. We should have a unique location for all extensions to Composer and a few documents/tutorials about how the application can be extended with only XUL, JS and XBL. We also need to add an Extensions menu entry somewhere in Composer's menu.

All comments and suggestions welcome at daniel at glazman dot org.

Tristan Nitot (warning, keyword SMOKING_CARPET added), MozillaZine, jgraham, ZDNet, C|net News.com, Business Week