Introduction to HTML Applications (HTAs)
The power to build HTML Applications (HTAs) brings Windows Internet Explorer to the fore as a viable Windows development platform. HTAs are full-fledged applications. These applications are trusted and display only the menus, icons, toolbars, and title information that the web developer creates. In short, HTAs pack all the power of Internet Explorer—its object model, performance, rendering power and protocol support—without enforcing the strict security model and user interface of the browser.
- Why Use HTAs
- Creating an HTA
- HTA-Specific Functionality
- The Power of Trust: HTAs and Security
- Compatibility
- HTA Deployment
- Conclusion
- Related Topics
Why Use HTAs
Historically, programming languages like C++ and Microsoft Visual Basic have provided the object models and access to system resources that developers demand. With HTAs, Dynamic HTML (DHTML) with script can be added to that list. HTAs not only support everything a webpage does—namely HTML, Cascading Style Sheets (CSS), scripting languages, and behaviors—but also HTA–specific functionality. This added functionality provides control over user interface design and access to the client system. Moreover, run as trusted applications, HTAs are not subject to the same security constraints as webpages. As with any executable file, the user is asked once, before the HTA is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. The end result is that an HTA runs like any executable (.exe) file written in C++ or Visual Basic.
HTAs are suited to many uses, whether you are prototyping, making wizards, or building full-scale applications. Everything DHTML and script can deliver—forms, multimedia, web applications, HTML editors, and browsers—HTAs can too... and then some. In fact, HTAs can make some tasks easier. The simplicity of generating prototypes using HTAs makes it possible for designers to script dialog boxes and alerts while the C++ or Visual Basic developers program the underlying functionality.
Creating an HTA
To create an HTA, write an HTML page, and then save it with the .hta extension.
The following sample demonstrates the simplest possible HTA. It consists of a string—"Hello, World"—and is saved with the .hta extension. (Even though the html and body tags are omitted in this example, no error is displayed.) To close the HTA, press ALT+F4.
Hello, World
Code example: https://samples.msdn.microsoft.com/workshop/samples/author/hta/hta_simple.hta
To launch an HTA, double-click its program icon, run it from the Start menu, open it through a URL, or start it from the command line. After starting, the HTA renders everything within the body tag and displays the value set in the title tag as the window title.
HTA-Specific Functionality
Where the .hta extension tells the operating system how to run the application, the HTA:APPLICATION tag and attributes tell the window how to behave as an application. This tag exposes a limited set of attributes—attributes that control everything from border style to the program icon and its menu. Most attributes have default values optimized for the average application. This tag must appear within the head tag.
The HTA:APPLICATION tag in the following example specifies application features not available in DHTML. As prescribed by the attributes, this application has neither border (border), nor title bar (caption), nor standard program icon (sysMenu). The application title appears in the Windows task list but not in the taskbar (showInTaskBar), and only one instance of the application is permitted to run at a time (singleInstance). When launched, the HTA is known to the system as "monster" (applicationName) and initially is sized to fill the screen (windowState). For a full list of attributes and properties, and links to more information about each, see HTML Applications Reference. The program can be closed by pressing ALT+F4.
<head>
<title>My Monster Application</title>
<hta:application id="oMyApp"
applicationname="monster"
border="none"
caption="no"
icon="/graphics/creature.ico"
showintaskbar="no"
singleinstance="yes"
sysmenu="no"
windowstate="maximize">
</head>
Many of the HTA–specific properties that affect the user interface of the window are interdependent. When sysMenu is set to no, both the program icon and the Minimize and Maximize buttons are disabled. When border is set to none, neither the window border, the program icon, the title bar, nor the Minimize and Maximize buttons display. Finally, when caption is set to no, the Minimize and Maximize buttons, the program icon, and the window border are disabled. These contingencies all conform to standard Windows GUI design.
The Power of Trust: HTAs and Security
As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a webpage. The result is an application that runs seamlessly, without interruption.
In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). And HTAs have read/write access to the files and system registry on the client machine.
The trusted status of HTAs also extends to all operations subject to security zone options. In short, zone security is off. Consequently, HTAs run embedded Microsoft ActiveX controls and Java applets irrespective of the zone security setting on the client machine. No warning displays before such objects are run within an HTA. HTAs run outside of the Internet Explorer process, and therefore are not subject to the security restrictions imposed by Protected Mode when run on Windows Vista.
HTA windows can extend the trust relationship to content in other domains. HTAs allow cross-domain script access between window objects and cookies. To address the security risks inherent in cross-domain scripting, HTA enables the APPLICATION attribute for frame and iframe objects. This HTA-only attribute is not the sole security precaution available. HTAs are designed such that frame and iframe objects, where the APPLICATION attribute is set to no, have no script access to the HTA containing them. In this way, no unsecure content is allowed into an HTA through an untrusted window.
HTAs are designed such that untrusted HTML frame and iframe objects have no script access to the HTA containing them. In the case of frame objects that are not HTA-enabled, the highest level frame comprises the top window for all frame objects it contains. For that frame object, the window.top and window.self properties are one and the same. In addition, unsafe frame and iframe objects receive neither a referrer nor an opener URL from the parent HTA. The end result is that they are unaware of the containing HTA as the parent window.
In applications where all content is safe, frame and iframe objects can safely be marked as trusted. Wizards and control panels are examples of safe content. The HTA-enabled status of the iframe in the following example permits it to pass information back to its parent window.
<iframe src="filename.htm" application="yes">
In contrast, an iframe object that allows browsing to unsecured content must be implemented as regular HTML. Content in the iframe example below is subject to the security setting for its zone. The following iframe can be used when embedding HTML.
<iframe src="filename.htm" application="no">
Note The APPLICATION attribute is ignored if used in HTML rather than in an HTA.
When running HTAs, users should take the same precautions as with any executable: Only install HTAs produced by reliable sources. HTAs cannot be code-signed. However, they can be installed from signed cabinet (.cab) files or other signed installation formats. Either way, the most accountable sources will be corporate intranets and established software vendors.
Compatibility
By default, HTAs display webpages in Compatibility View, which displays standards-mode content in IE7 Standards mode and quirks mode content in IE5 (Quirks) mode. To utilize features available to current versions of Internet Explorer, use the meta element to define an X-UA-Compatible header for your HTA, as shown in the following code sample.
<html>
<head>
<title>SVG-Enabled HTML Application</title>
<meta http-equiv="x-ua-compatible" content="ie=9">
<hta:application
id="oSample"
applicationname="svghtasample1"
version="1"
</hta>
</head>
<body>
<p>Because this HTA includes an X-UA-Compatible header,
it is displayed in IE9 Standards mode when Internet
Explorer 9 is installed on the system. As a result,
SVG can be used to draw a blue star.</p>
<svg width="12cm" height="4cm" viewBox="0 0 1200 400"
xmlns="https://www.w3.org/2000/svg" version="1.1">
<desc>Example Star</desc>
<polygon
fill="blue" stroke="blue" stroke-width="10"
points="350,75 379,161 469,161 397,215 423,301
350,250 277,301 303,215 231,161 321,161" />
</svg>
</body>
</html>
For more information, see Defining Document Compatibility.
In addition, the following concerns also affect compatibility:
HTAs that incorporate features supported by specific versions of Internet Explorer function correctly only when opened by versions of Internet Explorer that support those features.
HTAs do not support the AutoComplete in HTML forms feature, or the window.external object.
HTAs do not support the Mark of the Web and open in the Intranet zone; configuration settings applied to this zone may affect the behavior of your HTA.
HTA Deployment
The HTA implementation supports multiple deployment methods: the web model, the package model, and a hybrid of the two. Application developers should decide how best to meet their distribution needs.
The Web Deployment Model
The web deployment model consists of an application that can be run and administered just like a webpage. In this scenario, the HTA is launched simply by browsing to its URL or by accessing it from the Internet Explorer Favorites list. Before launch, an Internet Explorer dialog box presents the user with the choice to open or save the application. After launch, ancillary application components are downloaded from the server as needed and then cached. Servers must return a Content-Type: application/hta header for Internet Explorer to correctly interpret the response as an HTA.
This model boasts some important strengths. It facilitates seamless updates: The intranet administrator need only post the new code or content for the client to receive the latest version. It provides ease of use: The user need never install or uninstall the application. Unused applications are automatically flushed from the cache. One important consideration when evaluating this deployment model is that server-based applications cannot be run offline or when the server goes down.
The Package Model
In the package deployment model, the installation process for the HTA is the same as for traditional applications. Files are copied from a disk or over a network, using any installer or self-extracting executable. The installer places the application in the Program Files directory or in the directory selected by the user. A link to the HTA is included in the Start menu. Look to tools vendors for vehicles for packaging and delivering HTAs to your specifications.
Like the web model, the package model is attractive for a number of reasons. The user is prompted only during the initial installation about trusting the application; thereafter, the application runs as trusted code just as an .exe does. Also, the installed HTA is always available to users, whether they are connected to the server or not.
Hybrid Deployment Models
Any combination of web and package deployment models is feasible. The method of delivery is transparent to the HTA. HTA components are always referenced as URLs, absolute or relative, so the applications simply work.
Examine Your Priorities
What are your distribution needs? The following list presents just a few scenarios.
- If keeping the initial download time brief is paramount, then hybridize by installing the top window of the HTA onto the client machine, leaving the HTA to access the server for images and support files.
- If your users run the application both at work and remotely, consider deploying HTAs over the local network using the web model while also distributing it for remote use using the package model.
- Perhaps your business requires a tool where the content is maintained by separate groups and is distributed across servers. The application will look and function like a unified whole if you create a single user interface and use web deployment to automatically deliver the latest information.
Conclusion
No matter what the delivery model, using Internet Explorer as your development platform is a compelling way to build applications large and small.