RE: [Dynapi-Dev] DynAPI build, Splitting files

[Pascal B. <pa...@dy...>]

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
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens SReindl
> Verzonden: zaterdag 9 december 2000 9:14
> Aan: dyn...@li...
> 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