[whatwg] Scripting Tweaks

[Ian Hickson]

On Wed, 20 Apr 2005, Dean Edwards wrote:
> 
> 1) Mozilla's DOMContentLoaded event is very handy. It fires when a 
> node's content has been loaded and parsed (the DOM has been 
> constructed). This is much better than the standard onload event as it 
> doesn't wait for binary content to also load.

Added.


> 2) I'd like to be able to lock/disable an entire document. This is 
> useful when submitting to hidden frames. It helps prevent users from 
> re-submitting data before it has been processed. Ideally, I could 
> disable an entire frameset. Better yet, I can display some kind of 
> visual feedback so that the user knows the page is locked (e.g. 
> hourglass, greyed out content).

I considered this some more, and it really seems that giving the author an 
explicit way to disable the entire content is somewhat against some of the 
principles of the Web. You can work around the lack of this by having a 
<section> that you position using CSS over the whole viewport, or by 
disabling all submit buttons, or putting all buttons in a <fieldset> and 
disabling that, or any number of other mechanisms, but I don't think we 
should have a way to disable the page. I can just imagine the kinds of 
problems that would occur if this were to be introduced.


> > 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.

Actually now it could; we've introduced events to handle that case.


> 3) I find myself using Microsoft's uniqueID property quite often. Although the
> ID attribute is supposed to provide a unique identifier, it often doesn't. We
> would probably need a complementary DOM method to retrieve an element by
> uniqueID (IE uses the "all" property).
> 
> http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/uniqueid.asp
>
> 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.

   for (var i in elements) {
     if (!elements[i].processed) {
       process(elements[i]);
       elements[i].processed = true;
     }
   }
   for (var i in elements)
     delete elements[i].processed;

The "uniqueID" thing is really working around a deficiency in JS 
(inability to use objects as keys). I think that's where it should be 
addressed. The uniqueID idea has a number of rather unique implementation 
difficulties. The obvious implementations have security and privacy 
implementations; the solutions to those tend to be expensive either in RAM 
or CPU. I recommend bringing this to the attention of the ES4 group.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'