Prev: print(), iframe, IE 5/6
Next: Request.Form in Javascript
From: Thomas 'PointedEars' Lahn on 22 Dec 2007 05:14
AKS wrote:
> On Dec 22, 4:10 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> wrote:
>
>> The logical course of action should be clear then:
>
> "should be clear"? Not absolutely. What do you check here:
>
>> if (o && isMethod(o, "focus")
>> && typeof o.style == "undefined"
>> || typeof o.style.visibility != "undefined")
>
> ?

The element object must have a focus() method. If it has, then either it
does not support a `style' object or if it does, it has to support the
`visibility' property.

> To avoid an error, it should look like this:
>
> if (o && isMethod(o, "focus") &&
> typeof o.style != "undefined" &&
> typeof o.style.visibility != "hidden")

I took into account that the element may be focused if there was no CSS
scripting support (with the assumption that then there was no CSS support
and the element could not be hidden), while your "correction" would not
allow the element to receive focus then.

> But in IE it is still dangerous. Because style can be specified in css

It would already "be specified in css" in the `style' attribute value of the
element. You mean instead "specified in a document-global or linked
stylesheet".

> or can be inherited from the parent (hidden) element.
> Then your check is useless.

True. However, that occasion is something that can be tested for as well.
Quick hack:

function _getComputedStyle(o, p)
{
var s;

if (typeof document.defaultView != "undefined"
&& isMethod(document.defaultView, "getComputedStyle")
&& (s = document.defaultView.getComputedStyle(o, null))
&& isMethod(s, "getPropertyValue"))
{
return s.getPropertyValue(p);
}
else if (typeof o.currentStyle != "undefined"
&& typeof o.currentStyle[p] != "undefined")
{
return o.currentStyle[p];
}

return s;
}

function isHidden(o)
{
while (o)
{
if (typeof o.style == "undefined"
|| typeof o.style.visibility != "undefined"
&& /hidden/i.test(o.style.visibility)
|| /hidden/i.test(_getComputedStyle(o, "visibility"))
{
return true;
}

o = o.parentNode;
}

return false;
}

function focusElement(s)
{
var o = document.getElementById(s), s;
if (o && isMethod(o, "focus") && !isHidden(o))
{
o.focus();
}
}

Nevertheless, when observing this much of (feature) testing for one simple
call, this is one of the occasions where I wish that there was a universally
supported and easily scriptable DOM interface -- or at least that exception
handling was universally supported, for

try
{
o.focus();
}
catch (e)
{
}

is simply much more beautiful than the above, while the former might not
even suffice (consider `disabled').

>> One might also want to employ exception handling (try...catch)...
>
> And one might (who don't care about IE older 5.5) also want to employ
> this safety method:
>
> o.setActive();

I don't see why that would qualify as a "safety method". It does a
completely different thing:

| setActive Method
|
| Sets the object as active without setting focus to the object.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Randy Webb on 22 Dec 2007 05:37
Thomas 'PointedEars' Lahn said the following on 12/22/2007 5:14 AM:
> AKS wrote:

<snip>

>> or can be inherited from the parent (hidden) element.
>> Then your check is useless.
>
> True. However, that occasion is something that can be tested for as well.
> Quick hack:

And untested or you would have fixed the errors in it. Nor does it deal
with the explicit case where I showed you it would fail.

Case 1:
<div style="display:none">
<input type="radio" id="search" disabled>
</div>

Case 2:
<input type="hidden" id="search">

Enjoy.

<URL: http://www.jslint.com/>

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
From: AKS on 22 Dec 2007 06:59
On Dec 22, 3:14 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> I don't see why that would qualify as a "safety method". It does a
> completely different thing:
>
> | setActive Method
> |
> | Sets the object as active without setting focus to the object.

Ok, good quote. But let's get back into the real world.
Test this (only in IE, of course):

<script type='text/javascript'>

function F() {
var o = document.getElementById('search');
if (o && (o = o.setActive)) {
o();
};
};

</script>

<body onload='F()'>

<input type='text' id='search' onfocus='window.status =
event.type'>

</body>






From: David Mark on 23 Dec 2007 01:32
On Dec 22, 5:14 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> AKS wrote:
> > On Dec 22, 4:10 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> > wrote:
>
> >> The logical course of action should be clear then:
>
> > "should be clear"? Not absolutely. What do you check here:
>
> >>         if (o && isMethod(o, "focus")
> >>             && typeof o.style == "undefined"
> >>             || typeof o.style.visibility != "undefined")
>
> > ?
>
> The element object must have a focus() method.  If it has, then either it
> does not support a `style' object or if it does, it has to support the
> `visibility' property.
>
> > To avoid an error, it should look like this:
>
> > if (o && isMethod(o, "focus") &&
> >         typeof o.style != "undefined" &&
> >         typeof o.style.visibility != "hidden")
>
> I took into account that the element may be focused if there was no CSS
> scripting support (with the assumption that then there was no CSS support

That is a bad assumption. For instance, it is well known that some
CSS-enabled agents do not allow certain style properties to be updated
with script (display being the most common.) Testing whether these
properties are strings is a good indication as to whether scripted
updates will have any effect. These tests do not exclude the
possibility of the rules being applied with style sheets.

> and the element could not be hidden), while your "correction" would not
> allow the element to receive focus then.
>
> > But in IE it is still dangerous. Because style can be specified in css
>
> It would already "be specified in css" in the `style' attribute value of the
> element.  You mean instead "specified in a document-global or linked
> stylesheet".
>
> > or can be inherited from the parent (hidden) element.
> > Then your check is useless.

That isn't true for visibility rules (though it is for display.)

>
> True.  However, that occasion is something that can be tested for as well.

No, it is false in this case.

> Quick hack:

Not one of those.

>
>   function _getComputedStyle(o, p)
>   {
>     var s;
>
>     if (typeof document.defaultView != "undefined"
>         && isMethod(document.defaultView, "getComputedStyle")
>         && (s = document.defaultView.getComputedStyle(o, null))
>         && isMethod(s, "getPropertyValue"))
>     {
>       return s.getPropertyValue(p);
>     }
>     else if (typeof o.currentStyle != "undefined"
>              && typeof o.currentStyle[p] != "undefined")
>     {
>       return o.currentStyle[p];
>     }
>
>     return s;
>   }

Mixing cascaded and computed styles is an error-prone approach. This
wouldn't work for display rules.

>
>   function isHidden(o)
>   {
>     while (o)
>     {
>       if (typeof o.style == "undefined"
>           || typeof o.style.visibility != "undefined"
>           && /hidden/i.test(o.style.visibility)
>           || /hidden/i.test(_getComputedStyle(o, "visibility"))

This will error if _getComputedStyle returns an undefined result.

>       {
>         return true;
>       }
>
>       o = o.parentNode;

This is wrong. If the computed, cascaded or inline style is visible,
then there is no reason to check the parent node(s). As mentioned,
display rules are a different story. So this function is worthless
for what is designed to do.

>     }
>
>     return false;
>   }
>
>   function focusElement(s)
>   {
>     var o = document.getElementById(s), s;
>     if (o && isMethod(o, "focus") && !isHidden(o))
>     {
>       o.focus();
>     }
>   }
>
> Nevertheless, when observing this much of (feature) testing for one simple
> call, this is one of the occasions where I wish that there was a universally
> supported and easily scriptable DOM interface -- or at least that exception
> handling was universally supported, for
>
>   try
>   {
>     o.focus();
>   }
>   catch (e)
>   {
>   }

If an application doesn't know when it is safe to focus an element,
then it can lean on this crutch. Other than the remote possibility of
an !important user style hiding an element, this issue shouldn't come
up.

>
> is simply much more beautiful than the above, while the former might not
> even suffice (consider `disabled').

It won't even come close. And hopefully nobody will post an addendum
that tests for disabled elements as there is no way to do that
reliably either.
From: AKS on 23 Dec 2007 01:38
On Dec 23, 10:51 am, David Mark <dmark.cins...(a)gmail.com> wrote:

> > o.setActive();
>
> That does something else.

What exactly? And what's the difference? Did you test code snippet
from my previous post?

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: print(), iframe, IE 5/6
Next: Request.Form in Javascript