http://www.quirksmode.org/bugreports/archives/2004/10/moving_checkbox.html
Seems it's a known IE6 issue (unclear when it got fixed in IE7).
I can hack around it in the copy of dragdrop.js that I'm using, but I'm a little hesitant to commit anything back to the version control here.
Is there an accepted process for reviewing? Or could someone more confident than myself take a stab at fixing it?
Or is it even worth putting in?
I assume it would involve a lot of most-of-the-time-unnecessary DOM traversal before and after every insertBefore() call. Not too expensive unless you're draggin/dropping some deeply nested stuff, I guess.
Anyway, Christophe, or anyone else reading this. Let me know what you think can/should be done about this.
thanks philipp
On 10/4/06, Philipp Hanes <[EMAIL PROTECTED]> wrote:
So, a colleague of mine has informed me that my sampkle does *not* display this behavior in the IE 7 that he has installed.
I have only looked at it in IE 6 (not idea, for that matter how older versions behave).
I suppose this shrinks the pool of people who would even be willing/able to look into it a little.
I haven't had the time to dig further myself, and may have to work around the problem some other way for this particular project.
But if someone could confirm that they are seeing this too, on the sample I out up, that would be helpful.
thanks philippOn 10/1/06, Philipp Hanes < [EMAIL PROTECTED]> wrote:I've pasted my original attachment into a simple HTML page at
http://www.philipphanes.com/test/dragcheck.html
which displays this behavior.
Hope you can see something I'm not seeing (wouldn't surprise me).
Thanks for taking a look.On 9/30/06, Christophe Porteneuve < [EMAIL PROTECTED]> wrote:
Philipp Hanes a écrit :
> The code below works fine in Firefox (Windows), but in IE when I change
> the state of one of the checkboxes, and then drag it past the other one,
> it reverts to its initial state.
> This only affects the one that's actively being dragged.
Obviously there is some issue with how IE implements the methods used by
the drag code. But s.a.us does not seem to rely on HTML representations
for this, which may have explained your checked status going to limbo.
Maybe IE's cloneNode DOM method skips the checked property, but it is
only used for ghosting, and your sample code doesn't enable ghosting, so
that shouldn't be it also. Do you have a working demo online for this
issue?
> This might be a problem in prototype's serialization not handling the
> distinction between"defaultChecked" and "checked" that's mentioned in
> http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerProgrammingBugs
Actually, Prototype's behavior is correct in using the current state of
the checkbox (the checked property) for serialization, since the
*original* state (defaultChecked) is not what we're going after.
The bug you mention highlights the necessity for the input to be in the
DOM already before using the checked property, while the defaultChecked
property is intended for initially setting the state.
--
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
