Little pleasures

Now working on BlueGriffon after Nvu, there are a lot of things I can implement in BlueGriffon I could not achieve with Nvu. The reason is the maturity of the Mozilla platform. Let me list the plusses I just could not live without any more:

  • xulrunner ; I said it many times in the past but let me repeat it one more time : xulrunner is a true cornerstorne in the Mozilla ecosystem.
  • CSS 3 selectors ; that's surprising but the :nth-child() selectors and friends I introduced in the first Selectors draft so long ago are so powerful they allow a wide range of new features.
  • DOM 3 getUserData/setUserData ; the possibility to add data to the DOM without hurting the serialization is a major thing for me.
  • Storage and sqlite-based templates ; it's wonderful and probably deserves a FUEL-like library to simplify sqlite databases' manipulation. And Laurent told me today I could even write my own template system based on whatever component I want. Just lovely !
  • XBL ; Laurent and I recently discovered that we don't need any more to call this.parentNode.parentNode.... to call a method on the bound element from an anonymous descendant. XBL bindings are much simpler and maintainance/changes are simpler since we can move anonymous nodes in the <content> element without having to care about the context. That's a great plus.
  • the style and override manifest instructions ; they are so powerful for such a simplicity they allow beautiful things.
  • JavaScript's speed ; to give a very concrete example, Nvu had c++ code to gather the list of classes and IDs used in the selectors of all stylesheets attached to a given document. At the time I implemented it in c++, I dropped a JS implementation because it was just too slow to be usable. BlueGriffon has the same feature, now implemented only in JS, and the speed difference with the c++ implem in Nvu (gecko 1.7) is negligible. Wow, to say the least...
  • canvas ; do I need to explain ?
  • HTML5 drag and drop, deliciously simple to manage.

The things I still miss:

  • dependant windows ; I'd love to be able to open a window from another one and have both of them moved or inconified/raised together.
  • a library of transitions à-la-jQuery in XUL to make smoothly appear dialog areas or smoothly resize dialogs, slide deck contents.
  • a HTML parser ; that's amazing the number of ugly things Myk and I had to write for microformats or webchunks just because we don't have a HTML parser... The current need to use a hidden (or visible if you're lucky) iframe is painful.
  • since JavaScript now reaches the speed magnitude of native code, I'd love to see CSS Selectors' extensiblity. I want to be able to define my own boolean pseudo-classes without having to hack SelectorMatches(). It's not purely theoretical, I would use that immediately.
  • a more powerful CSS Object Model storing not only CSS rules recognized by Gecko but also unknown rules and comments. This is a very tough issue, hard to solve. But a web editor will always suffer if the user loses the comments or the non-standard rules he/she inserts in stylesheets..
  • CSS Media Queries... Having in the same web editor the ability to edit a document for normal, medium and small screens is a real plus and CSS MQ are the technology I need here.

Things I have not used yet but I will definitely use them in the near future:

  • JavaScript code modules (JSMs)

And the things I still dislike and want to see dumped:

  • XSLT ; yeah yeah XSLT is powerful but it's also an awfully complex solution when you want to deal with simple transformations.
  • RDF ; a proof of existence of the devil.


1. On Tuesday 7 October 2008, 00:43 by Wladimir Palant

What's the advantage of getUserData over expando properties? That means of course, other than the fact that it circumvents XPCNativeWrappers protection (just a guess). Maybe I missed the point here...

2. On Tuesday 7 October 2008, 03:51 by Robert O'Callahan

We have CSS Media Queries on trunk. What do you need that's not there?

3. On Tuesday 7 October 2008, 04:03 by Boris

Daniel, if you're getting speed similar to C++ from JS that means that you're probably bound by the peformance of the underlying CSSOM code... Even with Tracemonkey we're about 6x slower than optimized C++ at integer math; worse on more complicated things. SelectorMatches is performance-sensitive enough that I don't think we could easily add extensibility to it without noticeable overhead. I'd love to be proved wrong, of course.

4. On Tuesday 7 October 2008, 08:55 by voracity

"a more powerful CSS Object Model"

+1. This would make prototyping or backporting new CSS-dependent standards possible.

5. On Tuesday 7 October 2008, 11:02 by Neil

You've never needed to explicitly scope function calls in XUL at all, because the scope chain includes all ancestor nodes (this does slow down execution somewhat.) HTML used to work like this to, but that was fixed (sorry I forget the bug#, this was years ago.)

6. On Tuesday 7 October 2008, 15:44 by Grauw

Oh, the hate on XML technologies. :(

So often have I seen custom templating solutions when people could just have been using XSLT with hardly any syntactic overhead and native-browser performance.

7. On Tuesday 7 October 2008, 18:50 by mawrya

Thanks for the concise analysis. I'm looking forward to trying HTML5 Drag and Drop. I wouldn't miss RDF either but dumping XSLT would be enough to make me consider moving to a different platform.

8. On Tuesday 7 October 2008, 23:00 by ChrisJ

Okay to drop RDF: as far as I know, it was only a pain to product/extension developers.

But why dump XSLT? As long as no developer is obliged to use it, I don't see the point. And I'm pretty sure there are many users who rely on XSLT being available in Mozilla.

9. On Wednesday 8 October 2008, 05:44 by karl

Just as a side comment. The RDF in the way it has been put into Mozilla is 1) outdated (first version), 2) not appropriately used for what is it for.

As I always say use the right tool for the right task.