Daniel Glazman Outlines Future of Mozilla Composer

Wednesday May 7th, 2003

The new Mozilla Roadmap set out clear paths for Mozilla's Web browsing and mail/news applications with the continuation of the Mozilla Firebird and Mozilla Thunderbird projects. However, the future of the other Mozilla Application Suite components, such as Composer (Mozilla's Web page editor), was left less certain. Last month, Daniel Glazman, a member of the Mozilla Editor team and author of the popular CaScadeS stylesheet editor (now landed on the Mozilla trunk but not built by default), volunteered to continue maintaining Composer. Daniel has published a weblog posting outlining his plans for the future of Composer, which will live on as a standalone application rather than as a Firebird extension. The laundry list of planned improvements includes better CSS editing abilities, XHTML 1.0 support, an extension to allow MathML to be used and support for HTML forms. Improvements will also be made to make it easier for authors to create new extensions, opening up even more possibilities for Composer's future.

it does. Mozilla Editor (linked in the article) is used by Composer and for the embeddable HTML editing widget used for mail and other stuff. That will (necessarily) stay part of Gecko and be shared by Firebird, Thunderbird and the "standalone" Composer. The bits of Composer (the UI, for example) that aren't part of that Gecko core will live in a separate app, instead of being an extension on top of Firebird (which would be more like the current situation, where of course browser, mail and composer are all part of the same big app)

This sounds very positive. I'm glad he will be adding color to the html and attribute tags, which will make reading so much easier. I hope someone will make it so that Composer doesn't keep changing your source code every time you save, even when you have 'Retain original source formatting' selected. That's such a big pet peeve of mine.

True, but I was thinking more along the lines of if you are hand-coding the HTML yourself. Besides, having easy access to the validators might help us find bugs in Composer. Or you might just want it as a check that your page is OK.

Frameset support? I am not really against adding frameset support, but haven't many web developers stopped deveolping serious web sites using frames? If I am not correct I cannot remember many sites still using frames; maybe a few non-comercial sites but that's all.

while using frames on public websites is discouraged for a lot of good reasons, there are still some uses for it in internal web applications - for example, when you have a data-populated menu frame providing navigation for content in a main body frame. it can be expensive to continually requery to load the menu frame, and caching the data on the server can be a messy hassle.

How many personal homepages with frames are out there ? Wouldn't you want these authors to switch from MS Frontpage to Mozilla's Composer. I see lots of them that made a frames-page with Frontpage. But when they would like to edit it with Mozilla's Composer they are disappointed because Composer says it cannot handle it. Mozilla can handle frames without problem, so that sounds strange to these users.

You need not make a WYSIWYG-editor for me, but there are lots of users who just rely on WYSIWYG for their webpages. Mozilla's Composer can be a good alternative for them, if only it would handle frames correctly. Does not sound too difficult to add to me. If only one could visually design a frameset and define which webpage should be displayed in which frame...

I hate frames, but am completing a project that uses them for good reason.

Our problem is that the "navigation" is a large amount of data that comes from a relatively slow queries (between 10-30 seconds usually, and not very cachable). The query time is acceptable, but it would not be acceptable to reload this data on every click. Therefore, we 'cache' the data by leaving it a frameset. Although we are using good markup, any overhead from the HTML itself is trivial in most applications.

You reminded me of this one add-on that Netscape DevEdge once offered. It allowed you to visually make framesets, through an interface that looked a lot like Java. But I don't think that including support for editing frames is a must anymore, since they don't seem as popular.

I was under the impression that the reason was included in Mozilla in the first place was not simply because it had been in Netscape 4 and so it is in Mozilla. I believe the reason Composer was included in Mozilla was that it provided many useful services for the browser and mail apps. Wasn't Composer used to fill in texxt boes and to compose html mail. Wasn't composer used to allow the page source to be vied within the browser. How will all this be handled if CXomposer is a stand-alone application. Will the code have to be duplicated in the browser and mail application or will a lot of composer's code be embeded within the Gecko engine.

Don't get me wrong I am very pleased with the direction Daniel outlines in his blog for Composer. I am unsure how the browser and mail apps will fill in the gaps with Composer as a stand-alone application.

It is wonderful to see Composer's development continued. There is a need for a quality free web site editor which does not have a biased slant to a "Windows only" world. The web must remain functional for all. The web is not just for those running MS software.

To this end I hope Daniel will resist any pressure to add things that only work in Windows or IE. If it does not work in "most" (preferably "all") browsers and OSs I hope it will not be included.

I am sorry I keep posting double. The password manger keeps poppong up and confuses me as to wether the post has been made. This has been a known issue for <2 years with the password manager and forums such as MozillaZine. A bug was filed and resulted in a "Won't fix." Hopefully with the move to Firebird the password manager can be given a tiny bit of "artifical intellegence" so it only asks and stores one password at forums such as MozillaZine. :)

actually, AFAICS, the WONTFIX bug was an evangelism request asking that MozillaZine change the form to work with Mozilla. MozillaZine folks said it was actually a Mozilla bug and they wouldn't change the MozillaZine form, so that bug got WONTFIXed... sillyness...

after that, a bug for the Mozilla issue was filed, and that bug is still open - bug 153986

You're confusing Editor (the editing back end -- this supports things like transactions, text entry, etc, etc) and Composer (the front end -- this is all the composer UI, things like drag resizing of images, insert image dialogs, and so forth).

The former is basically going to be part of the GRE to be used by mail, composer, midas, etc. The latter is what Daniel is talking about.

I was under the impression that the reason was included in Mozilla in the first place was not simply because it had been in Netscape 4 and so it is in Mozilla. I believe the reason Composer was included in Mozilla was that it provided many useful services for the browser and mail apps. Wasn't Composer used to fill in texxt boes and to compose html mail. Wasn't composer used to allow the page source to be vied within the browser. How will all this be handled if CXomposer is a stand-alone application. Will the code have to be duplicated in the browser and mail application or will a lot of composer's code be embeded within the Gecko engine.

Don't get me wrong I am very pleased with the direction Daniel outlines in his blog for Composer. I am unsure how the browser and mail apps will fill in the gaps with Composer as a stand-alone application.

It is wonderful to see Composer's development continued. There is a need for a quality free web site editor which does not have a biased slant to a "Windows only" world. The web must remain functional for all. The web is not just for those running MS software.

To this end I hope Daniel will resist any pressure to add things that only work in Windows or IE. If it does not work in "most" (preferably "all") browsers and OSs I hope it will not be included.

I was under the impression that the reason was included in Mozilla in the first place was not simply because it had been in Netscape 4 and so it is in Mozilla. I believe the reason Composer was included in Mozilla was that it provided many useful services for the browser and mail apps. Wasn't Composer used to fill in texxt boes and to compose html mail. Wasn't composer used to allow the page source to be vied within the browser. How will all this be handled if CXomposer is a stand-alone application. Will the code have to be duplicated in the browser and mail application or will a lot of composer's code be embeded within the Gecko engine.

Don't get me wrong I am very pleased with the direction Daniel outlines in his blog for Composer. I am unsure how the browser and mail apps will fill in the gaps with Composer as a stand-alone application.

It is wonderful to see Composer's development continued. There is a need for a quality free web site editor which does not have a biased slant to a "Windows only" world. The web must remain functional for all. The web is not just for those running MS software.

To this end I hope Daniel will resist any pressure to add things that only work in Windows or IE. If it does not work in "most" (preferably "all") browsers and OSs I hope it will not be included.

Now that Composer is free of the rest of Mozilla, hopefully it will become eventually what I envisioned with mozOffice - a free, open source extensible document creation suite that can (blue sky!) create anything from spreadsheets to Web pages to letters. Good deal, Daniel!

I don't know if I see spreadsheets as a use for composer, but maybe. This may sound a little weird as I haven't put any thought into it until just now, but it seems like a spreadsheet and client-side database (something like Access) could (should?) be combined into a MozData application. That way you'd leave the MozData to deal with structured (cell-based) data, and Composer as a free-form text editor for document files, whether they be .DOCs or include all the bells and whistles of an advanced HTML/CSS editor.

I'm going to use my license to get even crazier and say that the applications should detect what mode you are using it in and shut off the other to conserve resources. For instance, if I'm writing my resume, I shouldn't need tag completion or W3C validators. But if I'm working on a web page with a text-editor, I shouldn't need bolding and underline. On furhter thought perhaps these should continue to be different apps after all.

While true spreadsheets (with calculations and similar stuff) seem unlikely to be in Composer, in general this sounds reasonable. I've heard of people in a small organization who used Composer (even in its current state) as a simple rich text editor for their internal document exchange.

>> I've heard of people in a small organization who used Composer (even in its current state) as a simple rich text editor for their internal document exchange.

Yes yes yes yes yes! I've thought about trying to get the users at our organization to convert as many of their documents as posible from word processors to HTML. You kill so many birds with one stone that way.

While it would be interesting to see composer write stuff like rtf files and pdf's and stuff, I don't think that it's a direction it should take. That should be up to OpenOffice. That way they can focus on making the best damn html editor out there.

No, it's not about producing rtf or pdf with Composer. The point is that HTML itself plus clean and nice editor is enough for _some_ real-life document exchange. And, given XHTML functionality planned by Daniel, this format would be true XML suitable for XSLT transformations and related technologies - just like OpenOffice formats.

So where does Venkman (the Mozilla Javascript debugger) fit in? Surely it fits with Composer - but should it be integrated into the default like Daniel plans for CaScadeS or is better suited as an extension?

Can't access Daniel Glazman's site right now, so will have to try to read his plan later. But I think a standalone Moz Composer is a great idea. I have tried several html editors and webpage tools and have yet to find one I really like. Always good to have another freeware choice.

I think this could be vital. Especially if composer is designed to be extended from the ground up. One of the best java editors (IMO) is jEdit (www.jedit.org) and I think it owes it's sucess to it's great plugin architecture. A whole community of people now contribute to its sucess and it would be nice if the same could happed for a W3C complient web editor.

Great idea. This design idea is one reason for Mozilla Firebird's increasing popularity. Making Composer extensible via extensions will inspire many developers to quickly add new features. I'm so glad Daniel is keeping Composer alive.

Wouldn't effort be better placed on making extensions like Mozile and Midas more powerful and feature rich? Yeah, it's neat to have a basic web editor out there, but things like Composer cannot compete with Dreamweaver (especially combined with Contribute) and GoLive. It can be done, but is it really truly necessary to have Composer?

Easy, Composer is perfect when someone wants to make an easy and quick web page. Perhaps spinning it off to a stand-alone product will allow it to gain features that will make it comparable to Dreamweaver and GoLive without introducing unwanted bloat into Midas and others.

If you make Midas more powerful and feature rich, then you got Composer. So nothing is gained by rewriting the wheel.

Also, the price of the Mozilla Composer is more appealing than that of Dreamweaver. I think there should be an open source alternative to all commercial products for people that have to work or compete with little or no money. Just don't call it CDex and put a TM after it.

If we drop composer by stating it cannot compete with commercial offerings such as Dreamweaver, there will be no viable option to Frontpage.

Frontpage developes sites best viewable with IE on Windows. I have encountered some commercial sites developed with Frontpage and many non comercial ones. Composer promotes a web which is viewable and fully functional regardless of the OS and browser used. Frontpage often promotes the ideal "best viewable with IE and Windows." In the free category for WYSIWYG web site development tools Composer is the only competition (I believe) to FrontPage. For the future of the Web (being viewable/functional regardless of OS or browser) we must not let Composer die.

Although there has been no official announcement about it, I am guessing that ChatZilla will either become another stand-alone product that uses the GRE or a Firebird extension. Stand-alone would probably be better in my opinion because an IRC Client does not belong with a web browser and nothing is gained from the intergration (unless there is a sidebar component that would allow you to chat on IRC while visiting web pages, then I can see the argument for an extension).

The plans for composer look great. It's currently imperfect in many ways, but it would have been sad to see it die. Hopefully becoming an application in its own right will prevent it from being seen as the runt in the Mozilla litter and allow it to get some developer attention.

In the meantime, since everyone is playing blue-sky ideas for composer, I thought that I could join in: http://zeus.jesus.cam.ac.uk/~jg307/

So soon I wil have to download like 4 seperate things to get what I get now in a 12M download? I'm sorry 12M is not that big these days. I do not want 4 seperate downloads when I can do just one and get everything I need in the Suite!

Don't assume things. Seems like everyone reads into things too much, without taking a look at the big picture and use some common sense.

Since when has Mozilla and Netscape never offered a complete download? Don't worry, I can almost guarentee that there will be a 1 file download that contains all the new stand-alone apps with the most common extensions. System administrators and the computer geeks always demand 1 big download.

For those who have dial-up and for those who wish to select what they download, the web installer will also be available for them so they can select exactly what they want. Dial-Up users do care about 12 MB files, especially if they have 1 phone line and need to use it for phone calls as well.

I'm really hoping that the ability to edit a html page that is currently being displayed in the browser is kept. This is so handy for keeping hyperlinked notes -something I use every day.

This is one piece of integration that I will really miss if it goes.

In terms of composer generally - it has always seemed to be a bit buggy and slow to me - though not as bad as it used to be. Also reformatting of pages is definitely annoying. Is spite of this I really hope it is kept as it is a very useful lightweight editor.

i love composer, and really can't wait to use the standalone version. It's the only reason why i keep downloading Mozilla, because i've been using Firebird and Thunderbird (today even Sunbird) since their first release.

I think that something useful would be a Tidy checker http://tidy.sf.net. The Validate HTML takes you to the W3C website while you can do it on your own computer. Tidy does an excellent job with XHTML1.1 strict websites.

And most important than all i think that composer is a great WYSIWYG editor, but not a very useful code editor... i found myself doing some layouts in composer but i can't even write in Composer... only a couple of weeks ago you were allowed to _search_ in the textarea... i think that the editor should be far more capable, and that should be with extensions.