NADAV: Can you briefly explain the thinking behind DHTML behaviors? What problem(s) do they solve?
MICHAEL: There were really two separate but complementary reasons for doing this. With IE 4, our goal was to turn the browser into a rich client for real applications. Not just the form-submit style applications that are prevalent on the Web, but the type of system that would reduce the number of server round trips and make the power of the client more available to developers. Especially in intranet scenarios, we have seen this come to fruition. The browser (IE 4) has started to become a viable replacement for other, more classically written client front ends. However, HTML was really lacking a component model for developers: If you had a chunk of code that you wanted to reuse, it wasn't very easy to do so. Using script src= allowed the user of the component to know a lot about how the component worked, and there was information leakage like crazy. It really didn't scale. So, we knew we needed to create a true component model for developers using HTML.
The other problem that prompted DHTML behaviors was totally different. When we showed Web authors the types of things you could do with IE 4, the response was almost universally positive. When we showed them that they needed to write scripts to create the effects they wanted, however, they generally didn't want to do it (either because they weren't script savvy or the cost would have been too high [to hire someone to do the coding]). For the shops that did plunge in, there was this complex iterative model of DHTML development where the content folks authored HTML, the designers described what they wanted it to do, and then the developers had to write a bunch of code. So, the second goal of behaviors was to make the power of DHTML more accessible to more people.
Really at the heart of both of these goals was the need for a component model. That component model needed to completely encapsulate the essence of that component (including style, behavior, and display). The component model also needed to be robust enough for developers, but easy enough for designers to snap into their sites.
next page»
