but doesn't that mean that we then go back to where we were before the dynapi.
we are back to being at the mercy of the browser.
i personally use the dynapi to make the browser behave in a standard manner.
there are too many differences between the method of event control between the
browsers to simply hand back that control to them.
I am all for getting DOM controls working. But I still believe that there is no
real DOM compliant browser. and as NS6 is the closest we get, this is not the
best place to start. Mozilla themselves have said that it is not complete.
Digital Strider wrote:
> That would be a nightmare to keep consistent and way too much
> overkill. DOM API's do not need to be as complex the DynAPI. For
> instance, there is not need to have functions to set the css
> properties, when they can be accessed directly (of course it could be
> an extension). Also, things like eventListeners are built-in to DOM
> browsers (although slightly different in IE), so there is no need to
> create a complex event system.
>
> --
> Robert Rainwater
>
> /*
>
> <emote> straps on headphones and places a bag of rocks next to his keyboard.
>
> Well, for once I get to disagree with Robert. Creating the "new" API
> (from the ground up) to mirror implementation syntax of the current API
> makes all the sense in the world.
>
> Constructing a page now or in the future for DHTML will require and page
> object construction.
>
> MyLayer = MyLayer;
>
> Now and in the future you will need to make DHTML calls;
>
> MyLayer.setHTML;
> MyLayer.setVisable;
> MyLayer.slideTo;
> MyLayer.moveTo;
> MyLayer.etc........
>
> We'll still have threads, image management, animation systems
> (circle,path,image), etc..
>
> The current syntax is "obvious" and "appropriate". All your doing in the
> beginning (before loading any libraries) is capturing browser type and
> pointing the client user towards the most appropriate API.
>
> Related to eventhandling I'm of the mind that it will still be required.
> Will all implementations support object management in an identical manner
> (bubble up/bubble down)? Personally, I think not. So in the end your
> probably going to have to define listeners and manage targets and sources
> anyway.
>
> myLayerListener;
> and all the event calls:
> mouseover,
> mousedown,
> mouseup,
> custom defined,
> all seems very appropriate to me.
>
> Sure, the implementation will be different but the function calls could and
> should be the same as now.
>
> Benefits,....
>
> 1) All currently deployed pages will (with possible minor changes) be able
> to migrate to the new code base.
>
> 2) Migration will be augmented and learning curves lowered significantly due
> to simular syntax.
>
> 3) Once the new API is stable you can deploy it much sooner then you would
> be able to if you wait for browser migration and client support requiements
> allow it to happen.
>
> 4) The new API would be a fraction of this ones size.
>
> 5) It just makes sense.
>
> Disadvantages,...
>
> 1) This will require building for the future with an eye over the shoulder.
> But I don't think the issue is unmanageable at all.
>
> 2) It will take longer to create the next API testing for reverse syntax
> capatability.
>
> Let the storm begin...
>
> DS
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.252 / Virus Database: 125 - Release Date: 5/9/2001
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
