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
