Re: algorithmic normative conformance requirements, design principles, etc.

Larry Masinter wrote:
> But in fact there is no way to determine if image.width
> and image.height are simultaneously available, because
> 'available' is dynamic. Any program of the form
> 
> 
>   if (image.width != 0) { ... something using image.height ...
>                           which assumes image.height is non-zero ...}
> 
> will not always function properly, if the image becomes
> unavailable between the time image.width is computed
> and when image.height is accessed, because images can
> become "unavailable", because of network congestion, 
> server timeout, delay, etc.

True, but JavaScript on the web has run-to-completion semantics.  That 
means that unless that program has some explicitly asynchronous 
machinery (setTimeout/setInterval/sync XHR/etc) inside that if body, 
whether an image is available cannot in fact change during the program's 
execution.  Heck, even it changing during sync XHR is somewhat 
undesirable (though that happens in at least some UAs right now). 
Certainly network events should not occur during script execution 
normally.  Doing that would break existing scripts quite badly.

> My original point was that this was an instance of
> using algorithmic specification rather than using
> language constraint specification.

That it is, yes.

> Perhaps you'd like to find some part of the spec which
> *isn't* ambiguous or poorly specified in this way?

What's ambiguous or poorly specified here?

> Some single example / page / section which you think
> is completely specified both from a user and client
> point of view?

What do you mean by "user" and "client" here?

-Boris

Received on Thursday, 28 May 2009 02:05:48 UTC