- From: Dean Edwards <dean@edwards.name>
- Date: Mon, 19 Jul 2004 19:59:22 +0100
James Graham wrote: > Jim Ley wrote: >> >> The alternative is simply not to use HTC's but straight script, it has >> a number of advantages: > > As I understand it, the requirement that is actually set in stone is > that the IE support not require a binary plugin. Therefore, in cases > where straight script will do, I see no reason not to use straight > script. On the other hand, I would expect HTCs or other IE-specific > technologies to be used in cases where straight script did not provide > the necessary functionality for the emulation layer. i pretty much agree with this. ideally i'd like to build a solution based around HTCs. the WF2 spec extends existing HTML elements and implements some new ones. this is precisely what HTCs are meant for. for those that don't know, HTCs consist of javascript and some markup to define an element's interface. the markup allows the definition of properties, methods, event handlers and custom events. the first three can all be duplicated using javascript, only custom events cannot. here is what HTCs provide over javascript alone: * object initialisation * custom events * automatic binding to new elements created by DOM methods it is important to understand that an HTC solution is essentially a javascript solution. with a *pure* javascript solution you would not get the benefits above. personally i am not against a pure javascript solution. if it can be made to support all of the WF2 spec it has clear benefits over an HTC solution. the benefits are: * less likely to be disabled using browser security settings * may be deployed from a central server earlier this year i wrote a mechanism for implementing HTCs in mozilla browsers: http://dean.edwards.name/moz-behaviors/ a similar technique can be used in IE. an interface defined in an HTC may be applied to an existing element using javascript. you would lose some functionality - as outlined above. please note that i am not suggesting we write a similar mechanism to moz-behaviors. i am merely providing an example of how the script content of an HTC can easily be applied to an element using javascript. organizing the javascript code into behaviors is the correct development approach. ideally i would like to produce a code set that can source an HTC solution *and* a pure javascript solution. also, using moz-behaviors, an HTC solution could also provide support for legacy mozilla browsers... so whether you agree or disagree with HTCs as an implementation on IE, i think there is some merit in organizing the code like this. -dean
Received on Monday, 19 July 2004 11:59:22 UTC