[whatwg] Scripting Tweaks

[Dean Edwards]

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