[mochikit] Re: input disabled attr
On Jan 10, 2006, at 10:20 PM, Bob Ippolito wrote: Strange, because checking with Safari 1.3.1, the same problem occurs. Also, I realize I did not have the latest FireFox, so I have now tried it with a newly installed 1.5, that however gives the same problem. This is on OS X 10.3.9. So, to repeat, following call does not enable a previously disabled input element: setNodeAttribute(input, 'disabled', false); Can the problem be coming from beyond the browser? Please post a full example that demonstrates what it does do and what it should do and I'll look into it myself. Seems to be behave exactly as Mike and Eugene have described. In any case here's a simple example to show exactly what is going on. If use of disabled (or any boolean attribute) should be avoided, what should one use instead? Title: disabled attribute Setting the disabled attribute on an input element, via _javascript_ and via DOM (mochikit's setNodeAttribute()). Note that setting any value, be it false or even null, on the DOM attribute will cause the boolean disabled attribute to evaluate to true. Behaviour seems to be consistent across browsers (at least on FF 1.5 and Safari 1.3.1 on OS X 10.3.9). mario
[mochikit] Re: input disabled attr
Mike Shaver wrote:
On 1/11/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
I am not against its use in form elements. It is useful indeed. But it
is handled differently in different browsers mostly because of
deficiency of the standard. That was my warning about.
I believe that you can use the attribute reliably in all browsers, if
you stick to this pattern:
- to disable, add the attribute: elt.setAttribute("disabled", "disabled")
- to re-enable, remove the attribute: elt.removeAttribute("disabled")
I don't know of any browsers that don't support that model, but I will
confess that I haven't tested it explicitly in a while.
It was not so at least a couple years ago --- I was bitten by it once on
IE. I don't recall what version it was.
If you look in MSDN reference I gave in my response
(http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/disabled_0.asp)
you will see that "disabled" is defined as a boolean property.
"setAttribute" documentation requires to provide a boolean value for
such properties:
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/setattribute.asp.
It doesn't mean that your pattern doesn't work in IE. It means it is not
documented for IE => it uses undocumented behavior, which is not reliable.
That is why I think that "disable" is one of the most screwed up
attributes. :-)
Thanks,
Eugene
[mochikit] Re: input disabled attr
On 1/11/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> I am not against its use in form elements. It is useful indeed. But it
> is handled differently in different browsers mostly because of
> deficiency of the standard. That was my warning about.
I believe that you can use the attribute reliably in all browsers, if
you stick to this pattern:
- to disable, add the attribute: elt.setAttribute("disabled", "disabled")
- to re-enable, remove the attribute: elt.removeAttribute("disabled")
I don't know of any browsers that don't support that model, but I will
confess that I haven't tested it explicitly in a while.
Mike
[mochikit] Re: input disabled attr
On Jan 11, 2006, at 9:26 PM, chris feldmann wrote:
On 1/10/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
+1. I covered a similar question here:
http://article.gmane.org/gmane.comp.web.dojo.user/2307/
To sum it up: "disabled" is one of the most screwed up attributes. Try
to avoid it, if possible.
I can't agree with this at all; it is often useful to disable and
re-enable form elements. You can use the regular DOM function
removeAttribute():
window.onload=function(){$("in1").removeAttribute("disabled");};
[...]
[...]
Thanks! I mailed yesterday asking what to use instead, but message has
not shown up here yet. Anyhow, that said, it is a rather confusing type
of attribute (all boolean x/html attributes will behave in this way?),
especially when I remember that I had already come across this issue
some time ago, and still am surprised by it... good indication that it
is screwed up.
mario
[mochikit] Re: input disabled attr
chris feldmann wrote: To sum it up: "disabled" is one of the most screwed up attributes. Try to avoid it, if possible. I can't agree with this at all; it is often useful to disable and re-enable form elements. You can use the regular DOM function removeAttribute(): I am not against its use in form elements. It is useful indeed. But it is handled differently in different browsers mostly because of deficiency of the standard. That was my warning about. Thanks, Eugene
[mochikit] Re: input disabled attr
On 1/10/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> +1. I covered a similar question here:
> http://article.gmane.org/gmane.comp.web.dojo.user/2307/
>
> To sum it up: "disabled" is one of the most screwed up attributes. Try
> to avoid it, if possible.
I can't agree with this at all; it is often useful to disable and
re-enable form elements. You can use the regular DOM function
removeAttribute():
window.onload=function(){$("in1").removeAttribute("disabled");};
[...]
[...]
chris
[mochikit] Re: input disabled attr
+1. I covered a similar question here: http://article.gmane.org/gmane.comp.web.dojo.user/2307/ To sum it up: "disabled" is one of the most screwed up attributes. Try to avoid it, if possible. Thanks, Eugene Mike Shaver wrote: On 1/10/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Sounds like you've probably found a bug in Firefox. I don't see anything in the code that should cause that behavior. My reading of HTML 4 is that "disabled" is a boolean attribute, meaning that having it present with any value[*] renders the input disabled, and to re-enable it requires that the attribute is removed, not set to the string "false" or "FALSE" or "0" or "no, thank you", etc.. [*] Actually, it seems that the only legal constructs are and , and all else is undefined. http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.3.4.2 "Some attributes play the role of boolean variables (e.g., the selected attribute for the OPTION element). Their appearance in the start tag of an element implies that the value of the attribute is "true". Their absence implies a value of "false"." Setting the JS property .disabled to a false boolean value is equivalent to removing the attribute via the DOM. Mike
[mochikit] Re: input disabled attr
On 1/10/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > Sounds like you've probably found a bug in Firefox. I don't see > anything in the code that should cause that behavior. My reading of HTML 4 is that "disabled" is a boolean attribute, meaning that having it present with any value[*] renders the input disabled, and to re-enable it requires that the attribute is removed, not set to the string "false" or "FALSE" or "0" or "no, thank you", etc.. [*] Actually, it seems that the only legal constructs are and , and all else is undefined. http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.3.4.2 "Some attributes play the role of boolean variables (e.g., the selected attribute for the OPTION element). Their appearance in the start tag of an element implies that the value of the attribute is "true". Their absence implies a value of "false"." Setting the JS property .disabled to a false boolean value is equivalent to removing the attribute via the DOM. Mike
[mochikit] Re: input disabled attr
On Jan 10, 2006, at 11:24 AM, mario ruggier wrote: On Jan 10, 2006, at 6:34 PM, Bob Ippolito wrote: The only thing it does it call into updateNodeAttributes, which will rewrite a few of the names for IE compatibility (e.g. class - > className) and let you use an object to set a bunch of nested properties (e.g. with the style object). Technically it uses setNodeAttribute(input, attrname, value) rather than input [attrname] = value, so the names it's using should match XHTML, not JavaScript, conventions. Thanks a lot for the explanation. Sounds like you've probably found a bug in Firefox. I don't see anything in the code that should cause that behavior. Strange, because checking with Safari 1.3.1, the same problem occurs. Also, I realize I did not have the latest FireFox, so I have now tried it with a newly installed 1.5, that however gives the same problem. This is on OS X 10.3.9. So, to repeat, following call does not enable a previously disabled input element: setNodeAttribute(input, 'disabled', false); Can the problem be coming from beyond the browser? Please post a full example that demonstrates what it does do and what it should do and I'll look into it myself. -bob
[mochikit] Re: input disabled attr
On Jan 10, 2006, at 6:34 PM, Bob Ippolito wrote: The only thing it does it call into updateNodeAttributes, which will rewrite a few of the names for IE compatibility (e.g. class -> className) and let you use an object to set a bunch of nested properties (e.g. with the style object). Technically it uses setNodeAttribute(input, attrname, value) rather than input[attrname] = value, so the names it's using should match XHTML, not JavaScript, conventions. Thanks a lot for the explanation. Sounds like you've probably found a bug in Firefox. I don't see anything in the code that should cause that behavior. Strange, because checking with Safari 1.3.1, the same problem occurs. Also, I realize I did not have the latest FireFox, so I have now tried it with a newly installed 1.5, that however gives the same problem. This is on OS X 10.3.9. So, to repeat, following call does not enable a previously disabled input element: setNodeAttribute(input, 'disabled', false); Can the problem be coming from beyond the browser? mario
[mochikit] Re: input disabled attr
On Jan 10, 2006, at 8:49 AM, mario ruggier wrote: On Jan 10, 2006, at 7:57 AM, Bob Ippolito wrote: On Jan 9, 2006, at 12:40 PM, mario ruggier wrote: confused... using setNodeAttribute() to set the "disabled" attribute of an input html element seems to do nothing, but setting it directly works fine. I.e. setNodeAttribute(input, 'disabled', true); setNodeAttribute(input, 'disabled', false); seems to not do anything, but the following does what I expect: input.disabled = true; input.disabled = false; What am I missing? Try it with svn trunk, I think 1.1 had a problem with that function. Good, thanks. Thought it was something more mysterious. Just tried with trunk head, and, replacing the packed file that I am using, it still does not work. If it is of any help, it is trying to set it to false that fails... i.e. trying to un-disable it. Setting it to true succeeds. FF on OS X. Irrespective of this temporary issue, in this particular case the raw way of doing is clearer. What are the potential problems though with doing it that way? Are there x-browser glitches I am protected from? Or, in general, what are the advantages of setting attributes via setNodeAttribute()? E.g. - can use a variable to specify the attr name (but can't I also do input[attrname] = true?) That's not an advantage - ??? The only thing it does it call into updateNodeAttributes, which will rewrite a few of the names for IE compatibility (e.g. class -> className) and let you use an object to set a bunch of nested properties (e.g. with the style object). Technically it uses setNodeAttribute(input, attrname, value) rather than input[attrname] = value, so the names it's using should match XHTML, not JavaScript, conventions. Sounds like you've probably found a bug in Firefox. I don't see anything in the code that should cause that behavior. -bob
[mochikit] Re: input disabled attr
On Jan 10, 2006, at 7:57 AM, Bob Ippolito wrote: On Jan 9, 2006, at 12:40 PM, mario ruggier wrote: confused... using setNodeAttribute() to set the "disabled" attribute of an input html element seems to do nothing, but setting it directly works fine. I.e. setNodeAttribute(input, 'disabled', true); setNodeAttribute(input, 'disabled', false); seems to not do anything, but the following does what I expect: input.disabled = true; input.disabled = false; What am I missing? Try it with svn trunk, I think 1.1 had a problem with that function. Good, thanks. Thought it was something more mysterious. Just tried with trunk head, and, replacing the packed file that I am using, it still does not work. If it is of any help, it is trying to set it to false that fails... i.e. trying to un-disable it. Setting it to true succeeds. FF on OS X. Irrespective of this temporary issue, in this particular case the raw way of doing is clearer. What are the potential problems though with doing it that way? Are there x-browser glitches I am protected from? Or, in general, what are the advantages of setting attributes via setNodeAttribute()? E.g. - can use a variable to specify the attr name (but can't I also do input[attrname] = true?) - ??? Thanks, mario
[mochikit] Re: input disabled attr
On Jan 9, 2006, at 12:40 PM, mario ruggier wrote: confused... using setNodeAttribute() to set the "disabled" attribute of an input html element seems to do nothing, but setting it directly works fine. I.e. setNodeAttribute(input, 'disabled', true); setNodeAttribute(input, 'disabled', false); seems to not do anything, but the following does what I expect: input.disabled = true; input.disabled = false; What am I missing? Try it with svn trunk, I think 1.1 had a problem with that function. -bob
