|
From: Dan W. <da...@wi...> - 2003-04-29 21:24:54
|
On Tue, 2003-04-29 at 09:52, Joy Ride wrote: > Hello, > > I would like to make few notes about comming release of DynAPI3. I'm sorry > for that I haven't gone trough DynAPI3 code so that I would know wheter > these are allready taken count of. These are based on our experience and if > any one of you have better knowledge if these issues, I would be happy to > know about them. > > 1) There should be attention paid in to image size/sizing issues in DynAPI3. > (At least in DynAPI2 there were several problems related in it.) Netscape > 6/7 and Opera browsers are able to find out image dimensions only after the > whole document is loaded. There for DynAPI should employ mechanism which > prevents image size queries before document is loaded on these browsers. > Exspecially DynAPI core shouldn't rely on image dimensions before document > is fully loaded. > > 2) The Javascript engine of Netscape is very slow on what comes to events. > Special atention should be paid in to performance issues in Netscape > browsers (more shortcuts / performance tweaks?). Exspecially dragging is a > problem in Netscape. Jukka suggested that it might be good idea to consider > different approaches to click events and drag events in Netscape (simplified > drag module for Netscape?). I don't know if this is possible, but maybe it would work better if we use some more native netscape 6+ objects, instead of the standard dom. Netscape has 'behaviors' in their css files for the browsers themselves to call javascript function, say on mouseover of an element, etc. > > 3) In Netscape 4 loading is the hardest issue. Fairly badly documented > feature describes that Netscape 4 can have only one layer open for loading > at the time. Other layers have to be closed before loading stuff in to other > layer (note that Netscape doesn't close layer automaticly). If something is > tried to load in to layer when other layer is open Netscape crashes. This > suggests that some sort of loader is needed (based on our testes, in some > browsers onLoad detection is not 100% acurate). > > 4) Opera 5 is very slooooooow... it may affect in to some script > functionality. > > 5) Definition of looks should be made with styles when ever possible. Style > definitions should be done based on DOM standard. I totally agree with this, unless the current standards(CSS&DOM) are very bad in depicting a certain value and what it means, I say stick with the standards. We could also look at future standards values, like what is defined in CSS3. > Which means that widht > equals in to width of content area. Borders are excluded from this width > (this behavior differes from DynAPI2 approach). Following browsers use DOM > standard in a way described earlier (others need to be fixed "manually" in > dynapi): Opera from version 6 on, Netscape from version 6 on, MSIE from > version 5 on machintosh platfom and MSIE from version 6 on PC platform. On > MSIE6 on PC platfor ther is one catch though. MSIE6 uses DOM behavior only > if there is correct doctype definition (=DOM) and link to correct standard > in HTML file header. Otherwice it uses old aproach, where borders (for > instance) are counted as part of widht. There for there should be (?) some > sort of detection for doctype definition in DynAPI. > > These are the issues, we think that should be dealt with DynAPI3 before > betarelease if they aren't dealt allready. I think that we will be able to > provide the results of browser compability tests (Excel files, we have > tested all the objects and methods separately on each browser) shortly... I > will let you know when we are ready with those. > > > - Juho Risku / Helmi Staff > http://www.visualway.com/helmi > > ___________________________________ Just a few thoughts.... -- Dan Willemsen <da...@wi...> |