Open standards cannot effectively compete with Microsoft XAML and other closed technologies for large market share without a good set of developer tools that make authoring and developing easy (or at least easier). Visual Basic 5-6 were limited and inefficient programming platforms, but were wildly popular simply because developers could drag/drop/insert UI and it would just work. Microsoft Access data applications have much the same appeal. If XUL is to compete with these closed technologies, it needs to have a good GUI editor. The mozilla2.0 team is acutely aware of the problem, but nobody has yet stepped forward to lead the charge.
I spoke briefly with Daniel Glazman about possible UI ideas for a GUI XUL editor, and how it might relate to the fantastic work that he is doing on NVU, the next-generation HTML editor. After a little bit of playing, it is obvious that the editing model for XUL would have to be very different from HTML.
One of the primary factors involves the selection model. In HTML, you select text in a mostly-linear fashion to edit it. Even floats and other out-of-line objects have their own little “flow”. This is simply not the case for XUL, where you must think in terms of boxes and flex, fitting to the available/desired space. In XUL editing, your “cursor” may be vertical or horizontal, and has a limited scope in the current containing box. Once you escape the immediate containing box, your cursor switches orientation from horizontal to vertical (and vice-versa).
I did a basic playground stylesheet with a simple XUL file, and created a special element <edit:cursor> which would act as a “heavy” cursor. What I want to do is steal large parts of DOM inspector code, so that there is a tree sidebar which matches the GUI view.
I found a few places where I need/would really love additions to core gecko… somebody please tell me how hard these are:
1) parse entity names with a special DOM element, instead of expanding them to text. This is pretty much a requirement to do large-scale apps that localize appropriately using the chrome registry
2) a :-top-hover selector. I need a selector that only matches the topmost hovered element, not every hovered element.
3) a -moz-min-margin rule… I can work around this if necessary, but in order to give space between boxes for drag-n-drop and other activities, I would like a -moz-min-margin: 4px rule applied to *.
Did I just volunteer for something? I hope not ;)