Export (0) Print
Expand All

Richer Data Entry

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 Internet Explorer Developer Center.

Dave Massy
Microsoft Corporation

October 23, 2001

Download the compose.exe sample file. (83.8 KB)

Contents

Send a Greeting
Editing Behavior
Submission
Downlevel
Editing Conclusion

Thanks for all the feedback to the last column, Fun with Tables. I have received many useful modifications and requests, and hope to revisit the tables topic in the future to address some of these issues and further enhance the set of behaviors that supply this functionality.

Since the last column was published, the final release of Microsoft® Internet Explorer® 6.0 has become available. With this release, the Internet Explorer development team has concentrated on a number of areas to enhance previous releases of the product. Of particular note is support for the Platform for Privacy Preferences (P3P) Project developed by the World Wide Web Consortium W3C. This support puts users in control of how information that they enter into the browser is used. (See Privacy in Internet Explorer 6.)

This is a very significant development; users need to feel confident, when using the Internet, that their information is secure. Internet Explorer 6.0 also offers high quality implementation of full support of Cascading Style Sheets 1 (CSS1) and DOM level 1, with enhancements to support for CSS2, CSS3, and DOM Level 2. Also noteworthy is the support for Synchronized Multimedia Integration Language (SMIL 2.0), which recently achieved recommendation status with the W3C. SMIL 2.0 enables timing and synchronization of elements and multimedia within a document. (For details, see the MSDN article, Basics of HTML+TIME Animation.) For a full description of the capabilities of Internet Explorer 6, see Highlights of Internet Explorer 6.

Send a Greeting

In this column, I wanted to discuss the support for rich HTML editing in Internet Explorer 5.5 and later. Note that you will need Internet Explorer 5.5 or later to experience these examples. With Internet Explorer 5.5, the previously rudimentary support for editing HTML was greatly enhanced, allowing for new scenarios to be exploited using Dynamic HTML. For an idea of what this capability offers, take a look at the Greeting Card Designer.

In this example, we have a greeting card designer where you can insert text and images, and select and resize them. Notice the nice gradient fill options for some of the backgrounds, making use of some declarative filter support, rather than a large resource intensive image. Also notice how, with the control key pressed, you can select multiple objects such as images and text. What's more, this example offers 'live resize'—while dragging a corner of an image to adjust the size, rather than just an outline of the image displayed, the full images are shown.

This is a fun little example of what can be achieved with the HTML editing support. It is easy to imagine extending this to have a submit button that would allow you to mail such a card electronically to an e-mail account, or to place it on a server for the recipient to view.

At the heart of this capability is a powerful editing engine fully incorporated into Internet Explorer. From Internet Explorer 4.0 onwards, HTML editing capabilities have been included in the platform. These are utilized in programs such as Microsoft® Outlook® Express for creating and editing HTML formatted e-mail. With Internet Explorer 5.5, we expanded the capabilities of the editor to allow such programs that hosted the core component of Internet Explorer to even further enhance and override these editing capabilities.

If you are interested in hosting HTML editing as part of a Windows application, take a look at MSHTML Editing, which explains the technology and how to host this component. This should help you concentrate on adding value to your application, while leveraging the work that you've already done. The significance of this to those doing DHTML in the browser, though, is that this same functionality is also exposed to you as the contentEditable property in the DHTML Object Model. By setting the contentEditable property on an element to TRUE, the contents of that element become editable—as will all the child elements, unless one of them has its contentEditable property set to FALSE.

Editing Behavior

Now by itself this might not sound particularly exciting, but if you take this ability and combine it with the other capabilities of Dynamic HTML and the behavior technology, we can produce a component that offers quality HTML text editing, much like the e-mail experience we all expect from programs such as Outlook Express. This component can then be easily reused in Web pages; for instance, an application such as a discussion board can allow users to be more expressive with their comments.

View the sample. (You can also download the full example code for this column as a self-extracting executable by using the link at the top of this article.)

<HTML xmlns:ed>
<?import namespace=ed implementation=editor.htc />

<HEAD>
      <TITLE>Compose</TITLE>
</HEAD>


<BODY STYLE="filter:
progid:DXImageTransform.Microsoft.Gradient(startColorstr='deepskyblue',endColorstr='white');" 
leftMargin=0 topMargin=2 rightMargin=0 marginwidth="0" marginheight="0" 
STYLE="font-family:verdana;">

<CENTER>
<ed:mailEditor style="height:60%;"  />
</CENTER>

</DIV>
</SPAN>

</BODY>
</HTML>

This behavior is implemented as an HTML Component or HTC file, editor.htc, and is therefore made up of HTML and script to provide this functionality. An interesting point about this particular behavior is that it is implemented as an element behavior rather than as an attached behavior. Element behaviors were introduced in Internet Explorer 5.5 and offer a more robust form of binding the component functionality to a custom element. In this case the element is the <ed:mailEditor/> tag. (See Element Behaviors for more information on element behaviors.)

Because this behavior is exposing editing functionality only available in Internet Explorer 5.5, it makes sense to use an element behavior, as it offers us not only the benefit of robust binding, but also viewlink encapsulation of content. The use of viewlink technology (see Viewlink for an overview) means that the content for the editing component is invisible from the host document, except through properties that the component deliberately exposes. This further enhances the robustness of using these components, as colliding namespaces are not an issue.

Another interesting point about this behavior is that it actually in turn makes use of further behaviors to handle such things as the color selection drop-down menus—showing how components can be used to build new components to provide potentially complex functionality.

Submission

So, we have a reasonable editing component that can easily be used within an HTML page. Still, having authored a rich message within this edit box, I'd like to actually save it to a server, so that my thoughts aren't just lost forever. To have this component take part in form submission, we have to use a little trick, since by default, custom elements don't automatically take part in form submission. The trick is to have a hidden input field, and when submission occurs, copy the content of the edit component to the hidden input field, which will then automatically be included in the submission of the form. Something such as the following should work, depending on how you accept data on the server.

    <FORM ACTION="http://...sample.asp" METHOD="POST" onsubmit="GetSource();">
<INPUT ID=in1 TYPE="hidden" NAME="CONTROL4" SIZE="20,5">
<ie:mailEditor STYLE="height:60%;" ID=editor />
        <P><INPUT TYPE=SUBMIT>
    </FORM>
<SCRIPT>

var inputElem = null;
function GetSource()
{
   inputElem = document.body.all.in1;
   inputElem.value = editor.docsource;
}
</SCRIPT>

Downlevel

One more thing we need to consider: What about users of older browsers that do not support this functionality? There are a couple of approaches to this. We could sniff the browser version on the server and serve up different pages according to the capabilities of that browser. This is often a good approach for complex applications, but there is an alternative for cases like the discussion board scenario I discussed earlier: the use of Conditional Comments.

Using conditional comments, we can author a single page that contains the HTML for our rich editing page as well as a more mundane input field for less capable browsers. When a downlevel browser sees this page, none of the additional HTC files will be downloaded, so there will be minimal overhead. Users of Internet Explorer 5.5 or later, however, will automatically get the richer editing experience. Note that in the example below, I've omitted the submission code, as we don't have a server resource established to submit to.

View the sample.

<HTML xmlns:ed>
<?import namespace=ed implementation=editor.htc />

<HEAD>
      <TITLE>Compose</TITLE>
</HEAD>

<BODY STYLE="filter:
progid:DXImageTransform.Microsoft.Gradient(startColorstr='deepskyblue',endColorstr='white');" 
leftMargin=0 topMargin=2 rightMargin=0 marginwidth="0" marginheight="0" 
STYLE="font-family:verdana;">

<CENTER>

<!--[if gte IE 5.5]>
<ed:mailEditor STYLE="height:60%;"  />
<![endif]-->
<![if ! gte IE 5.5]>
<INPUT TYPE="text" STYLE="height:300;width:500" >
<![endif]>

</CENTER>

</DIV>
</SPAN>

</BODY>
</HTML>

Editing Conclusion

Once again, because these are HTC files made of script and HTML, I encourage you to modify them to meet your own particular requirements.

 

DHTML Dude

David Massy occasionally wears sun glasses and pretends to be a dude, but when the dark glasses are removed, he works as a technical evangelist on Windows and Internet Explorer technologies, which means he talks to customers of Microsoft about how they might best use the technologies. Before becoming a technical evangelist, Dave worked on the Internet Explorer team as a program manager. Since Dave is originally from England, he is valiantly struggling to educate his American colleagues on how to pronounce "tomato" correctly.


  
Show:
© 2014 Microsoft