Internet Explorer Namespace Support
As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see IE Developer Center.
March 1, 2009
- Element namespace support since Internet Explorer 5
- Simplifying binary behavior deployment
- Simplifying HTML source
- Element namespaces deep-dive
- Rules for namespace string automatic binding
- Dynamic HTML – applying element namespaces
- Default namespaces and the namespaces collection
- Legacy element namespace functionality
Element namespaces are the means for HTML component developers to bind attached behaviors to special HTML markup (called HTML Components or HTCs), and COM developers to bind binary behaviors. Only namespaced elements can have HTCs or binary behaviors applied to them.
Internet Explorer 5 though Internet Explorer 7 provided limited HTML parser support for element namespaces. Component developers were also required to support Internet Explorer’s proprietary <object> and <?import> syntax.
Internet Explorer 8 offers HTML component developers (of binary behaviors) the opportunity to simplify the deployment and inclusion of binary behaviors in an HTML Web page. To enable a more seamless deployment model for binary behaviors, two new functions allow binary behavior authors to register a namespace string and clsid with Internet Explorer 8. After registering, HTML markup using element namespaces need only refer to the namespace string and Internet Explorer 8 will take care of the binding automatically.
Furthermore, Internet Explorer 8 improves its element namespace support by implementing support for default namespaces within the HTML parser. Default namespaces reduce the amount of HTML markup necessary to describe an element namespace.
In the past, using element namespace support to load a binary behavior required the declaration of an OBJECT element, and an IMPORT processing instruction to bind the OBJECT to a namespace prefix. This is illustrated in the following example.
<html xmlns:svg> <head> <title>SVG embedded inline in XHTML</title> <!-- The following is the "hookup code" required by IE –-> <object id="AdobeSVG" classid="clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2"> </object> <?import namespace="svg" implementation="#AdobeSVG"?> </head> <body> <svg:svg width="600" height="300"> <svg:linearGradient id="gradient"> <svg:stop style="stop-color:yellow" offset="0%" /> <svg:stop style="stop-color:green" offset="100%" /> </svg:linearGradient> <svg:rect x="0" y="0" width="100" height="100" style="fill:url(#gradient)" /> <svg:circle cx="50" cy="50" r="30" style="fill:url(#gradient)" /> <svg:circle cx="150" cy="100" r="50" /> </svg:svg> </body> </html>
In this example, an SVG viewer (provided by Adobe) is loaded into the OBJECT element. The namespace svg defined on the HTML element is bound to that object in the IMPORT processing instruction. Finally, each element namespace must be declared with an svg prefix in the markup.
In Internet Explorer 5 through Internet Explorer 7, element namespace support requires the OBJECT and IMPORT syntax in order to bind to a binary behavior. The HTML parser is also severely limited in its element namespace support compared to the XML Namespaces standard: only namespace prefix definitions (such as xmlns:example[='namespaceURI']) are allowed, and then only on the HTML element.
Internet Explorer 8 adds two functions to enable binary behavior developers to pre-register a namespace string associated with the CLSID of their component. Once registered, web pages that make use of that namespace string in their element namespaces are automatically bound to the associated binary behavior in Internet Explorer 8; no need to include the proprietary <OBJECT> and <?IMPORT> directives.
The new functions are as follows.
IEIsXMLNSRegistered checks to see if a namespace name is already registered.
IERegisterXMLNS registers a namespace.
When the namespace string and CLSID is registered, the appropriate keys and values are stored in the registry at the following location.
HKEY_LOCAL_MACHINE\ (or HKEY_CURRENT_USER) SOFTWARE\ Microsoft\ Internet Explorer\ XML Namespace
Subsequent calls to IERegisterXMLNS with the same namespace string will overwrite the exiting CLSID. Please use IEIsXMLNSRegistered before IERegisterXMLNS to ensure that a given CLSID is not already registered for the given namespace string.
The Internet Explorer default behaviors can be instantiated with both this mechanism and the old OBJECT/IMPORT elements on a web page.
In Internet Explorer 8, HTML component developers can write simplified markup to bind and use a binary behavior, thus making their code more readable and compact. Internet Explorer 8 removes the need for the proprietary hookup markup (the OBJECT and IMPORT elements). It does so by letting pre-registered binary behaviors be used in a Web page simply by reference to their registered namespace string (such as "http://www.w3.org/2000/svg").
Internet Explorer 8 also allows default namespaces anywhere in the markup to scope a namespace and avoid the repetition of namespace prefixes on every element. A default namespace has the syntax xmlns="namespace string".
The previous SVG plugin sample code could be rewritten as follows, assuming that the namespace "http://www.w3.org/2000/svg" was registered with IERegisterXMLNS upon installation of the SVG plugin.
<html> <head> <title>SVG embedded inline in XHTML</title> </head> <body> <svg width="600" height="300" xmlns="http://www.w3.org/2000/svg"> <linearGradient id="gradient"> <stop style="stop-color:yellow" offset="0%" /> <stop style="stop-color:green" offset="100%" /> </linearGradient> <rect x="0" y="0" width="100" height="100" style="fill:url(#gradient)" /> <circle cx="50" cy="50" r="30" style="fill:url(#gradient)" /> <circle cx="150" cy="100" r="50" /> </svg> </body> </html>
This markup is easier to read and more compact that the previous version.
Note: Both default namespace declarations as well as prefix definitions will bind the binary behavior if the namespace string matches the installed entry in the Windows registry.
This section describes the way Internet Explorer 8 supports namespaces. The definitions in this section should not be confused with those found in the WC3's XML Namespace specification. Differences between the two are noted as necessary.
The scope of a namespace declaration depends upon where it is declared in the document tree. To illustrate, consider the following markup.
<HTML xmlns:pre="namespace1" xmlns:other="namespace4"> <BODY> <pre:element1> <pre:div>Some text</pre:div> <other:div>More text</other:div> </pre:element1> <element2 xmlns="namespace2"> <element3>Some text</element3> <input type="text" > <element4 xmlns="namespace3">Some more text</element4> </element2> <p xmlns="namespace3">Paragraph text <element5>Text</element5> <other:element6 /> <hr> <other:hr /> </p> </BODY> </HTML>
This example illustrates several points of interest.
The HTML element defines the namespace "namespace1" and "namespace4", but this element itself is not included in a namespace.
Element1 is included in "namespace1" (due to prefix binding).
The DIV element with the "pre" prefix is included in "namespace1" because explicit namespace prefixes override native HTML element behavior , which is true for Internet Explorer 7 and easrlier versions.
The DIV element with the "other" prefix is included in "namespace4". Prefixed elements can be arbitrarily nested inside of prefixed elements of different namespaces.
Element2 defines "namespace2" and is also included in that namespace.
Element3 is included in "namespace2" because it inherits the default namespace of its parent.
The INPUT element is not included in "namespace2" because it is a known HTML element
Element4 is included in "namespace2" (not "namespace3") because its default namespace is nested inside of another default namespace ("namespace2").
The P element is not included in "namespace3" because it is a known HTML element.
Element5 is included in "namespace3" because it inherits the namespace defined from its parent.
Element6 is included in "namespace4" because prefixed elements override the default namespace inheritance of their parent.
The HR element without a prefix is not included in any namespace because it is a known HTML element.
The HR element with the "other" prefix is included in "namespace4" for two reasons. First, prefixed elements override the default namespace inheritance of their parent. Second, explicit namespace prefixes override native HTML element behavior, which is true for Internet Explorer 7 and earlier versions.
When an element has a namespace, regardless of the namespace value, it becomes a generic elements instead of an unknown element. Generic elements have a scope and can be dynamically attached to behaviors. Unknown elements have no intrinsic behavior.
Namespace URIs are not true URIs and are not resolved. In other words, relative namespace URLs are only bound to a behavior if the behavior has registered the same relative URL. The match is based on simple string matching; it either matches or it does not.
Namespace prefix definitions are not recognized outside of the root element, which is a limitation of Internet Explorer 7 and earlier versions.
In order to automatically bind a behavior to a default namespace, the "xmlns" and the namespaceURI attributes must both must be specified. In addition, the namespace must be registered before it is specified. If the syntax is not valid, the element becomes a generic element with no intrinsic behavior.
That following table lists some common valid examples of namespace declaration.
|xmlns="namespaceURI"||A complete and value example.|
|xmlns=namespaceURI||In keeping with Internet Explorer's forgiving parser rules, the quoted values are optional (though recommended).|
|XmLnS="namespaceURI"||Attribute names are not case sensitive.|
|Namespace prefix matching is not case sensitive.|
The following table contains examples of namespace declarations that will not automatically bind a register behavior to an element.
|xmlns=""||The empty string cannot be used to dynamically tie a behavior to a default namespace.|
|Xmlns||This declaration attempts to to use the xmlns attribute as a boolean expression. It is not bound to any behavior, but it is added to the element as an attribute set to an empty string; this is consistent with previous versions of Internet Explorer.|
|xmlns:bob||To remain compatible with the behavior of earlier versions, Internet Explorer 8 allows this syntax as a way to attach behaviors to elements declared with older techniques, such as CSS rules and the <?IMPORT> element.|
When matching a namespace declaration to the namespaces registered on a user's computer, Internet Explorer 8 uses literal string matching. It does not interpolate URI character entities to symbolic characters. For example, the string "%20" is treated as three separate characters; it does not represent a space for the purposes of namespace matching.
Techniques that dynamically applied namespace declarations for Internet Explorer 7 continue to work in Internet Explorer 8.
When using createElement, keep the following points in mind.
You can include a namespace prefix when declaring the type of element to create, as shown in the following example.
document.createElement("NSPrefix:HTMLElement")When you do this, Internet Explorer creates a generic element is created. If the prefix is known namespace, the element is bound to the corresponding behavior.
If you do not include a prefix with the element name when creating an element as a child of an element bound to a behavior, the child element does not automatically inherit the parent element's namespace binding.
If you call createElement with an element name that does not correspond to a valid HTML element, a generic element is created.
Web developers can use innerHTML and outerHTML to dynamically create elements automatically bound to default namespaces, as shown in the following example.
<script> document.body.innerHTML = "<element1 xmlns='namespace1'><element2 /></element1>"; </script>
In this example, "element1" and "element2" are bound to the default "namespace1" namespace.
Note: If you allow users of your Web site to contribute content to your site, be sure to take appropriate measures to prevent malicious behavior.
Internet Explorer 8 extends the way Internet Explorer 7 stored in the DOM by including default namespaces in the namespaces collection.
The values of the name property of the items in the namespaces collection must be unique. Because default namespaces do not have an associated prefix, Internet Explorer adds the string "[default]" to the name property, as shown in the following example.
To illustrate, consuidert the following HTML.
<html> <body> <element1 xmlns="http:myNamespaceURI"> <element2 /> </element1> </body> </html>
The namespaces collection contains one item. The value of its name property is "[default] http:myNamespaceURI" and the value of its urn property is "http:myNamespaceURI".
Individual elements use the following properties to report namespace information.
The scopeName property returns the value of the namespace prefix associated with the element. If the element has a default namespace applied, this property returns the default namespace string with the word "[default]" prepended. This property equivalent to the "prefix" property specified in the WC3's DOM Level 2 Core specification.
Element namespaces provide HTML component developers a convenient method to bind binary behaviors to traditional HTML pages. Binary behaviors are very useful for extending the Internet Explorer web platform. Internet Explorer 8 also improves its element namespace support by implementing support for default namespaces within the HTML parser. Default namespaces reduce the amount of HTML markup necessary to describe an element namespace.Travis Leithead is a Product Manager on the Internet Explorer team.