Rails spinoffs - Sep 2006 - in IE, checkboxes in sortables become reset when moved?

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.
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
?
Or is there something else I can be doing to work around this?
Any suggestions welcome.

thanks             philipp

  <ul id="section1">
    <li id="item_1" class="lineitem"><input
type="checkbox"
checked="checked"/> This is item 1</li>
    <li id="item_2" class="lineitem"><input
type="checkbox"/>This is item
2</li>
  </ul>

<script type="text/javascript">
    // <![CDATA[
   
Sortable.create(''section1'',{tag:''li'',only:''lineitem''});
    // ]]>
 </script>


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---

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: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---

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
<tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org>
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: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---

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             philipp

On 10/1/06, Philipp Hanes
<philipp.hanes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
<tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> 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: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
> >
> > > >
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---

So, I''ve found a reference to this, in general.
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
<philipp.hanes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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             philipp
>
> On 10/1/06, Philipp Hanes
<philipp.hanes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> 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: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
> > >
> > > > > >
> > >
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---