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
controlattribute? - Do toolbarbuttons have labels and tooltips (even if the label is hidden)?
- Are there menu alternatives to toolbar actions (use
keysetandcommandset)? - Is the
contextattribute 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
imageattributes? - Does the source avoid using inline
style?
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)
Maybe you could use the name “lint” for it? I think it would be a great tool. I haven’t started to tackle XUL but I’ve been watching your blog because it’s a great resource for when I finally get around tuit.
There is a whole slew of things to make your XUL localizable right, too. http://developer.mozilla.org/en/docs/Writing_localizable_code has at least some, I just saw that it misses out on the golden rule to name label entities .label and accesskeys .accesskey together with the same prefix. The translate toolkit needs that. Then there’s the talk that dynamis gave at the summit, mentioning issues like “don’t concat different strings with spaces” or “don’t put a plaintext ‘.’ in your xul”.
Another big point would be RTL, when designing a XUL interface, you want to take good care that your stuff works if you change layout to RTL. Not sure what that means in concrete guidelines, though, and if a tool could check that.
Axel-
Thanks, I totally missed localization and skinning. Updating…
Mark, let’s talk in some detail. I have an interface in my Verbosio application for validating XML documents in a given language such as XUL. Soon, I’ll need help writing actual code for validation, so this could prove very useful.
great idea, go for it!
Maybe it’s useful to look into the new modular validator framework of the W3C.
I once started a ‘beyond validation’ SVG checker, but still have to improve that into a generally usable state.