dynapi-dev

[Dynapi-Dev] DynAPI3 beta release - few comments

[Joy R. <joy...@ho...>]

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?).

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. 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

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: [Dynapi-Dev] DynAPI3 beta release - few comments

[Dan W. <da...@wi...>]

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...>

[Dynapi-Dev] DynLayer Highlighters

[Raymond I. <xw...@ya...>]

Hello Everyone,

Please check out this new Highlighter library that
will be used to create borders, etc:

http://www24.brinkster.com/dyntools/next/examples/dynapi.api.dynlayer-highlighter.html

Note: This demo does not support ns4 as yet. To get
the best results remove the fadeColor() function from
the demo. 

What do you think? Are they fast enough to be used as
highlighters?


--
Raymond Irving




__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Dynapi-Dev] DynLayer Highlighters

[Dan W. <da...@wi...>]

On Tue, 2003-04-29 at 23:09, Raymond Irving wrote:
> Hello Everyone,
> 
> Please check out this new Highlighter library that
> will be used to create borders, etc:
> 
> http://www24.brinkster.com/dyntools/next/examples/dynapi.api.dynlayer-highlighter.html
> 
> Note: This demo does not support ns4 as yet. To get
> the best results remove the fadeColor() function from
> the demo. 
> 
> What do you think? Are they fast enough to be used as
> highlighters?
> 
> 

This looks nice.  I've been playing with the new Netscape Javascript
Debugger, it has the ability to show how many times each function is
called, and their average speeds, etc. Its pretty cool.  Attached is the
output from this page.

> --
> Raymond Irving

-- 
Dan Willemsen <da...@wi...>

Re: [Dynapi-Dev] DynLayer Highlighters

[Doug M. <do...@cr...>]

Windows 2000 - AMD Thunderbird 900Mhz - 256 MB ram

Mozilla 1.4a - 300 layers in 681 milliseconds
IE 5.5 - 300 layers in 360 milliseconds

I suspect that should say "colors in x milliseconds" ?

----- Original Message -----
From: "Raymond Irving" <xw...@ya...>
To: <dyn...@li...>
Sent: Wednesday, April 30, 2003 12:09 PM
Subject: [Dynapi-Dev] DynLayer Highlighters


> Hello Everyone,
>
> Please check out this new Highlighter library that
> will be used to create borders, etc:
>
>
http://www24.brinkster.com/dyntools/next/examples/dynapi.api.dynlayer-highli
ghter.html
>
> Note: This demo does not support ns4 as yet. To get
> the best results remove the fadeColor() function from
> the demo.
>
> What do you think? Are they fast enough to be used as
> highlighters?
>
>
> --
> Raymond Irving
>
>
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 4/25/2003

Re: [Dynapi-Dev] setborder bug - resolved?

[Raymond I. <xw...@ya...>]

Hello,

I propose that instead using layers (highlighters) to
create borders in DOM browsers we simply extend the
clipped area (w,h)to twice the border size:

var w=((this.w+this._borClipOff)||0);
var h=((this.h+this._borClipOff)||0);
this.css.clip='rect(0px '+w+'px '+h+'px 0px)';

The above will cause layers when viewed in DOM to
appear a little wider than when viewed in IE. This
should not be a problem for most designs as the
deigner can work around this. My main reason for doing
this is obvious... CSS is much faster than using
layers to create borders.

The designer will also have the option of using
highlighters to create borders in either IE or DOM.
This is done by drawing four child layers around the
parent layer:

setBorder(size, color, useLyr);
size = size of border
color = color of border (e.g. "#FF00FF" or
{top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0", 
left:"FFFFFF"})
useLyr = (Optional) Forces the use of Layers as
borders. This is always true for NS4 but defaults to
false for DOM and IE.

Do you agree to this implementation?

--
Raymond Irving

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Dynapi-Dev] setborder bug - resolved?

[Dan W. <da...@wi...>]

On Wed, 2003-04-30 at 23:25, Raymond Irving wrote:
> Hello,
> 
> I propose that instead using layers (highlighters) to
> create borders in DOM browsers we simply extend the
> clipped area (w,h)to twice the border size:
> 
> var w=((this.w+this._borClipOff)||0);
> var h=((this.h+this._borClipOff)||0);
> this.css.clip='rect(0px '+w+'px '+h+'px 0px)';

My question, why even bother with this in dom browsers, you should be
able to set the css border property, and not touch the clipping. 
Shouldn't we?  This would allow some of the special border designs on
new browsers(like dashed, dotted, inset, outset, etc.)

> 
> The above will cause layers when viewed in DOM to
> appear a little wider than when viewed in IE. This
> should not be a problem for most designs as the
> deigner can work around this. My main reason for doing
> this is obvious... CSS is much faster than using
> layers to create borders.
> 
> The designer will also have the option of using
> highlighters to create borders in either IE or DOM.
> This is done by drawing four child layers around the
> parent layer:
> 
> setBorder(size, color, useLyr);
> size = size of border
> color = color of border (e.g. "#FF00FF" or
> {top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0", 
> left:"FFFFFF"})
> useLyr = (Optional) Forces the use of Layers as
> borders. This is always true for NS4 but defaults to
> false for DOM and IE.
> 
> Do you agree to this implementation?
> 
> --
> Raymond Irving

-- 
Dan Willemsen <da...@wi...>

Re: [Dynapi-Dev] setborder bug - resolved?

[Raymond I. <xw...@ya...>]

See Below:

--- Dan Willemsen <da...@wi...> wrote:
> On Wed, 2003-04-30 at 23:25, Raymond Irving wrote:
> > Hello,
> > 
> > I propose that instead using layers (highlighters)
> to
> > create borders in DOM browsers we simply extend
> the
> > clipped area (w,h)to twice the border size:
> > 
> > var w=((this.w+this._borClipOff)||0);
> > var h=((this.h+this._borClipOff)||0);
> > this.css.clip='rect(0px '+w+'px '+h+'px 0px)';
> 
> My question, why even bother with this in dom
> browsers, you should be
> able to set the css border property, and not touch
> the clipping. 
> Shouldn't we?  This would allow some of the special
> border designs on
> new browsers(like dashed, dotted, inset, outset,
> etc.)

The problem we're having with DOM browsers is that the
border is not part of the element (or content area)
width/height. When setSize is called the clip property
is set to the specified width/height of the layer.
This makes it possible for us to change the content of
a layer and not have the layer automatically adjust to
the size of it's content, correct? Because of this
when we set the border property we will not be able to
see the right and bottom borders due to the clipping.

--
Raymond Irving

> > 
> > The above will cause layers when viewed in DOM to
> > appear a little wider than when viewed in IE. This
> > should not be a problem for most designs as the
> > deigner can work around this. My main reason for
> doing
> > this is obvious... CSS is much faster than using
> > layers to create borders.
> > 
> > The designer will also have the option of using
> > highlighters to create borders in either IE or
> DOM.
> > This is done by drawing four child layers around
> the
> > parent layer:
> > 
> > setBorder(size, color, useLyr);
> > size = size of border
> > color = color of border (e.g. "#FF00FF" or
> > {top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0", 
> > left:"FFFFFF"})
> > useLyr = (Optional) Forces the use of Layers as
> > borders. This is always true for NS4 but defaults
> to
> > false for DOM and IE.
> > 
> > Do you agree to this implementation?
> > 
> > --
> > Raymond Irving
> 
> -- 
> Dan Willemsen <da...@wi...>
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Dynapi-Dev] setborder bug - resolved?

[Kevin <ke...@ke...>]

"Raymond Irving" <xw...@ya...> wrote:

> Hello,
> 
> I propose that instead using layers (highlighters) to
> create borders in DOM browsers we simply extend the
> clipped area (w,h)to twice the border size:
> 
> var w=((this.w+this._borClipOff)||0);
> var h=((this.h+this._borClipOff)||0);
> this.css.clip='rect(0px '+w+'px '+h+'px 0px)';
> 
> The above will cause layers when viewed in DOM to
> appear a little wider than when viewed in IE. This
> should not be a problem for most designs as the
> deigner can work around this. My main reason for doing
> this is obvious... CSS is much faster than using
> layers to create borders.

I wouldn't ask a designer to work around our problems.
If two DynLayers are side by side in a simple containing
DynLayer. Giving the first a border dynamically would
push the other under the containers clip and messing up
the second DynLayers co-ordinates. Re: my previous
comment:

"Would we have to 'adjust' the dlyr x/y? What are the
coords of relative elements or when constructing a
widget and bordered elements need to touch?"

This is bad and what makes it even worse is that IE5x
will behave differently to IE4/6 and again differently to
DOM. This doesn't matter for one DynLayer widgets
as they animate over everything else.

-
Kevin

> The designer will also have the option of using
> highlighters to create borders in either IE or DOM.
> This is done by drawing four child layers around the
> parent layer:
> 
> setBorder(size, color, useLyr);
> size = size of border
> color = color of border (e.g. "#FF00FF" or
> {top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0", 
> left:"FFFFFF"})
> useLyr = (Optional) Forces the use of Layers as
> borders. This is always true for NS4 but defaults to
> false for DOM and IE.
> 
> Do you agree to this implementation?
> 
> --
> Raymond Irving
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../

Re: [Dynapi-Dev] setborder bug - resolved?

[Raymond I. <xw...@ya...>]

See Below:

--- Kevin <ke...@ke...> wrote:
> 
> "Raymond Irving" <xw...@ya...> wrote:
> 
> > Hello,
> > 
> > I propose that instead using layers (highlighters)
> to
> > create borders in DOM browsers we simply extend
> the
> > clipped area (w,h)to twice the border size:
> > 
> > var w=((this.w+this._borClipOff)||0);
> > var h=((this.h+this._borClipOff)||0);
> > this.css.clip='rect(0px '+w+'px '+h+'px 0px)';
> > 
> > The above will cause layers when viewed in DOM to
> > appear a little wider than when viewed in IE. This
> > should not be a problem for most designs as the
> > deigner can work around this. My main reason for
> doing
> > this is obvious... CSS is much faster than using
> > layers to create borders.
> 
> I wouldn't ask a designer to work around our
> problems.
> If two DynLayers are side by side in a simple
> containing
> DynLayer. Giving the first a border dynamically
> would
> push the other under the containers clip and messing
> up
> the second DynLayers co-ordinates. Re: my previous
> comment:
> 
> "Would we have to 'adjust' the dlyr x/y? What are
> the
> coords of relative elements or when constructing a
> widget and bordered elements need to touch?"

Adjusting the xy would really mess things up.
 
> This is bad and what makes it even worse is that
> IE5x
> will behave differently to IE4/6 and again
> differently to
> DOM. This doesn't matter for one DynLayer widgets
> as they animate over everything else.

You now what, this border thing with IE, DOM and NS4
is really taking up a lot of time. I think I'll only
implement borders using layers. If a user needs CSS
support then they'll have to implement that on there
own. IMO I believe CSS borders should work the same
way table borders do... the border (padding,etc)should
be part of the width/height of the element.  So
elm.style.width="100px" will remain 100px even with a
border of 4px.


--
Raymond Irving

> -
> Kevin
> 
> > The designer will also have the option of using
> > highlighters to create borders in either IE or
> DOM.
> > This is done by drawing four child layers around
> the
> > parent layer:
> > 
> > setBorder(size, color, useLyr);
> > size = size of border
> > color = color of border (e.g. "#FF00FF" or
> > {top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0", 
> > left:"FFFFFF"})
> > useLyr = (Optional) Forces the use of Layers as
> > borders. This is always true for NS4 but defaults
> to
> > false for DOM and IE.
> > 
> > Do you agree to this implementation?
> > 
> > --
> > Raymond Irving
> > 
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Search - Faster. Easier. Bingo.
> > http://search.yahoo.com
> > 
> > 
> >
>
-------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
>
http://www.mail-archive.com/dyn...@li.../
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
>
http://www.mail-archive.com/dyn...@li.../


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Dynapi-Dev] setborder bug - resolved?

[Doug M. <do...@cr...>]

It seems to me that a more "natural" way to handle things would be to reduce
the size
of the layer rather than increasing it's clipping.

It seems perfeclt intuative to me that adding aborder of one pixel's width
would reduce
the amound of usable area by one pixel in each direction
----- Original Message ----- 
From: "Kevin" <ke...@ke...>
To: "Dynapi-Dev" <Dyn...@li...>
Sent: Thursday, May 01, 2003 2:41 PM
Subject: Re: [Dynapi-Dev] setborder bug - resolved?


>
> "Raymond Irving" <xw...@ya...> wrote:
>
> > Hello,
> >
> > I propose that instead using layers (highlighters) to
> > create borders in DOM browsers we simply extend the
> > clipped area (w,h)to twice the border size:
> >
> > var w=((this.w+this._borClipOff)||0);
> > var h=((this.h+this._borClipOff)||0);
> > this.css.clip='rect(0px '+w+'px '+h+'px 0px)';
> >
> > The above will cause layers when viewed in DOM to
> > appear a little wider than when viewed in IE. This
> > should not be a problem for most designs as the
> > deigner can work around this. My main reason for doing
> > this is obvious... CSS is much faster than using
> > layers to create borders.
>
> I wouldn't ask a designer to work around our problems.
> If two DynLayers are side by side in a simple containing
> DynLayer. Giving the first a border dynamically would
> push the other under the containers clip and messing up
> the second DynLayers co-ordinates. Re: my previous
> comment:
>
> "Would we have to 'adjust' the dlyr x/y? What are the
> coords of relative elements or when constructing a
> widget and bordered elements need to touch?"
>
> This is bad and what makes it even worse is that IE5x
> will behave differently to IE4/6 and again differently to
> DOM. This doesn't matter for one DynLayer widgets
> as they animate over everything else.
>
> -
> Kevin
>
> > The designer will also have the option of using
> > highlighters to create borders in either IE or DOM.
> > This is done by drawing four child layers around the
> > parent layer:
> >
> > setBorder(size, color, useLyr);
> > size = size of border
> > color = color of border (e.g. "#FF00FF" or
> > {top:"#FFFFFF", right:"C0C0C0", bottom:"C0C0C0",
> > left:"FFFFFF"})
> > useLyr = (Optional) Forces the use of Layers as
> > borders. This is always true for NS4 but defaults to
> > false for DOM and IE.
> >
> > Do you agree to this implementation?
> >
> > --
> > Raymond Irving
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Search - Faster. Easier. Bingo.
> > http://search.yahoo.com
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>