Quantcast

Re: IE bug affecting widgets

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IE bug affecting widgets

Bill Keese-2
Hmm, I didn't about / had forgotten about this.  I guess the upshot is
that you should never say disabled="false".  Just don't have anything.

James Talmage wrote:

> Found this wierd IE behavior when I tried to use a property called
> "disabled" in a widget and set it via html attributes.  Below is a
> simple html document that I created to illustrate the problem.
>  
>  
>  
> <html>
> <script type="text/javascript">
>     function doTest(divId){
>         var x = document.getElementById(divId);
>         alert(divId + ": " + x.getAttribute("disabled"));
>     }
>     function onLoad(){
>         doTest("testDiv1");
>         doTest("testDiv2");
>         doTest("testDiv3");
>     }
> </script>
> <body onload="onLoad();">
> <div id="testDiv1" ></div>
> <div id="testDiv2" disabled="true"></div>
> <div id="testDiv3" disabled="false"></div>
> </body>
> </html>
>  
>  
>  
> The results for IE and Firefox were as follows:
>  
>                
>                          Firefox             IE
> testDiv1            null                   false
> testDiv2            true                  true
> testDiv3            false                true
>  
>  
>  
> In other words, IE automatically creates an attribute called
> "disabled",  if the html specifies an attribute called "disabled" the
> value of the attribute via JS is true, no matter what value is actuall
> specified.  If the attribute is not specified in the html an attempt to
> retrieve it will return "false", not null as is the case with any other
> attribute name.
>  
> One thing I did notice is that the dojo widget parser is able to
> distinguish whether or not the "disabled" attribute is declared in the
> html.  If a widget prototype declares a boolean property "disabled" that
> defaults to false, that default value is not changed if the html
> decleration does not specify the disabled attribute, but it's always set
> to true no matter what value is assigned in the html.
>  
> Is this a known issue?
> Are there other property names that display this kind of wierdness?
> Is there a way for the parser to get around this and set the correct value?
>  
> This should get documented in big bright letters.
>  
>  
> --James
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dojo-interest mailing list
> [hidden email]
> http://dojotoolkit.org/mailman/listinfo/dojo-interest
_______________________________________________
Dojo-interest mailing list
[hidden email]
http://dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IE bug affecting widgets

Eugene Lazutkin

IE doesn't support a value for the attribute "disabled". The correct usage with <div> is:
 
enabled: <div>...</div>
disabled: <div disabled>...</div>
 
There is a corresponding property "disabled", which is "false" for enabled elements, and "true" for disabled.
 
 
To sum it up: the property value is set by a mere presence of the attribute "disabled". All '="whatever"' will be discarded by IE. Don't rely on this attribute's value to be portable across platforms. And it is safer not to use standard attributes for your widgets anyway.
 
Why is it so? Is it because MS the Evil Empire (tm)? Not in this case. It is because they implemented it according to official HTML 4.01 Specification: http://www.w3.org/TR/REC-html40/interact/forms.html#adef-disabled --- note the example of usage. Another note is it is defined for control only. IE just applied it to all elements instead of ignoring it. Therefore it is not an issue per se and it doesn't qualify as the "weird IE behavior".
 
Thanks,
 
Eugene
 
"James Talmage" <[hidden email]> wrote in message <A href="news:2fbd5c180511281906w13e6d472s58adbd85c7e6c161@mail.gmail.com">news:2fbd5c180511281906w13e6d472s58adbd85c7e6c161@......
Found this wierd IE behavior when I tried to use a property called "disabled" in a widget and set it via html attributes.  Below is a simple html document that I created to illustrate the problem.
 
 
 
<html>
<script type="text/javascript">
    function doTest(divId){
        var x = document.getElementById(divId);
        alert(divId + ": " + x.getAttribute("disabled"));
    }
    function onLoad(){
        doTest("testDiv1");
        doTest("testDiv2");
        doTest("testDiv3");
    }
</script>
<body onload="onLoad();">
<div id="testDiv1" ></div>
<div id="testDiv2" disabled="true"></div>
<div id="testDiv3" disabled="false"></div>
</body>
</html>
 
 
 
The results for IE and Firefox were as follows:
 
                
                         Firefox             IE
testDiv1            null                   false
testDiv2            true                  true
testDiv3            false                true
 
 
 
In other words, IE automatically creates an attribute called "disabled",  if the html specifies an attribute called "disabled" the value of the attribute via JS is true, no matter what value is actuall specified.  If the attribute is not specified in the html an attempt to retrieve it will return "false", not null as is the case with any other attribute name.
 
One thing I did notice is that the dojo widget parser is able to distinguish whether or not the "disabled" attribute is declared in the html.  If a widget prototype declares a boolean property "disabled" that defaults to false, that default value is not changed if the html decleration does not specify the disabled attribute, but it's always set to true no matter what value is assigned in the html.
 
Is this a known issue? 
Are there other property names that display this kind of wierdness?
Is there a way for the parser to get around this and set the correct value?
 
This should get documented in big bright letters.
 
 
--James


_______________________________________________
Dojo-interest mailing list
[hidden email]
http://dojotoolkit.org/mailman/listinfo/dojo-interest

_______________________________________________
Dojo-interest mailing list
[hidden email]
http://dojotoolkit.org/mailman/listinfo/dojo-interest
Loading...