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 another 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.
|Templates need to log syntax errors on the JS console or elsewhere.
Templates should have a means of matching values based on substrings, greater than a value, etc. |1.9
Better ways of doing databinding, for instance to XML, components, or JS objects. |1.9
A slider tag (scale) for volume controls. Safari RSS has this and WebForms 2.0 will have this. We should make it work. |1.9
|Fix all the existing XBL implemented elements so that they actually have all the methods of the interfaces they say they implement.
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. |1.9
|Allow the toolkit bindings to have extra privileges in some way such that native calls and dtd handling will work when the elements are used in remote XUL. (AxelHecht) 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.
|There needs to be a way of parsing XUL documents and fragments. DOMParser only parses XML. (NeilRashbrook) HTML parsing, too. Currently the best you can do is document.write() (AxelHecht) Actually DOMParser works just fine with XUL as does XMLSerializer. I use this functionality all the time to manipulate fragements of XUL (dcradler). We need to check for DOM LS, jst, what's the status with that?
|Improve chrome URLs so that name collisions aren't going to occur. (AxelHecht) proposal? Not sure what this is supposed to be. (NeilDeakin) BenjaminSmedberg proposed using namespaced package names in http://bdsmedberg.no-ip.org:8080/chrome/
Popups have a issues with certain content. We need to fix those. |1.9
|Specify the XUL box model and then make sure it is implemented that way
|Make it so that XBL can be attached without using CSS. Or, just make it so that XBL is available right a binding is applied.
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. |1.9
|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. (AxelHecht) more detail here? (NeilDeakin) For example, for focus events, the target is the anonymous HTML input rather than the XUL element. (NeilRashbrook) This is because the focus event doesn't bubble so the onfocus handler has to be inherited onto the anonymous HTML input.
get the element at a given coordinate, or set of elements. Use elementFromPoint. |
|get XUL elements to work well in XML documents. (NeilRashbrook) Many of the XUL helper methods are currently defined on the XUL document. (AxelHecht) Is this part of my favorite content sink story or vice versa?
need to make the popup API a little more logical. Currently showPopup is strange and doesn't match any specs that were created. |1.9
elements that only allow numeric input or other filtered input. |1.9
|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. (MinhNguyen) Java's AWT also has FlowLayout as the defalt layout manager.
|in addition, an icon object that can be dragged around in its container without having to write dragging code. (NeilRashbrook) Or at least the ability to capture the mouse while it's pseudo-dragging, so that all events get targetted at a specific element, avoiding hacks like listening for mouseup on the window element and hoping the mouse isn't released outside of the window.
|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.
|good drag and drop APIs, available for local and remote content.
|a means for the application to know when the item has been dropped onto another application.
a means to know when a drag is cancelled. This is needed to tear down drop markers inserted into a document. Currently, you need to set up a timer and check for the continued existance of the drag session. |1.9?
|Transfer Data 356295
translucent dragging to allow dragging icons, treerows, etc around. |1.9
|Transfer Data 279703
make sure that the Firefox toolbar customization is part of the toolkit. |?
|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, although there's a hack to prevent the stack from expanding when items are dragged down or to the right.
popups that can be non-rectangular or transparent, and have or not have title bars. |
|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? (AxelHecht) 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.
elements for selecting dates and times. |1.9
|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.
|ability to capture a window or parts of a window into an image. This is useful for creating thumbnails. (ChrisThomas) Is roc's drawWindow the solution to this?
|ensure that a retrieving and modifying the scroll position of the content of any element is available. Also useful would be to have a scrollToPosition type function for textboxes.
|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? (Nickolay) there's <xul:label class="text-link" href="http://google.com" value="google!"/>, it just needs to be fixed to work with tabs (bug 263433).
get non-rectangular windows working on Mac. Often used for audio players, or Apple Dashboard like applications.
make richlistbox multi-selectable (XUL:Richlistbox and bug 298371) and implement FAYT for it (bug 298993) (zeniko)
- A CanvasTag for customized drawing is needed. The HTML canvas is available so this pretty much done. (Enn) I still think a non-retained version would be useful though.
- 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.
- could use an improved colorpicker too. Nvu has a better one. (NeilRashbrook) http://nrr.dnsalias.net/colours.xul is something I started work on...
- baseline alignment doesn't seem to work right in XUL.
- 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.
- allow toolbars that can be placed on the side or in a single row. Might not be as necessary with good toolbar customization capability.
- 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).
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. (NeilRashbrook) How would you specify the sort value and datatype? (Bug 335122)
- 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. (AxelHecht) 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? (AxelHecht) 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.
- 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.
- 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).
- 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.
- 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.
- add a crop value which crops but doesn't add the ellipsis. (NeilRashbrook) style="overflow: crop;"
- 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.
- grids could support rowspan/colspan like html tables do. That would make some layouts easier without having to resort to various nested boxes.
- 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.
- server side events. WHATWG describes a proposal for server sent events (http://whatwg.org/specs/web-apps/current-work/#server-sent) 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.
- 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.
- be able to set the Windows taskbar icon and add menu items there, or equivalents on other platforms.
- 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.
- 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...
- some graph widgets like bar graph, pie chart, etc. This could be done with SVG and XBL presumably.
- add some styles to allow tabs to placed on the other sides on the tabbox.
- need more control over template recursion. Recursion can now be disabled.
- 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. (AxelHecht) Lots of the layout points look very similar and ask for some kind of non-block non-inline non-xul-box layout scheme, right?
- 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.
- 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.
- support for Mac drawers, perhaps by using a <sidebar> tag which can just be a sidebar on other platforms.
- 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.
- 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.
- scriptable access to nsIPromptService or something like it so that common simple dialogs don't have to be written from scratch.
- 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.
- probably want to have filters.
- 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).
- 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.
- 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.
- API to have elements roll up or down smoothly. (NeilRashbrook) And prefs to turn it off again, please.
- 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.
- 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>
- 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.
- access to a font picker. Windows, at least, has a font picker as a common dialog. We should provide something like this.
- 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.
- 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. (MinhNguyen) 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.
- 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...)
- tri-state checkbox that actually displays in three states and is more sane.
- be able to modify images.
- 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.
- 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?
- 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...
- 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.
- overlays should support an onload attribute. Possibily even onunload or onclose. (NeilRashbrook) What's wrong with addEventListener?
- 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? (MinhNguyen) And you could then surround the window tags with a windowset tag.