jQuery Forum

Transform a set of images into a Mac-like Dock menu, horizontal or
vertical, with icons that expand on rollover, and optional labels.
(Not particularly new, but I needed it.)
demo : http://www.wizzud.com/jqDock/
Feedback welcome.

I've encountered this intermittent, thoroughly unreliable (in terms of
being able to reproduce it) problem with swap().
Basically I have an image that has borders on it.
That image gets animated to change its width and/or height (plus
possibly a couple of others like top and left, but immaterial here).
What was happening very occasionally in Firefox, and even rarer, in
IE, was that borders were getting set to zero, and I couldn't work out
why or when. I completely re-factored my code, and got rid of the
problem (I thought) by removing all possible calls to myimage.width()
and myimage.height(), and where I couldn't remove them entirely I
spaced them out, so that a width() call did not follow immediately
after a height() call.
That seemed to solve the problem, but then I tested Safari (2 and 3)
and the problem came back again - in spades!
By putting alerts all the way through my code and jQuery, I finally
narrowed it down (I think!) to swap().
It would appear that the reinstatement of the 'old' values is
sometimes not happening. The width/height get reported back correctly,
it's just that the borders don't get reinstated.
I put the following modification into my jQuery ...
swap: function(e,o,f) {
    var now = {}; // added
    for ( var i in o ) {
        now[i] = e.style[i]; // added
//        e.style["old"+i] = e.style[i]; // commented out
        e.style[i] = o[i];
    }
    e.swaps = now; // added
    f.apply( e, [] );
    for ( i in o ) // just removed the var (i already declared)
        e.style[i] = now[i]; // added
//        e.style[i] = e.style["old"+i]; // commented out
},
... and I now don't have a problem! (Or at least I haven't managed to
get it fail yet!)
The way I reasoned it was that maybe the extra properties on style
were causing problems. I couldn't see that the old values really
needed to be stored on the element itself, particularly not in style,
but I could see that the called function *may* want to know what the
'proper' values should be. So I store the 'proper' values locally - in
'now' - and set a swaps property on the element itself before calling
the callback; then use 'now' to reinstate the 'proper' values at the
end.
Sorry it's such a long explanation but have some sympathy for how long
it's taken me to track this down!
Anyway, does anyone have any thoughts, opinions, input, previous
experience of the same problem ... anything?
[Just reading back over it, it might be safer to reinstate from the
element's swaps property, just in case the called function changes the
values it wants put back - can't see why it would, but still... .
Trouble is, this way works and it might not if I change it!]

Came across this problem whereby width/height animation in Opera, of
an object that has a border, causes 'jumps' in the object size before
resizing.
Demo and fix : http://www.wizzud.com/tester/operabug.html
This occurs because the borders are being included in the starting
width and height when initialising the animation. The problem is
located in fx.cur(), when curCSS() is used to get the width/height
values.
I can only find this problem in Opera (tried IE6, IE7, FF1.5, FF2,
Safari 2, Safari 3beta).
I have a rough patch (see demo) that fixes it, but has anyone else
encountered this problem before? Or know of any other browser that it
affects? Or have an alternate/better solution?
I searched the tickets and could not find anything relevant - I have
not yet raised a ticket for this, wanted to get some feedback first.

Probably @Brandon primarily...
I have a test version of some changes for offset(), basically:
- updated safari2 body offsets handling
- updated mozilla table handling and borders handling
- added thin/medium/thick border handling
- slightly modified IE body borders handling
For part of the testing I took the liberty of using and adding to your
visual test page(s) - an extra absolute and a table - as a consequence
of which I have played around with the links a bit! (There is also an
additional DIV#page to contain the test target areas).
http://www.wizzud.com/tester/ba_test_quirks.html and
http://www.wizzud.com/tester/ba_test_standard.html
It's running a modified v1.2.1, the modifications being:
- offset() has a switch at the top to redirect to offsetWizzud() if
set; otherwise it is the completely original code but with debug
statements threaded through it
- offsetWizzud() is my modified offset(), with debug statements
threaded through it (and quite a few comments)
- offset_WizzudClean() is offsetWizzud but cleaned up (no debug
statements, reduced comments, etc) ie more like production code, and
not called by the test pages at all - it's for comparison convenience.
The 2 test pages (above) will switch between the original offset() and
my modified version, and display of the debug info can be disabled.
I have tested on IE7, IE6, Firefox 2.0.0.7 (Win, Linux & Mac), Firefox
1.5.0.11 (Win), Safari 3beta (522.15.5) (Win), Opera 9.23 (Win & Mac),
Avant 10.2/11.5 (Win), Netscape 7.1 (Win), Safari 419.3 (Mac),
Konqueror 3.5.6 (Linux).
I don't have access to IE5.5 so if someone could test that I'd be
grateful
There are still some cases it won't/can't handle, but they're mainly
ones that either don't make sense HTML-wise, or where I found it nigh-
on impossible to determine what the browser is doing or how or why, or
if it mattered or I cared!
I hope it is useful.

If you call jQuery.noConflict() prior to loading the scripts for the
following ui functionality, they will fail ...
mouse, draggable, calendar, magnifier, resizable, shadow, slider and
sortable.
They all reference $, either directly or by passing it into the
anonymous 'run-now' function - I couldn't think of a better way to
describe it, but you know what I mean .... (function($){ [code] })
($);

This probably Brandon's area ...
The inclusion of an HTML element with an id of 'box' causes IE to fail
in the offset method, reporting that "Object doesn't support this
property or method" and relating to elem.getBoundingClientRect(). This
is even though it has just passed a logic test for it!
The solution is to declare box locally, ie change
box = elem.getBoundingClientRect();
to
var box = elem.getBoundingClientRect();
The problem and solution can be seen demonstrated at
http://www.wizzud.com/tester/offset_quirks.html or
http://www.wizzud.com/tester/offset_standard.html (quirks mode or
standard mode respectively). Click 'fix #box bug' to run fixed code.
The demo is set up such that offset is called on the #box element
itself, but it will still fail if #box exists anywhere on the page and
offset() is called on any other element.
Ticket 1651 raised for the above.
As a side issue, the offset() method has some code to combat IE's 2px
html border offset, but in quirks mode it depends on the User having
removed the html border using css styling. If the default styling is
left in place then offset() returns incorrect values.
I have an alternative suggestion which can be seen in action on the
pages mentioned above (click 'apply mod' to switch in my code, and
'remove mod' to run original). The only time it should make any
difference is for IE in quirks mode.
The alternate code is
var dde = document.documentElement || {};
add(-(dde.clientLeft || 0), -(dde.clientTop || 0));
in place of
    if ( msie ) {
        var border = jQuery("html").css("borderWidth");
        border = (border == "medium" || jQuery.boxModel && parseInt(version)

This is undoubtedly the wrong place to raise this, but ... aren't
nextAll, prevAll, andSelf, map and slice also 'destructive' operations
that can be reverted by end()?

I believe there is a bug in serializeArray whereby using...
<select multiple="multiple" name="test[]">
<option value="one" selected="selected">One</option>
<option value="two">Two</option>
<option value="three" selected="selected">Three</option>
</select>
$('select').serialize();
returns 'test[]=0&test[]=1' instead of 'test[]=one&test[]=three';
I think the problem is line 2094(ish)...
jQuery.map( val, function(i, val){
which should be...
jQuery.map( val, function(val, i){
Ticket #1600 raised.

Has anyone come across this before, coz it's been driving me nuts!
IE7 and IE6 are both reporting the cursor position as 2px greater - both X
and Y - than the actual position, say, of a div on the screen.
For example, given an absolutely positioned div at 100(top), 200(left), with
a mousemove event bound to document, returns event.pageX of 202 and
event.pageY of 102 when the cursor is placed at the top left hand corner of
the div.
Firefox and Opera work perfectly and return 200 and 100 respectively!
Demonstration at http://www.wizzud.com/tester http://www.wizzud.com/tester
- document is XHTML strict, but the same thing happens with HTML 40.1
transitional, so it's not the doctype! If you put the cursor (I set it to
crosshair to make it easier) at the top left hand corner of either grey area
it will report pageX/Y 2px out in IE, but on the money in Firefox/Opera. To
get IE to report 0,0 you actually have to go off the edge of the screen!
I looked into the fix code in jQuery but that is no solution because it just
uses clientX/Y, which (as shown on the demo) are wrong.
Basically, I can't see any way of accurately determining the cursor position
cross-browser without putting in a specific fix for IE!
Can anyone else help?
--
View this message in context: http://www.nabble.com/IE-2px-out-on-event.pageX-Y-tf4384471s15494.html#a12499347
Sent from the JQuery mailing list archive at Nabble.com.

The description of the usage of the scroll option is that it controls whether
or not the scroll offsets of the parent elements should be included in the
calculation of an element's offset.
With reference to the
http://dev.jquery.com/~brandon/plugins/dimensions/test/offset.html visual
test page, this works fine for Absolute3, Static3, and Inline1, all of
which are within the scrollable Relative3 area. My problem is with Relative3
itself, in that if you scroll it, the offset is calculated (with
scroll:true) using its own scroll offsets, so that sending the grey box to a
scrolled Relative3 puts the box outside the visible area of Relative3.
This seems to contradict the stated use of scroll in that Relative3 does not
have parents that have been scrolled but has itself been scrolled.
The reason for my query is that it is causing problems with Ext, purely on
this one point. I have raised it on extjs.com, with a possible work-around,
but Jack Slocum's (perfectly reasonable) response is to wonder why other
plugins (YUI, prototype) don't have a similar problem when they too
supposedly "take scroll into account". Well I don't know about prototype,
but this one sticking point is the big difference between YUI and the jquery
dimensions plugin.
I don't have an opinion on right or wrong (basically because I can't decide
which approach is more logical!), so I'm posing the question, and, I
suppose, requesting a change in either the behaviour or the description (of
the offset method) in order to make one consistent with the other. And
ultimately to get jQuery working consistently with Ext!
PS. I have put up a modified version of the Brandon's visual test that uses
the YUI position calculator, just so that interested parties (if there are
any) can see the difference between YUI and jQuery.
http://www.wizzud.com/getxy/index.html
http://www.wizzud.com/getxy/index.html
--
View this message in context: http://www.nabble.com/Question-about-scroll-in-dimensions-plugin-tf3777343s15494.html#a10681054
Sent from the JQuery mailing list archive at Nabble.com.

I have a problem with IE and the fix method of jquery.event, whereby it (IE)
sometimes objects to the variable b (=document.body) not being an object.
This usually happens on a page refresh, but cannot reliably be re-produced.
The solution I have put in place is a very small modification to the
assignment of the 'e' and 'b' variables prior to setting event.pageX and
event.pageY (if they are not available).
Using jquery 1.1.2 rev 1465 code, at line 2904 I changed
var e = document.documentElement, b = document.body;
to
var e = document.documentElement || {}, b = document.body || {};
and this solved the problem.
I have not been able to find any reports of anybody else having this same
problem, so why it should be happening to me I'm not sure. I am developing
with the Ext library, using jquery as the engine, and I don't know if that
is having any effect, but if it is I can't see why it should!
Anyway, its a really minor change, but if it could be incorporated into the
jquery core it would save me having to re-apply it on updates?
--
View this message in context: http://www.nabble.com/IE-sometimes-objects-to-jquery.event.fix-tf3674007s15494.html#a10266240
Sent from the JQuery mailing list archive at Nabble.com.

While playing with Ext I encountered a problem in Firefox whereby the offset
function in dimensions was causing an elem.style error. The reason is that
there is a do-while loop if options.scroll is set, and that loop will go all
the way up to the document, at which point - if the browser is Mozilla - the
code attempts to check the css for overflow not visible and falls over
because document has no style.
I fixed this in my version by modifying line 260 of dimensions.js and
inserting a check for op, so the line now begins ...
if (op && jQuery.browser.mozilla && ....
This prevents the jQuery.css() call failing at the document level.
--
View this message in context: http://www.nabble.com/dimensions-plugin-Mozilla-bug-tf3421935.html#a9537545
Sent from the jQuery Plugins mailing list archive at Nabble.com.
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/