cross-browser nuances.

s@rdalya's behaviors may slightly differ on different platforms.
These nuiances and possible resolutions to them (if any) are archived in this blog.
Several exceptional situations are given here as well.

Note that the issues listed in this page are not bugs actually.
They may or may not be fixed in the forecoming versions of s@rdalya.
If you have any workaround, feel free to
share it.

---

If an element on the page does not have an id, certain
s@rdalya objects, like DraggableLayer may not
function properly on that element.

So, if you attach an object to DraggableLayer, make sure that it has an id.
Or give it an explicit id via DOM scripting.

 var lyr=document.getElementsByTagName("p")[0];
 lyr.id="ParaDrag";
 new DraggableLayer(lyr).fixToDragMode();

---

EvenHandler registers a separate event whenever addEventListener method is called for Internet Explorer. However it should register an event only once.

That is:

 eh.addEventListener("btnX","click",fn);
 eh.addEventListener("btnX","click",fn);

will trigger fn twice when clicked to "btnX" in IE. In Mozilla, Netscape and Opera, fn will be called only once.

---

If you don't explicitly specify the top and left
values of a layer for the page; Opera 8 beta and former
versions will assume the layer is placed relative to the top-left
corner of the browser window. However, it should have been positioned relative
to its relatively positioned container according to W3C specs.

A similar situation exists for Internet Explorer as well:

If the layer is positioned by specifying its right attribuite via CSS, internet explorer will assume the
left value of the layer to be zero.
However, recent versions of Mozilla-based browsers and
Opera will compute the left as expected
(the position of the left side of the layer from the left side of the container).

When using a DraggableLayer and start dragging a layer
for the first time; these peculiarities may result in the sudden jump of the DraggableLayer to the top left corner of the page.

To prevent this, the top and left values of the layer that will be dragged should be explicitly specified in CSS.

---

For Mozilla 1.5 and Netscape8 Beta; StyleManager returns "" for borderColor and borderWidth CSS values, regardless of what they have been defined in the CSS.

---

There are differences between the default values StyleManager returns for Internet Explorer and Mozilla or Opera.

Internet Explorer:

 visibility: visible => isVisible == true
top       : auto    => getTop    == NaN
left      : auto    => getLeft   == NaN 

Mozilla-based browsers & Opera:

 visibility: inherit => isVisible == false
top       : 0px     => getTop    == 0px
left      : 0px     => getLeft   == 0px

Therefore visibility, top and left CSS values should be given explicitly in the CSS
file if they are needed to be recalled later.

---

If there are more than one ToolTip objects in a document,
only the last one is used.

Thus, it is not practical to use more than one ToolTips per page.

---

DynamicLayer's (set|get)Width, (set|get)Height methods include paddings and borders in their
calculations as well.

However, StyleManager does not include
paddings and borders in calculation.

Thus, the findings of these objects may differ.

---

Opera requires at least a single non-whitespace
character for the LayerObject's
changeContent method to run.

 [div id="MyLayer"]
 [/div]

 [div id="MyLayer2"]
 
 [/div&]

The layers above will generate runtime exceptions in Opera
(version 7.2 or below)

  [div id="MyLayer"].[/div] (note the . character in between)

The layer above will work in all the browsers without any problem.

---

Opera defines tons of shortcut keys for the keyboard.
Therefore switching from drag mode to resize
mode in a DraggableLayer may occasionally result in
slight render anomalies.

However the behavior is not permanent: The view will recover
when the resize operation finishes. This problem is related
to the special key assignment of Opera;
if you have not pressed any special key, you will
not encounter the problem anyway.