A validator for XUL could be a good idea. I am thinking about something more than just ‘schema’ validation. Something to help with best practices and accessibility. Maybe ‘validator’ isn’t the right word. Here are some checks that could be useful:
- Basic Structure – Stuff a schema language would check:
- Is the XML well formed?
- Are any elements unknown?
- For a given element, are any attributes unknown?
- For a given element, is it the child of a valid parent?
- For a given attribute, are the values allowed?
- Best Practices – Stuff that’s recommended for a good, localizable, skinnable and accessible UI:
- Are access keys on menus, checkboxes, radiobuttons, buttons and labels linked to controls?
- Are labels linked to controls using
- Do toolbarbuttons have labels and tooltips (even if the label is hidden)?
- Are there menu alternatives to toolbar actions (use
- Is the
context attribute used to attach context menus?
- Are radiogroups contained in a groupbox with a caption?
- Does the source declare a DTD for localization of string resources?
- Are labels, captions, accesskeys and other strings pulled from a DTD?
- Does the source import a stylesheet (exception: overlays)?
- Are toolbar, menu and button images assigned via CSS or hard coded
- Does the source avoid using inline
What else could a validator check? I pulled some of these from a good MDC article on accessibility guidelines. Localization is definitely important and MDC has guidelines and examples to help. The skinning stuff came from this skin/CSS guide.
I have most of these checks in the current version of XUL Explorer (to be released soon). I was planning a simple web version too.
Note: There is a web-based accessibility checker for XUL (and other types) at WebAIM. To test it, choose “XUL Report” for the LRAE file and pick “Form Test (XUL)” or “Browser (XUL)”, then press “Process” button. You can also supply your own XUL URL.
Update: Added localization and skinning guidelines to the list (thanks Axel)
I was a little surprised how “popular” my XUL/E post became. The demo viewer page alone has over double the hits of the second place page. In that post, I demonstrated how Mozilla’s rendering engine (Gecko) could be embedded in Internet Explorer and used to display rich XUL applications and advanced SVG and canvas graphics. Of course, XUL/E is a play on Microsoft’s brand-new-fantastic-sliced-bread WPF/E technology and Mozilla is not mounting a XUL/E initiative (but I can dare to dream).
However, the Mozilla ActiveX control is real and is a quick and easy way to embed a Mozilla web browser not only in Internet Explorer, but any development environment that supports ActiveX controls, including .NET WinForms. Adam Lock’s pages have a lot of information on the control. If you want a current build of the control, download XULRunner, as the control is distributed in that package.
In the comments of my XUL/E post, some asked about using the control as an alternative to Adobe’s SVG ActiveX control. This is certainly possible, but not ideal in it’s current form. However, some small changes could make it much more feasible. One change would be making the control a default viewer for the SVG MIME type. Doing so would allow the control to automatically display SVG whenever IE navigated (directly or by
<A> link) to an SVG resource.
I already have a patch to do that exact thing for the XUL MIME type.
Even though Firefox 3 is only in early alpha, you can still see a list of new features available to web and extension developers. The list will be updated as development continues.
Jesse Ruderman also has a nice changelog with links to bugzilla, for those of you that want all the details.
A few common questions seem to be asked a lot, especially by developers new to the Mozilla platform. So, I wanted to draw attention to some relevant articles on the Mozilla Developers Center (MDC).
- How do I get access to the browser? If your writing an extension for Firefox, there is a good chance you want access to the browser. You might want to add tabs, get the selected text in the current tab or whatever. This tabbrowser code snippet article has enough information to get you started.
- How can I debug problems in my code? It can be really frustrating when you seem to have everything put together right, but nothing appears to be working. This extension FAQ article can help you debug some common problems.
- How can I be notified when ‘X’ happens? Web developers are familiar with the concept of ‘events’. It is common to use events to be notified when a web page loads or when a keypress occurs on an input. The same is true when developing extensions and other chrome-based code in Mozilla. The UI is made up of XUL, which is very similar to what you know of DHTML. Here is a list of XUL events and a helpful XUL reference with information about the various kinds of elements you’ll come across.
CÃ©dric Savarese has a demo of using XUL to make a richer HTML form. CÃ©dric’s approach is different than my XUL-in-Internet Explorer idea. His method only uses XUL in a XUL-enabled browser (Firefox, SeaMonkey or Netscape). In other browsers, it falls back to DHTML elements.
One of the neat things about his approach is that it showcases how Mozilla-based browsers can create rich web interfaces without any extra plugins.
Removing obstacles for extension developers is my group’s primary task at Mozilla. There are lots of ways we can do this and areas include documentation, tutorials, samples and tools. One thing that becomes clear after watching and helping extension developers is the difficulty some have getting familiar with the Mozilla framework and the plethora of object and interfaces available. Not only are some of the concepts foreign, but in many cases there are no clear ways for extension developers to achieve their goals. There are places to get help. The Mozilla’s IRC channels are a great place to ask questions, especially #extdev.
- Make it easy for developers to do common extension tasks.
- Hide as many implementation details as possible.
- Allow developers to get access to underlying XPCOM interfaces if they want to.
- Act as a buffer between extensions and Firefox internals.
In addition to making it easier for extension developers, we also want to help improve the overall quality of Firefox. A broken extension appears to be a broken Firefox. Anything that can be done to help extensions avoid breakage and use clearly defined methods of hooking into the browser will help.
I invite you to take a look at the FUEL wiki pages and send us feedback and comments. You can use the discussion pages on the wiki or visit IRC (we hang out there way to much) or even use the newsgroup thread.
Update: I forgot to mention that our goal is to ship this library with Firefox (and other Mozilla applications as needed). Of course, we would also want it be able to usable in older Firefox releases too. Packaging could be a challenge.
Here are some XUL clippings that show different uses of the
<canvas> element. The purpose of this post is not to show off uses of
<canvas>, but to point out that it can be used in XUL (Firefox extensions and XULRunner applications) very easily.
I also updated the XUL/E (XUL in IE) post to include some of these samples as well. That’s right, you can use
<canvas> in IE using the Mozilla ActiveX control discussed in the post.
Note: These are simply XUL files and if you’re using Firefox (or another XUL enabled browser), clicking the links will open the files in the browser instead of downloading to your machine. Right-click on the links and pick “Save Link As…” to save them to your machine.