[whatwg] Scripting Tweaks
Dean Edwards
dean at edwards.name
Wed Apr 20 08:18:09 PDT 2005
Ian Hickson wrote:
> On Wed, 20 Apr 2005, Dean Edwards wrote:
>
>>>So you'd submit to a hidden <iframe> and then disable the main page?
>>
>>Yep. The iframe then unlocks the page when submission is complete.
>>Forgetting about iframes for a minute. This is analogous to disabling
>>the entire application (not the chrome). Most GUI apps have this
>>behavior to some degree.
>
>
> Most GUI applications don't have the possibility of the network dying and
> never re-enabling the page. :-)
>
>
True. However, if the network dies the page is not going to reflect that
anyway. I've seen many users continuing to click submit because they
don't get immediate feedback. A good server application will handle this
of course. But this would not be an issue in a GUI which would usually
disable its interface when processing. Remember, I'm talking about
disabling the page /not/ the browser.
>
>>>>I can't think of one off the top of my head but I do find myself
>>>>using it. It's certainly handy for passing string references around
>>>>rather than object references.
>>>
>>>Wouldn't object references by lighter weight?
>
> I beg to differ:
>
> elem[i].disabled = true;
> setTimeout(function () { elem[i].disabled = false }, 1);
>
> That looks a lot easier than the eval() to me. And shorter. And it will
> have syntax errors caught at compile time.
>
Yes, but as I said initially, that creates a closure. This is not always
the most efficient solution. Your code won't work anyway because "i" is
variable. The closure would need to be more complicated to work properly.
> Is there another use case? :-)
>
OK. You're making me work hard here. :-)
If I want to build a list of elements that I've already processed:
var processed = {};
for (var i in elements) {
if (!processed[elements[i].uniqueID]) {
process(elements[i]);
processed[elements[i].uniqueID] = true;
}
}
I can't think of another way of doing that.
-dean
More information about the whatwg
mailing list