Alreigth then, how about a suggestion made earlier (don't recall by whom)..
Put some code into dynapi.js which will
'complie' the code for the specific browser in use?
we can use place-holder vars (constants) and have dynapi.js set them
according to
what browser/platform is in use..
Doug Melvin
----- Original Message -----
From: "Pascal Bestebroer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 10, 2000 2:51 AM
Subject: RE: [Dynapi-Dev] DynAPI build, Splitting files
>
> Once you split up parts of the API for every browser (that could
eventually
> include Opera, and other flavours) it means that people will start
focusing
> on a single browser because that's the browser they'll be using. Ofcourse
> this is already being done on a smaller scale (Dan's main focus seems to
be
> Netscape, and my focus is more IE5+) but at this point because of the code
> being one , we know that what ever we do should also work Netscape.. once
> you split things up I think this "awareness" will disappear and people
will
> just enhance the code for that single browser and let someone else worry
> about the other browsers files.
>
> "All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to
> learn the"
>
> that's correct, just two basic pairs of vars, so you want to split all
code
> up for simple things like these? And the fact that you have to go thru it
> and learn the differences is exactly my point, if you have the chance to
> only do your coding for IE, you will forget about NS and this might cause
> you to implement things in IE that are not possible in NS. Ofcourse this
> means we're holding back one browser because of the incompatibilities with
> the other, but that's the problem with cross-browser coding, and if you
need
> that extra functionality you should added it in your own code, not in the
> general API.
>
> The problem with speed that everybody talks about is not such a big issue,
> we're not developing for 386 or 486 machines anymore, Pentium machines
don't
> take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF
> statements are only called at initialisation and when changing styles, the
> main bottle-neck is not the IF statement but the time it takes browsers to
> redo the style sheet (and rerender things). This is just a browser
problem,
> not a code problem.
>
> And ofcourse size isn't such a big issue neither, seeing that most of the
> differences (I know, not all) are done on single lines as you pointed out:
>
> is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
>
> this will only be a few bytes difference once you split it up:
>
> e.x+document.body.scrollLeft
>
> so maybe you save some bytes with the split but you have to include all
> files multiple times and maintain all files multiple times for your site
to
> look good on all browsers.
>
>
> apologies for the long post :)
>
> cya,
>
> Pascal Bestebroer
> [EMAIL PROTECTED]
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]Namens SReindl
> > Verzonden: zaterdag 9 december 2000 9:14
> > Aan: [EMAIL PROTECTED]
> > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files
> >
> >
> > Well, call it as you like: Lib ode API, ... An API has the task to
supply
> > you with a unique set of functions in order to perform some development
> > tasks. In this case this is cross browser compatible programming of web
> > sites (btw, an API can be stored in a lib ;-))
> > I agree, that the API is not meant to be a play ground for fancy
> > stuff which
> > may be possible only for one particular browser.
> > But I don't see why the "streaming of the project" should be more work
for
> > separate files than for monolithic ones.
> > It's the definition of the basis of functions which is important, and
this
> > task has already been done, since the DynAPI is up and running.
> >
> > Look at this piece (from events.js):
> >
> > this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
> >
> > this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
> > this.x=is.ie?e.offsetX:e.layerX
> > this.y=is.ie?e.offsetY:e.layerY
> > var b = is.ie?e.button:e.which
> > if (is.ie){
> > if (b==2) b = 3
> > else if (b==4) b = 2
> > } else { }
> > All this is done only to define two basic paisr of vars. Terrible. And
> > impossible just to skip the nn stuff, becoause it's not clear, what
refers
> > to nn but only what is not for ie. I have to go through it and to
> > learn the
> > syntax of several browsers (document.body.scrollLeft vs
> > window.pageXOffset,
> > etc., and do not forget the sign).
> >
> > My
> > > "I mean, I want to develop mainly for IE and am not interested in the
nn
> > > specifics at all. I am satisfied when it works."
> > if of course *an example* only and not the goal of my programs.
> >
> > last not least, in addition to decrease in loading and rendering
> > time there
> > is one more feature which speaks for a split: control over
> > completeness. If
> > you have to assure that your implementation is complete you will have to
> > code all the functions. The chance just to forget an if branch is
smaller.
> >
> > I do not say that cross browser compatibility should be given up,
> > I think of
> > how this task can be done in a more transparent way.
> > Stephan
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
