[mochikit] Re: input disabled attr

2006-01-12 Thread Mike Shaver 

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

2006-01-11 Thread chris feldmann 
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);};
[...]
input type=text  disabled=true id=in1/
[...]

chris

[mochikit] Re: input disabled attr

2006-01-11 Thread Eugene Lazutkin 


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

2006-01-10 Thread mario ruggier 


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

2006-01-10 Thread Bob Ippolito 



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

2006-01-10 Thread Mike Shaver 

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 input
disabled and input disabled=disabled, 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

2006-01-09 Thread Bob Ippolito 



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