Are there set backs? Yes and no. The IE toolbars face certain difficulties with the user input, however they are not caused by the specifics of this toolbar tool. For example Del and Backspace wont work in text fields, Ctrl-Backspace can be used to delete input instead. Aside of this there is nothing else to be concerned for.

When building a HTML for the toolbar user interface you should be aware of some specifics. Most of them are related to the security management introduced with Windows XP Service Pack 2 and will require you to avoid certain techniques because they may cause security warnings to be shown to the users. The rest are just guidelines on how to design the HTML for the toolbar so that it would look nice.

The scripts in the toolbar UI page access your toolbar script directly through the external object (see Interacting between the toolbar UI and the toolbar script for more information). In other words the toolbar script can be thought as a an object exposed to your toolbar user interface page as object named external. In the toolbar script you implement the main part of your application and you invoke whatever is needed by calling routines from the toolbar script - external.routine_name. 

How to compose the toolbar HTML in order to comply to the security requirements.

There are two ways currently supported to feed the HTML into the toolbar:
Direct: The HTML is loaded directly from the file bypassing any navigation facilities thus avoiding any need of security checks.
Through ALP (Active Local Pages): This loads the HTML through the ALP protocol which allows the HTML to be generated by an ASP file or a CGI for example. However this scheme is more expensive (as it requires you to have an ALP developer license as well) and requires you to redistribute ALP engine with your toolbar application.

Using the direct load method.
In this case you should plan your toolbar user interface HTML so that no page reloads to be needed - i.e. you should apply any changes to the view by using DHTML techniques only (for example using innerText, innerHTML properties, the style properties and so on). Also you must NOT have any frames/iframes that load from file or from internet, because this may cause warnings too. It is recommended to avoid usage of frames and iframes, but if you need them anyway you should create them as containing about:blank and then fill them using the script (by using document.Wirte for instance). As it is seen above frames/iframes usage is not justified as it requires additional efforts, it is better to create bigger but single HTML and hide/unhide parts of it programmatically.

Using ALP to load the user interface.
In this case your HTML user interface is loaded through the ALP protocol and can be dynamically generated by an ASP page or CGI. While this sounds interesting it is not the most interesting way to use the ScriptBar and ALP together. Much more useful results can be achieved by invoking an ASP application in the browser's work area when it is required - for example to manage data collected by the toolbar, to configure it and any other thing that requires more user interface than a thin toolbar panel. 

Remarks: If you choose to use ALP extensively to load different UI-s in the toolbar area you can effectively treat the toolbar as a secondary work area of the browser - this means you can reload its user interface, frames, iframes and so on. As it was said above this sounds interesting but keep in mind that reloading the user interface of the toolbar is not expected by the users and that it involves additional efforts - your toolbar script will need to detect which UI is currently visible, to wait for reload when the UI is changed and so on. In other words you may get tangled in handling too many DHTML pages with a little additional benefit gained from it. If it is possible to make everything you need in a single DHTML page better do it that way. When it may be useful? In certain situations you may have several different toolbars with something common that justifies implementing them as one that behaves in different manner as needed. For example you may need different UI for different intranet applications. In such case using ALP to load appropriate user interface as the user goes from one application to another may be actually useful.

Other concerns 
It is not advisable to use any ActiveX controls in your toolbar user interface. First this may cause conflicts with the security manager (the user may have set the security too high for every zone), Second you will need to take care for more re-distributable files and last the visual controls (such as Flash or even Java) may need to load resources from the disk. This action may not be permitted by the security manager. Furthermore usage of additional ActiveX in the toolbar UI may make it heavier and slower to load. In general DHTML gives you more than enough features for dynamic user interface creation and employing additional components is hardly needed.

Design guidelines and requirements

Colors. Microsoft Internet Explorer supports some predefined names for the colors used by the system. Therefore you can use them to set the color of the toolbar body, text and other elements so that they match the rest of the browser's user interface. The most useful colors are: buttonface and buttontext. For example to set the body defaults to the colors IE uses for the other UI elements in the browser you can do this:
<body bgcolor="buttonface" text="buttontext" topmargin="0" leftmargin="0" SCROLL="NO">
As shown above, you should also set the margins to 0 and prevent scrolling (would be strange in a toolbar). Also use these colors in style definitions to make them match the system's. For more information on this topic see the DHTML References in MSDN (the topics related to color names and styles).

Page BASE URL. You must put a BASE tag in the header of the HTML page unless the page is loaded through ALP. This is what you must put there:
<head>
<BASE HREF="%BASE%">
... other content in the header ...
</head> 
The ScriptBar loads your user interface HTML directly and thus no page base URL is known for it. If this tag is present as shown above the toolbar will replace the %BASE% with the actual file path from which the HTML has been loaded. If you forget this tag the images in your HTML user interface will fail to load!

Images. Your HTML user interface for the toolbar will most often use some images for better appearance. You can preload them or just change their src properties when you need to change the image dynamically. As the toolbar content is on the local drive there is no point in pre-loading the images as it is often done in the WEB pages. If you are porting from an existing WEB page you can leave the code that pre-loads the images of course - this will do no harm.

Place all the images in the same directory as the toolbar DLL and the HTML user interface page and use relative paths to them. You can use subdirectories if you have too many resources but it is better to store everything in a single directory.

Hiding/showing parts of the user interface. In many cases you will want to hide/unhide parts of the toolbar user interface, show in the same place different controls, texts, images depending on what is happening in the work area or depending on some internal state changes. The best way is to use divisions (DIV HTML element) or tables (TABLE HTML element). You can find additional information about these features in the DHTML References in MSDN. Pay attention to the display style property and position style property.

The scripts in the user interface HTML. These scripts should be responsible only for user interface decorations and invoking further processing, but you should not implement anything more complicated in them. Whenever you need to do something more complex just call a function or sub implemented in the toolbar script and implement all the actual functionality in it. The reasons: First the script in the toolbar HTML is very restricted and second it has no access to the specific toolbar features.