XUL:Neils Wishlist

A list of possible enhancements for XUL 2.0 or APIs that would be used by XUL applications. Some are based on features found in other UI toolkits, and some are based on questions people have had on forums, newsgroups and bug reports. The items are prioritized in the order I think they should be done. I haven't yet explained why I think they should be in this order, but in general, the priority is based on the amount of requests for a feature, how much of a problem development would be if the feature didn't exist, as well as the complexity of implementing a feature.

Note that I don't list issues with remote XUL. Current issues with remote XUL are listed on the XUL:Remove Privilege page. It is assumed that all of the items below should work in remote content as well, unless there is some valid security reason for them not to.

Priority 1

1. a XUL:Canvas Tag for customized drawing is needed.
2. templates need to log syntax errors on the JS console or elsewhere.
3. need better debugging for when applications aren't registered in the chrome registry correctly. (NeilRashbrook) For a start the chrome registry should return useful error codes for invalid or unregistered URLs.
4. templates should have a means of matching values based on substrings, greater than a value, etc.
5. better ways of doing databinding, for instance to XML, components, or JS objects.
6. a XUL:Slider Tag for volume controls. Safari RSS has this and WebForms 2.0 will have this. There already is a tag called slider though which was intended for this purpose. We should make it work. We should make it compatible with WebForms 2.0 though.
7. get the <spinbuttons> widget to work. It's missing images currently. See bug 155053.
8. editable treecells that allow editing via a textbox or a menulist. Fairly easy to implement for non-RDF trees, except for the caret being hidden when a view is above it issue.
9. need to find a way to load localization files, both DTDs and string bundles, in remote XUL. (XUL:Axel Hecht) We need a good story here. There is the story that we can't/won't do a chrome registry for remote xul, that is, no fiddling of locales into URLs. Which may actually be a wise idea. Then you need to do some serverside processing to spin the DTD url into your content, which ends up in you being able to serve the DTD inline as well. But we need to iron this out, probably with a counter proposal to actually do URL munging for remote xul. (NeilDeakin) Supporting remote localization isn't a high priority but getting widgets like dialog and wizard to work properly is.
10. there needs to be a way of parsing XUL documents and fragments. DOMParser only parses XML. (NeilRashbrook) HTML, too. Currently the best you can do is document.write() (XUL:Axel Hecht) We need to check for DOM LS, jst, what's the status with that?
11. fix all the existing XBL implemented elements so that they actually have all the methods of the interfaces they say they implement.
12. improve chrome URLs so that name collisions aren't going to occur. (XUL:Axel Hecht) proposal? Not sure what this is supposed to be. (NeilDeakin) XUL:Benjamin Smedberg proposed using namespaced package names in http://bdsmedberg.no-ip.org/chrome/
13. popups have a issues with certain content. We need to fix those.
14. fix various issues with maxsizes in xul box code.
15. make it so that XBL can be attached without using CSS. This is necessary so that properties are available right after createElement is called, rather than having to wait for the binding to be attached.

Priority 2

1. currently when one wants to filter out results that don't match a condition, an empty rule has to be used. There should be a simple way to negate results.
2. need more control over template recursion.
3. there are various targets and elements available through an event object but it seems that none of them are ever the one I want. Often they point to anonymous content. (XUL:Axel Hecht) more detail here? (NeilDeakin) For example, for focus events, the target is the anonymous HTML input rather than the XUL element.
4. get the element at a given coordinate, or set of elements.
5. get XUL elements to work well in XML documents. (NeilRashbrook) Many of the XUL helper methods are currently defined on the XUL document. (XUL:Axel Hecht) Is this part of my favorite content sink story or vice versa?

Priority 3

1. way of making panels which arrange to fit, much like a Windows icon view. This can more or less be done with display: block, assuming that this doesn't change in upcoming CSS specs, but a tag for this would be nice. XAML calls this a FlowPanel and is a key layout primitive. (XUL:Minh Nguyen) Java's AWT also has FlowLayout as the defalt layout manager.
2. in addition, an icon object that can be dragged around in its container without having to write dragging code.
3. a clipboard API or wrapper that is easier to use. Meaning, one can cut and paste common types with only one or two lines of code. (NeilRashbook) I've always wondered why the clipboard helper only copies strings to the clipboard, you can't easily get them back.
4. good drag and drop APIs, available for local and remote content.
5. a means for the application to know when the item has been dropped onto another application.
6. make sure that the Firefox toolbar customization is part of the toolkit.
7. the stack is great for some positioned content, but there is a need to be able to have an absolutely positioned item or two without the need of a container, for example so that it can be moved about on the screen. Extensions, I'd imagine, would use this quite a bit. (NeilRashbook) Cards seems to manage fine with a stack.
8. popups that can be non-rectangular or transparent, and have or not have title bars.
9. something that allows applications to cache data. Currently, we have the network cache, and xul persistence in the local store, but they aren't very configurable. Possibility a way to store XML documents or RDF data. Also, provide access to cookies within XUL. (NeilRashbook) Move document.cookie to nsIDOMDocument perhaps? (XUL:Axel Hecht) vlad is going to post something about this, just want to note that we need a good privacy/security story here, if this is supposed to be used widely.
10. a tag or collection of tags for easy web services. The <serverpost> is a good start for doing HTTP Post, which I'm including in the web services category. We need these kind of things so it is easy to send content to a remote site without having to resort to XMLHTTPRequest scripting. (XUL:Axel Hecht) I'm not very fond of the idea as is, it seems like you're moving application logic into XML markup. Programming in XML is rather rare and Webservices are a rather generic thing to me, I have no vision on how this would help. If I'm wrong, should this go through the WHATWG? (XUL:Axel Hecht) I have been thinking again. I bet we have two scenarios for webservices. One is to include the result of a soap or xmlrpc request into the document directly, the other is to generate content via the result, that is, we rather want to include webservices as XML datasources than just have them somewhere else, right? (NeilDeakin) Yes, we want to support web services as datasources for use in templates/databinding. Also, 'How do I post a form in XUL?' is a frequent question so there needs to be an easy way of doing a post. Calling SOAP and so forth takes a lot of code when it should be easy to send entered data to a remote site.
11. controls for selecting dates and times. Again see WebForms 2.0 for how we should do this.
12. panels that can be docked on the sides on the window or in some form of container. By clicking on some button, they become floating. This would be useful for floating palettes.
13. ability to capture a window or parts of a window into an image. This is useful for creating thumbnails.
14. need to get the ActiveX control to work well with XUL, for instance, allowing it to recognize components and display new dialogs. (NeilRashbook) Java with XUL too.

(XUL:Axel Hecht) Lots of the layout points look very similar and ask for some kind of non-block non-inline non-xul-box layout scheme, right?

Priority 4

1. add some functions to the listbox so that creating multi-column items is easier.
2. make creating custom tags with XBL or other technologies easy, and ensure they can be distributed easily. I'm thinking a catgeory on update.mozilla.org here. The point is a bit vague about what it means.
3. controls that only allow numeric input or other filtered input. See WebForms 2.0 for how we should do this.
4. could use an improved colorpicker too. Nvu has a better one. (NeilRashbrook) http://nrr.dnsalias.net/colours.xul is something I started work on...
5. baseline alignment doesn't seem to work right in XUL.
6. need to make the popup API a little more logical. Currently showPopup is strange and doesn't match any specs that were created.
7. sometimes there's a need to get the current mouse position without the need to have listeners. This would also be useful when the mouse isn't in a window. Similarly for finding the keyboard state of keys like shift, control, etc.
8. allow toolbars that can be placed on the side or in a single row. Might not be as necessary with good toolbar customization capability.

Priority 5

1. selecting text in a chrome window seems to be disabled regardless of -moz-user-select. We should allow this if the style is set right. Note that an inline label uses a different frame for displaying text so it might not be possible there, but I think it's necessary to have some level of selectable text. (NeilRashbrook) Note that read-only textboxes have the advantage of being accessible (modulo caret issues).
2. allow the XULSortService to be able to sort on non-RDF content, especially trees. Currently, it sorts only template built content. It would be great to allow arbitrary sorting, even if it might be slower for larger amounts of content.
3. an API to play sound. Currently there is nsISound, but it isn't very exciting. It doesn't let you stop playing sound for instance. It should allow playing from a specific location and adjusting the volume at least. Should allow applications that provide at least basic iTunes like functionality.
4. a builtin <link> tag so that links can be created. We could create a wrapper around xlink if desired. (NeilRashbrook) So what's wrong with <html:a>? Or do you just want some XBL?
5. an expander widget for hiding and showing a block of content. Firefox's Options dialog has something like this. We should reuse that and make it more generic if necessary. (NeilRashbook) DOM Inspector's XBL bindings page has something like this, although last time I looked it needed visual enhancement (see my theme again).
6. change the error '... UnnamedClass.classes ...' to 'Components.classes' so that developers at least have some idea what happened when unprivleged code tries to access XPCOM.
7. want to know more about focused windows, such as when the window is in front or behind another. Also must consider the windows of other applications. (NeilRashbrook) Chrome can enumerate windows in z-order.
8. add a crop value which crops but doesn't add the ellipsis.

Priority 6

1. translucent dragging to allow dragging icons, treerows, etc around. I think only the Mac has this currently.
2. make command updaters a bit less manual. Currently one has to include some overlays and scripts in order to update the disabled state of an item as necessary. In addition, utilityOverlay.js is in the communicator package which is used for update edit items. This should be more declarative so that common edit commands are handled automatically.
3. grids could support rowspan/colspan like html tables do. That would make some layouts easier without having to resort to various nested boxes.
4. make a specialized form of grid which looks like a spreadsheet view. Essentially, a grid with a header along the top and left edge. Also, it should allow selecting entire rows and columns. This tag might be a lot of work but many will be able to make use of it.
5. server side events. Ian desscribes a proposal for server sent events (http://ln.hixie.ch/?start=1083167110&order=-1&count=5) which allows a server to send events to the client. I think the ability for a server to add event listeners to client side events would be useful too. Perhaps not mousemove. In addition another non-Mozilla application could hook up via a socket and respond. Gnome Dashboard does something like this.
6. implement some APIs that will cut/copy/paste/drag and drop XUL elements. Especially list items and tree items. This would make it easier on application authors.
7. be able to set the Windows taskbar icon and add menu items there, or equivalents on other platforms.
8. ensure that scrolling APIs for getting and changing the scroll position in elements are available and usable in remote content. Also useful would be to have a scrollToPosition type function for textboxes.
9. need to be able to create zip files. I think zlib already includes this so there should be an API around it. This would make XUL based extension creation utilities possible.
10. a visual editor would want a way to disable default events and apply its own. Is event capturing sophisticated enough today to allow this? It will also need to disable CSS hover events and the like. (NeilRashbook) event.preventDefault() normally works, except for XBL events which currently require event.stopPropagation(); however the problem with editing forms in Composer is that we want parts of the default actions to work...
11. some graph widgets like bar graph, pie chart, etc. This could be done with SVG and XBL presumably.
12. add some styles to allow tabs to placed on the other sides on the tabbox.

Priority 7

1. when one drags in some applications, a rectangle appears where dragging making it easier to determine what will be selected. In addition, the items inside become selected. This would be a useful feature to have.
2. XUL printing at least in a limited way if it's too hard otherwise. Maybe a way for a tree to dump its content into something printable.
3. support for Mac drawers, perhaps by using a <sidebar> tag which can just be a sidebar on other platforms.
4. need a way to set the window icon without having to stick a file in a special directory. For example, an attribute on the window tag.
5. a means to configure the system window menu. On Mac, the titlebar also has an optional proxy icon which can be dragged. It usually works like the icon in the browser address field. I recall that a menu can be attached to it also.
6. scriptable access to nsIPromptService or something like it so that common simple dialogs don't have to be written from scratch.
7. have an API for passwords to be saved. Mozilla has this. Needs to be accessible without allowing the retrieval of passwords associated with other components.

Priority 8

1. probably want to have filters.
2. another Apple thing is to have certain parts of the UI unactivatible when the window is not in front, so one doesn't accidently click the Delete All button when trying to focus the window. iTunes on Windows does this but to the entire window (which is very annoying).
3. some elements, such as menuitem, require a special CSS class to be used in order for an image to appear. Someone should explain why. I don't like having classes that have some special meaning. (NeilRashbook) I did that in my theme; I had to explicitly set the list-style-image to none and the moz-image-region to auto otherwise menuitems would pick up images from their ancestors e.g. the back/forward buttons.
4. the <editor> seems to have a timing issue and requires a script to set the URL. Also the editortype attribute doesn't seem to really allow one to switch between the text and html editors. It would be nice to allow switching between source and html views, for example.
5. API to have elements roll up or down smoothly. (NeilRashbrook) And prefs to turn it off again, please.
6. MDI style container widget would be useful for some applications. I'm thinking a XUL editor here again. Not sure if MDI is a suitable UI paradigm but I'm throwing it out there.
7. overlays should have a way of adding elements like popups and keys without any accompanying element to put them in. Could also be useful to find a way to allow elements to added even if the container doesn't have an id. (NeilRashbook) Just wrap it in an element without an id e.g. <popupset><popup id="context"><menuitem/></popup></popupset>
8. be able to easily get access to the windows of an application, including remotely. For instance, an array or tree of all windows opened by the application.

Priority 9

1. access to a font picker. Windows, at least, has a font picker as a common dialog. We should provide something like this.
2. should be able to call out to an external implementation to render a tree cell's content, perhaps using something shared with the canvas tag.
3. a convenient way of creating the tiny alert boxes that appear in the corner of the screen like the new mail popup. Mozilla has this already, but we need to formalize the API and make sure it's available for use. (XUL:Minh Nguyen) How about supporting Windows' notification bubbles somehow? Apps would need to be able to specify system tray icons as well. See http://jeans.studentenweb.org/java/trayicon/ for a Java version of this.
4. need a way to hook up textbox autocomplete results to a datasource. (NeilRashbook) You mean a custom JS autocomplete datasource? I've got a demo of that (requires chrome access, sigh...)
5. tri-state checkbox that actually displays in three states and is more sane.

Priority 10

1. be able to modify images.
2. resizing handles. Editor has these for image resizing and they could be adapted for general use. Would be useful in a XUL editor for resizing UI elements.
3. a specialized button with an image and no label. Easy to emulate though, but could be useful. (NeilRashbrook) Don't the default buttons like it if you don't specify a label? What's the issue?
4. it might be useful if some all-in-one edit menu XBL (or whatever) was available so that creating an Edit menu was fairly easy. Similar for other common UI, such as the File Open, Save, Close menu items, view toolbar options, etc...
5. would be nice to not have to import the global stylesheet in every XUL file. It should just be implied, or could be modified to allow theme selection. Not too keen on that last bit, but I thought I'd add it any way.
6. overlays should support an onload attribute. Possibily even onunload or onclose.
7. some people might want to put more than one window definition in a single file, at least, small dialogs. (NeilRashbrook) Perhaps you could choose the window by the anchor on the URL? (XUL:Minh Nguyen) And you could then surround the window tags with a windowset tag.

In progress

These items are already being implemented.

1. actually make undeterminate progress meters draw properly in the Classic theme. Currently they don't since an image for it doesn't exist in the native theme. (NeilRashbrook) I have now fixed bug 226491.
2. get non-rectangular windows working on every platform and not just on some configurations of Linux. Often used for audio players, or Apple Dashboard like applications.
3. custom cursors as in CSS2 might be useful for some applications. (XUL:Minh Nguyen) This is bug 38447.

Some comments from my weblog

• (a specialized form of grid which looks like a spreadsheet view) would be very nice, but it would have to be extensible and customizable. There are many flavors of grid-like objects in fat client applications, from spreadsheets like Excel to database-centric windows like the ones in Access... it's going to be a challenge to provide a grid control that is flexible enough that developers will use it and not resort to "rolling their own". We're prototyping something right now that is horrendously complicated already, and it's not even anywhere close to being functional yet... it would be very nice to have a built-in widget that could at least give us a leg up.

• spreadsheet view. This is an awesome idea. the spreadsheet got pcs where they are today. XUL is well suited to business applications. a spreadsheet view is an extremely logical step.

• resizing handles. I can't see it being too hard to implement, but it would be a dream come true. It would make it trivial to develop graphics apps, and a xul ide. a onresize handler would be great too if there isn't one already.

• making notification popup alerts. Yes! this would be great. Also somewhat attached to this is I'd love the ability to minimise an app to the system tray area (on windows). This functionality would make it a lot more like konfabulator in that you could write small quick apps that can be accessed easily.

• floating palettes. This would be to bonus of the year! fixed palettes are so < 1995. we're a decade older!

• make xul work properly in xml is another great one.

• If I could vote (which might be an interesting concept for the moz dev team to determine what developers want), there's the top 3 from my particular business perspective:

• spreadsheet-like control (like a StringGrid in Delphi/C++ or a data grid in C#)

• • printing, absolutely!

• • extend the template-thing much, much further, beyond the concept of RDF-controlled content generation. Dynamic, editable forms with plain-XML datasources would be great - maybe a bit like InfoPath. All the basics are there, it can be done!

• • A easy way to do confirmation boxes, and other simple dialog boxes without lots of workarounds due to security restrictions would be _very_ helpful. In my last project using XUL a lot of effort was needed to workaround what would have easily been accomplished in small, simple dialog boxes on a local fat client.

• Spreadsheet-like grids and more versatile (ie editable) treecells would be very usefu

Toiletduck> A good test of functionality is we need to be able to implement an iTunes clone in XUL. I'm not talking about the backend playing(decoding) of songs but everything else. We especially need a tree where you can double (or single) click in a cell to edit the content. An event should be triggered at _least_ when you hit enter/tab. I want to make a scripting language editor. When i click on the class, I want an attributes editor like visual c/basic. when i click on the value of the attribute I should be able to edit it! at the moment there are no editboxes allowed in treeviews. Neil (www.xulplanet.com) provided a hack but it makes the cursor disappear! This is 1995 functionality. about:config would be so much nicer with this functionality. IMHO it should be in priority 1.