Why Firefox’s new numbering is a problem

Mozilla recently released Firefox 5, (quietly) announcing that this represented the end of life (EOL) for Firefox 4. The problem is that Firefox 4 was released less than a two months ago.

This has led to an ongoing discussion about the effects that the new release schedule is having on corporate users – first from Daniel Glazman then from Mike Kaply. The storm of comments that has arisen resulted in both of them writing several follow-up posts, so if you’re interested in this topic do continue further into their blogs and comments (especially Mike’s site, as that seems to have been the target of more comments).

One of the most common responses I’ve seen is that Firefox 5 only adds a few relatively minor features, so it’s just like a 4.1 update really. But it’s the fact that it only contains minor changes which is a big part of the problem.

With a 4.1, 4.2 numbering system it’s usually a fair bet that the changes between versions are small. Jump to 5.0 and you would expect some more major changes, possibly affecting the UI in a way that will need you to retrain your staff. But when every version bump might only contain small changes, or might have massive changes it’s very difficult to plan ahead. And when there’s no distinction between a security release and one that adds significant UI changes, corporations have to treat every release as a major one.

If Mozilla really want to carry on with six-weekly releases then that’s up to them – but at least provide occasional islands of stability that will see security updates for (say) 18 months. Not everyone wants to live in the constant churn of the upgrade cycle – and that includes some ordinary users as well as corporations. For these people an annual “blessed” release would be a blessed relief!

Posted in Tech, Web, XUL. No Comments »

Mozilla Add-ons workshop, London 2010

Last night I went to the free Add-ons workshop that Mozilla hosted in London. It was an informative and interesting evening – well worth the trek down to London, even if it did then lead to a late-night trek back again.

Particular highlights of the evening were:

  • Myk Melez demonstrating that he’s a braver man that I am as he coded a small Jetpack extension as we watched – and it worked first time!
  • Tobias Leingruber’s wonderful presentation about his artzilla.org website and the creation of Firefox extensions as artistic works. Easily the funniest presentation of the evening.
  • Paul Rouget’s amazing demos. His French accent was a little thick at times – especially when he got excited. But the fact that he did get excited is telling in itself. Keep an eye on hacks.mozilla.org, especially as we get closer to the release of Firefox 4, as I’m sure most of his demos will appear there at some point.

There was also a stand with some free Firefox merchandise – mostly badges, pens and lanyards – but I did pick up a sheet of Foxkeh stickers for my girlfriend who is a big fan of the cute character, and uses the Foxkeh monthly desktop backgrounds on her computer (you might want to read this if you’re an English rather than Japanese speaker):

I’ve often wondered why the EU and US arms of Mozilla don’t make more use of Foxkeh in their marketing. He gets commented on by a lot of people that see my girlfriend’s desktop, which inevitably leads to conversations about what Firefox is, and how it differs from Internet Explorer. A mascot that leads to spontaneous discussions like this is surely something that should be used more widely.

Update: Chris Heilmann’s blog covers this event in more detail, and includes some videos of Paul Rouget’s demos.

Although many aspects of these demos will only become available in Firefox 4 (or nighties and pre-release versions thereof), it’s worth noting that SVG clipping, masking and filtering of HTML (including Ogg Theora video) works right now in Firefox 3.5, as demonstrated by my own post on using Inkscape filters in Firefox.

Posted in Tech, Web, XUL. No Comments »

Focus in XBL handlers in Firefox 3.6

Most people can safely ignore this post for fear of melting your brains. It’s only here to help people who stumble across the same problem I did, and go googling for the terms I’ve put in the post title.

For a while now Gecko has supported a non-standard CSS extension called “-moz-user-focus“. The main use of this (at least in my code) seemed to be to prevent particular XUL elements from being focusable by setting it to “ignore”.

When I recently upgraded to Firefox 3.6 I found that the focus handler in my XBL widgets was no longer getting called – with the result that I couldn’t even focus them using $(“objectName”).focus() in Firebug. It would appear that the default state for XBL-bound elements has changed from focusable to non-focusable.

The fix for this is simply to add “-moz-user-focus: normal” to the CSS styling of your XBL-bound element. It works whether added directly to a style attribute or in a referenced CSS file. With this in place my focus handler now fires as it used to, and the software works as expected once again.

Posted in Tech, XUL. No Comments »

Removing the mystery lines on a XUL checkbox

XUL has a checkbox widget, which you are expected to use like this:


<checkbox label="Account Locked" />

That will give you a perfectly functional checkbox with a label to the right of it (add dir=”rtl” if you want the label to the left of the checkbox). The image below shows how they appear on my Linux machine – the top part is an unselected checkbox, whereas the lower one has been clicked on, which has the effect of both checking the checkbox and focussing the widget:

Standard XUL checkboxes

It’s the focussing that’s the important bit here – notice how the label gets surrounded by a dotted border. A similar effect is used on a Windows machine, and is generally “a good thing” as it makes it clear which widget will be affected by keyboard presses (such as using the space bar to toggle the checkbox state).

Sometimes, however, the presence of this focus border is not “a good thing”, and can in fact become “a confusing thing”. Consider a user interface which has labels and widgets all neatly aligned using a XUL grid. In that case you might not want to have a label directly on the checkbox element at all, in which case you can find that a focussed checkbox takes on a most disconcerting appearance:

checkbox_no_label_1

The focus border is still being drawn around the non-existent label text. In this case it’s made worse by the checkbox being the second item in the row of a XUL grid with two columns. Because the field in the row below is much wider than the checkbox, the non-existent label flexes to fill the space, making an already odd looking widget seem even weirder. Incidentally, the field below is an XBL widget of my own devising, which is why it doesn’t look like a normal XUL textbox.

Putting the checkbox inside a XUL hbox element has the effect of curtailing its flexing habits, so that the focus border, while still present, is a little less offensive:

checkbox_no_label_2

But wouldn’t it be better to get rid of the focus border altogether? A little digging with the DOM inspector revealed that the checkbox label is being targetted with the following CSS selectors – the first on my Linux installation, and the second on Windows XP:


checkbox:focus > .checkbox-label-center-box > .checkbox-label-box

checkbox:focus > .checkbox-label-box

It’s possible to hit both of these by losing the immediate child selector (the “>”) and the “checkbox-label-center-box” class, so that the rule matches any descendent of a focussed checkbox which has a class of “checkbox-label-box”. A blunt approach would be to just disable the focus border altogether, by adding this to your CSS file:


checkbox:focus .checkbox-label-box
{
-moz-appearance: none;
border: none;
}

That does disable the focus border, but it disables it completely – even if the checkbox is used in a situation where it does have a label. Thankfully Firefox’s CSS engine is rich enough to let us use the [label] selector, to match elements which have the “label” attribute, as well as the :not() pseudo-class to negate the match. The result is this chunk of CSS, which will disable the focus border on checkboxes which don’t have a “label” attribute, but leave it untouched on those that do:


checkbox:focus:not([label]) .checkbox-label-box
{
-moz-appearance: none;
border: none;
}

Of course the proof of the pudding is in the slightly doctored screenshot (only doctored in that I pasted two together). In this you can see that the top row contains a checkbox with no label, and no focus border, and the bottom row contains a checkbox with a label which gets the default focus border that we all know and tolerate:

checkboxes_modified

Posted in Tech, XUL. 2 Comments »

XUL Developer Wanted (UK)

The company I work for is looking for another XUL developer to work on remote XUL front-end code. The job posting is copied below, if anyone’s interested in applying:

We are looking to employ a XUL developer to work on our next generation of laboratory management software. This class of software is used to track samples and record results in all manner of laboratory environments, and as such it also deals with managing lab instruments, generating certificates, basic statistical analysis of results, and so on.

The position is based in the heart of the UK countryside, on the Bucks/Oxon border. Developers preferring to work from home are welcome to apply, but we have a strong preference for someone to work in the office on a daily basis.

The front-end software is written using remote XUL in order to allow for centralised management by our customers’ IT departments. The back-end code is written in C# and connects to SQLServer or Oracle databases, using IIS as the web server. This position is for a front-end developer.

The ideal candidate will posses the following skills:

* Experience in writing front-end XUL. Ideally with experience in XBL, templates and overlays.
* Strong Javascript skills.
* Familiarity with other web technologies, including SVG and Canvas.
* Strong HTML skills

In addition, the following skills would be useful:

* C#
* SQL
* Gecko/Firefox development
* Extension development

PLEASE NOTE: This software is NOT Open Source. This is a proprietary product, built using XUL as a framework.

Applications should in the first part be made via email to [email protected] including a description of any relevant experience. Short-listed applicants will then be asked for a full CV, references, and examples of previous work.

Posted in Tech, XUL. No Comments »

Where are the Firefox GPS add-ons?

Firefox 3.5 has been out for a few weeks now, and amongst all the exciting new features is an API for geolocation.

In theory this means that a website can ask the browser where you are, and you then get prompted as to whether or not to let the site know. Of course that raises the question of how the browser knows where you are in the first place.

Firefox uses “geolocation providers” – small bits of software that can provide geolocation information to Firefox, so that Firefox can provide it to the website. By default Firefox ships with a geolocation provider which makes an educated guess about your location based on the wifi hotspots in the area – assuming your computer has a wireless card. This works reasonably well for a wifi-enabled laptop, but it’s far from GPS-level accuracy, and doesn’t help if you’re on a machine with no wifi card at all (in which case it bases its location information on your IP address – which puts my desktop machine about 100 miles away from its real location!).

So what can you do if wifi-based location just isn’t suitable for you? In theory it’s possible to use different geolocation providers which source their data from different places. On “Fennec”, the mobile browser based on Firefox, there’s a provider for the built-in GPS of the Nokia web tablets. But there doesn’t seem to be an add-on to let the normal version of Firefox get that same information.

There is an extension that lets you put in a fixed latitude and longitude, which is fine for a desktop machine – but that hasn’t been updated to work with the release versions of Firefox 3.5. Most GPS units connect to a PC using fairly standard and well-known serial protocols running over a Bluetooth or USB connection – yet I can’t find any add-ons which will allow Firefox to access those data.

I hope that either I’ve just missed them in my searches – or that suitable geolocation providers are coming soon – because it would be a real shame to see the potential for geolocation in the browser get ignored for want of such a little bit of code.

There’s more about the geolocation feature at the Mozilla Hacks site, and based on the comments there, I’m not the only one wondering where the GPS integration is.

Searching in a XUL tree – the XML version

Today on Planet Mozilla I came across this post by Daniel Glazman searching a tree generated from a SQLite template. This reminded me a lot of a similar trick that I play in our XUL code for searching a tree generated from an XML template.

Mirroring Daniel’s code, let’s create a tree first of all:

 
<tree seltype="multiple"
        id="myTodoListTree"
        enableColumnDrag="true"
        draggable="true"
        datasources="http://example.com/path/to/file.xml"
        ref="*"
        querytype="xml">
      <treecols>
        <treecol id="cText" label="Text" flex="1" persist="width ordinal"/>
        <splitter class="tree-splitter" persist="ordinal"/>
        <treecol id="cAssignee" label="Assignee" flex="1" persist="width ordinal"/>
        <splitter class="tree-splitter" persist="ordinal"/>
        <treecol id="cImportance" label="Importance" flex="1" persist="width ordinal"/>
      </treecols>
      <template>
        <query expr="*">
           <assign anonid="fulltext" var="?FULLTEXT" expr="concat(@text,@assignee,@importance)" />
        </query>
        <rule>
          <conditions>
            <where id="filter" subject="?FULLTEXT" rel="contains" value="" ignorecase="true" />
          </conditions>
          <action>
            <treechildren id="myTodoListTreeChildren">
              <treeitem uri="?">
                <treerow>
                  <treecell label="?text"/>
                  <treecell label="?assignee"/>
                  <treecell label="?importance"/>
                </treerow>
              </treeitem>
            </treechildren>
          </action>
        </rule>
      </template>
  </tree>

This template assumes that the XML datasource looks something like this:

<todoitems>
  <todo text="Buy some milk" assignee="Bob" importance="High" />
  <todo text="Feed the dog" assignee="Alice" importance="High" />
  <todo text="Feed the fish" assignee="Alice" importance="Medium" />
  <todo text="Feed the kids (halibut)" assignee="Bob" importance="Very Low" />
  <todo text="Feed Bob" assignee="Alice" importance="Very Low" />
  <todo text="Bob for apples" assignee="Alice" importance="High" />
</todoitems>

Now we can add a search field, just like Daniel’s:

<textbox type="search" oncommand="SearchKeyword(this)"/>

And the SearchKeyword function looks like this:

function SearchKeyword(oElem)
{
  var filter = document.getElementById("filter");
  filter.setAttribute("value", oElem.value);

  document.getElementById("myTodoListTree").builder.rebuild();
}

So what’s going on here? First of all, it’s worth noting that there’s a distinct difference between my code and Daniel’s – and not just in the switch from a SQL template to an XML template. His code changes the SQL query to only select results where the search term is found in one of the fields, but I can’t change the content of my XML file, so my code filters the displayed results instead. In other words his approach reduces the number of rows of data that are passed to the template, whereas mine passes the same amount of data to the template, then reduces the number of rows that are actually displayed.

This leads to a distinct difference in operation between these approaches. Daneil’s looks for the search term in each piece of data separately, whereas mine concatenates all the data for each row, then looks for the search term within this concatenated string. This can lead to some surprising results: if you search for “hal” you would expect the “Feed the kids (halibut)” entry to appear, but might be a bit put out to find “Feed the fish” also appearing. The reason for this becomes clearer if we look at the concatenated string that is searched (emphasis added for clarity):

Feed the fishAliceMedium

There are a couple of ways to deal with this issue – either by avoiding it altogether, or by turning it into a feature. To avoid the problem you could add multiple rules to the template, each with a different <where> element, effecively OR-ing them together. This is a lot of extra work, especially as the number of parameters grows.

The alternative approach is to separate the parameters by a character that’s not likely to appear in searches. For example, using the “~” as a separator, the XUL <assign> element would look something like this:

<assign anonid="fulltext" var="?FULLTEXT" expr="concat('~',@text,'~',@assignee,'~',@importance,'~')" />

The concatenated string now looks like this:

~Feed the fish~Alice~Medium~

Now the search term “hal” no longer appears. You’ll notice that I’ve added a tilde at the start and end of the concatenation as well. This isn’t strictly needed just for breaking up the search terms, but remember that I said I was going to turn this problem into a feature; now it’s possible to intentionally use a tilde to “anchor” a search. Look at these search terms:

  • “bob” – Searches for “bob” anywhere in any of the parameters
  • “~bob” – Searches for “bob” but only at the start of a parameter. Matches results where “Bob” is the assignee, and matches “Bob for apples”, but doesn’t match “Feed Bob”
  • “bob~” – Searches for bob at the end of a parameter. Matches results where “Bob” is the assignee, and matches “Feed Bob”, but doesn’t match “Bob for apples”
  • “~bob~” – Searches for a parameter that contains nothing but “bob”. Matches results where “Bob” is the assignee, but doesn’t match “Feed Bob” or “Bob for apples”

Finally let me share one more trick with you – the use of the “multiple” attribute on the <where> element:

<where id="filter" subject="?FULLTEXT" rel="contains" value="" ignorecase="true" multiple="true" />

This addition allows multiple comma-separated search strings to be combined as if using an OR operator. So searching for “~bob~,fish” would find all the tasks assigned to Bob, plus the “Feed the fish” task. Obviously this won’t work properly for search terms that contain a comma, so it’s not suited to every circumstance.

In our applications we often use multiple search boxes (usually three) where the user might want to perform some complex filtering. Each search box is tied to a separate <where> element, all of which have the “multiple” attribute set. The effect is that comma separated search terms in each box are combined as an OR operation, but the separate boxes are combined as an AND operation. This makes it easy to construct complex combinations of AND and OR whilst keeping a simple UI – just three search boxes.

For most users it’s intuitive to type a filter term into one box, then further restrict the results by typing into the second or third box. This means that we’re able to use the same UI for both novice and advanced users, without the former feeling overwhelmed.

Posted in Tech, XUL. 2 Comments »

XBL

XBL – a dubious abbreviation for eXtensible Binding Language – is perhaps the most important part of the XUL platform that we use, other than XUL itself.

XBL is a mechanism for encapsulating a XUL UI and javascript code into a composite widget that can be used in an application as though it was any other XUL element. In other words XBL lets us create XUL widgets of our own devising.

This is an invaluable asset because it allows our framework to hide a great deal of complexity inside these XBL widgets, whilst providing a simple interface to our application developers. When one of our developers uses a <tfs_passwordbox /> element in a page, they don’t need to know that, within the XBL, that apparently simple widget is actually constructed of half a dozen XUL elements (buttons, textboxes and images), together with a few hundred lines of code. They don’t need to know that it automatically connects to the database to retrieve the site’s password rules governing length and complexity. They don’t need to know about the other connection to the database it makes in order to get a list of words that aren’t allowed to be used in a password (typically the username and company name, at least).

All the developer has to do is to type <tfs_passwordbox /> into their code, and they get all that complexity for free.

Or how about our “lookup box” element – perhaps the most commonly used element amongst our applications. In its simplest incarnation the developer just has to type <tfs_lookupbox /> to get a widget looking like this:
A "lookup box" XBL widget

The “lookup box” is so called because it can be used to look-up data in the database. When the user double-clicks on it, or clicks on the button at the left edge of the box, they will be presented with a popup dialogue like this:

A "lookup box" which has been opened

The columns are automatically generated, based on the database table that the application is pointing to. The search field lets the user perform a free-text search within all of the data in the popup – or they can use the button at the left of the search field to restrict the search to a particular column. The columns can be sorted, rearranged, hidden and revealed. An entry from the database can be selected by double-clicking on a row, or by highlighting the row then clicking the “select” button.

The developer gets all of this functionality for free, just by using a <tfs_lookupbox /> widget in their page.

Of course not every application – or even every field in a single application – is the same. Sometimes a field has to be read-only, or must force the user to type something in, or force them not to type something, or show a different set of columns than the default, or get the data from a different table than the one the rest of the application uses. Thankfully our XBL-defined widgets can include attributes, just like any other XUL widget, which can then be accessed from within the XBL definition in order to modify the appearance or operation of the widget. So when our developer needs a field to be read-only, they just have to use <tfs_lookupbox readonly=”true” /> to get a widget like this:

A read-only "lookup box"

There’s a lot more that can be done with XBL – a lot more that is done within our framework in order to make an application that it both powerful for the user, and simple for the developer. And when we have a great idea to improve our widgets (or just when a bug gets fixed), a change to the XBL means that the change automatically applies to every widget in every application, with no need for the developer to go around trying to find and change them individually.

You may have noticed that this post has been a glowing recommendation of XBL, but with a distinct lack of real sample code. That’s quite deliberate – XBL is a big enough subject that any post of mine wouldn’t do it justice. The full details can be found across several pages of the XUL tutorial on Devmo. Suffice to say that XBL is such a powerful and flexible tool that the W3C has started to ratify a new version of it (of course, given the speed at which the W3C usually works, it might become a recommendation by about 2020, and then actually appear in more browsers than Firefox by 2030). Still, I live in hope that one day I will be able to use XBL with HTML content across various browsers – maybe then HTML will finally be powerful enough to displace XUL for our framework.

Posted in Tech, XUL. No Comments »

XUL Overlays

In short, overlays are a mechanism by which one XUL file can be inserted into another XUL file, in a controlled manner. That last bit is the key: “in a controlled manner”.

There are lots of ways to insert one file into another – we do it all the time when we inject our DTD file into the top of a XUL file at the web server. Usually, however, such insertions are “dumb” – the whole file is inserted in one big chunk, and there’s no easy way to distribute it throughout the host file.

For inserting a DTD file into the top of a page, dumb insertion is good enough. But what happens when you want to add new elements to the user interface of your application? You might need a new entry in one menu, another entry in the Help menu, a button here, a field there and a handful of labels all over the page. Dumb insertion isn’t any good when you actually want different parts of your file to target different parts of the host file.

XUL overlays get round this problem by letting you anchor the inserted elements using the ID of their parent. An example will make things clearer. Let’s start with our host file, part of which looks like this:



<menubar id="menubar-main">
 <menu label="File" id="menu-file">
  <menupopup id="menupopup-file">
   <menuitem label="Quit" oncommand="quit();" />
  </menupopup>
 </menu>
</menubar>


That’s a lovely generic menubar, the likes of which you might expect to find in any application. But suppose we also want to add some menu entries that are specific to this application – in this case a “File=>New Widget” entry and a “Help=>About Widgets” entry (noting that we don’t currently have a Help menu at all). All we need is an overlay file – which looks pretty much like a normal XUL file – which specifies where these new elements will go, relative to their parents:



<menubar id="menubar-main">
 <menu label="Help" id="menu-help">
  <menupopup id="menupopup-help">
   <menuitem label="About Widgets" oncommand="about();" />
  </menupopup>
 </menu>
</menubar>

<menupopup id="menupopup-file">
 <menuitem label="New Widget" oncommand="new_widget();" position="1" />
 <menuseparator position="2" />
</menupopup>


(sorry about the rubbish formatting – despite having a “code” tag, it seems that WordPress (with this theme, at least) doesn’t actually like showing code!)

Notice that our Help menu and its descendants are anchored within the parent menubar, by virtue of that menubar having the same ID as the menubar in our host XUL file. Notice also that the New Widget menuitem, and the menuseparator that follows it, are anchored within the File menupopup, again by virtue of the parent’s ID. The result of applying this overlay file to the original XUL host is a structure that looks something like this:



<menubar id="menubar-main">
 <menu label="File" id="menu-file">
  <menupopup id="menupopup-file">
   <menuitem label="New Widget" oncommand="new_widget();" />
   <menuseparator />
   <menuitem label="Quit" oncommand="quit();" />
  </menupopup>
 </menu>
 <menu label="Help" id="menu-help">
  <menupopup id="menupopup-help">
   <menuitem label="About Widgets" oncommand="about();" />
  </menupopup>
 </menu>
</menubar>


The browser renders the user interface as though it had been supplied in that composite format – so it shows a Help menu and the new entries in the File menu. The menuitem and menuseparator are placed before the “Quit” option due to the “position” attributes in the overlay file. It’s also possible to use “insertbefore” or “insertafter” attributes to locate the elements relative to an existing element, rather than at an absolute position amongst the parent node’s children. It’s even possible to use a “removeelement” attribute, which allows the content of an overlay file to remove elements from the final XUL document, even when those elements were originally present in the host file.

The example I’ve shown demonstrates how an overlay can be used to add special elements to a default bit of XUL code. In our framework they are most commonly used the other way round – we have a file that contains our standard UI elements (such as a “Help” menu and “File=>Log Out” menuitem) which is overlaid onto the individual application-specific XUL pages. This means that all of our applications have some common UI elements, without the individual developers having to do anything.

In our ASP.Net code – while we’re adding links to scripts, stylesheets, and our default overlay – we also check to see if there’s a page-specific overlay file for the current application. If there is, we insert a link to it at the top of the page. This means that we can maintain a standard version of each application, but if a particular customer needs it to be changed (fields removed, buttons added, and so on), we can often make those customisations in the page-specific overlay file. This makes it easier to upgrade the customer’s code in future, since the basic core files remain untouched.

As with most XUL topics, there’s far more detail (and far better examples) in the XUL Tutorial on Devmo.

Posted in Tech, XUL. No Comments »

Serving all the other files

Back to this diagram:

XUL framework block diagram

XUL framework block diagram

I’ve spent a couple of posts discussing the complexities of the DTD files. Thankfully the rest of the diagram is fairly easy to explain.

A user requests a XUL file from the server – initially this will be our login page. The ASP code on the server inserts some standard headers into the XUL page, referencing stylesheets, XUL overlays and javascript files. The relevant DTD file is injected directly into the page, as previously explained.

The browser now starts to process the XUL file it has received – much like it does with a web page. It requests any referenced files – the stylesheets, scripts and overlays – directly from the web server. Stylesheets and scripts are served directly, hence the arrow between Firefox and “other files”. Requests for overlays are intercepted, as these also have to have the DTD file injected into the top, hence the arrow back into the ASP.Net layer from “other files”. Images are usually requested directly, but could come via ASP if the page in question needs to get an image that has been stored on the database.

Once the user has logged in they generally want to do something with our application. This involves data coming from, and going to, the database. This transfer of data is done via web methods and AJAX. If you don’t know what that means, it’s just a fancy way of saying that the data is requested from the web server in the background, without re-loading the application screen. When the user does something that needs more data, our application makes a request to the web server, the web server gets the data from the database and sends them back to our application, and the application displays the data to the user. A similar set of steps occurs when we need to save data back to the database.

The actual operation of the application is controlled via Javascript code. This is the “logic” of the front-end and determines when particular fields or buttons are disabled or hidden. The appearance of the user interface is set using stylesheets – just like those used when writing a web site. There are two remaining pieces of XUL technology which have a huge impact on the user interface, however: overlays and XBL.

Overlays got a brief mention above, because references to overlay files get injected into the page header by our ASP code. XBL files don’t get injected directly, but rather are indirectly referenced by one of the stylesheets we include.

Overlays and XBL are such a major part of our application framework that they deserve posts of their own, so I won’t say any more about them here, but will come back to them at a later date.

That’s about it.

You see, other than the oddities of having to deal with DTD files in javascript, a remote XUL application is constructed in a very similar way to any other web page. Where XUL excels, however is in producing rich user interfaces. This is achieved firstly by having very powerful widgets as part of the XUL toolkit (far more powerful than the limited form elements available in HTML, for example), and by allowing you to easily combine those widgets in complex ways to create even more powerful widgets and applications – that’s what overlays and XBL are for…

Posted in Tech, XUL. No Comments »