image width & height, summary

I wanted to summarize the discussion about width and height
depending on "available" -- I'd written some of this up.
Again, sorry for the length, I've been editing it down.
Won't be able to respond for a couple of weeks.

I was trying to chase down examples in which to ground the
complaints that the document "frequently" states requirement
specifications in terms of implementation techniques for
"browsers", by looking at a random sample of sections.

The first section I looked at contained the algorithm for
"image.width" and "image.height". In the discussion, some
additional requirements that weren't clearly stated in the
document became apparent, and the document was updated.

The spec, as written, requires a state "available", and a
state transitions such that images can go from "not
available" to "available" once they have started loading,
but (we are told, not immediately obvious) that while an
image can also go from "available" to "not available" if the
fetch of the image fails, it can't subsequently transition
back to "available". To model this properly, an
implementation would need at least 3 states
(not-yet-available, available, once-available-but-failed)
and a production implementation would require more.

I described a hypothetical implementation (one which didn't
cache anything about images, but rather attempted to fetch
them each time) which might have a state where an image
width was known but the image height not yet known.  Such an
implementation would be "non compliant".  JavaScript
programmers assume that if image.width is known, then
image.height is known, and so it should be a constraint.

I'm not sure where the support for this requirement comes
from, though. How do we know what JavaScript programmers
assume, and why this requirement is necessary? Are there
well-known JavaScript DOM texts which include this
assumption?  Common JavaScript libraries that would fail?
Isn't this just one of many things that might break in a
typical script? Was this requirement in any previous
specification?

Certainly it's handy to have an implementation guide that
shows how something *can* be implemented, but in the current
document, the value constraints here descriptive, but the
algorithm is normative.

There should also be a concern about the requirement that an
image not be able to go back to "available" once it had
transitioned from "available" to "not available".  I think
the implication is that once an image has been loaded, and
is "available" for the second time, that it can't be
unloaded or uncached; fetching it a second time were to
fail, have an network error, that would cause such a state
transition.

For example, imagine running a browser on Flikr, and opening
up a "set" of 70,000 photos, with a HTML page of 70,000
images, but only some of which are visible at any one time.
When I scroll the window, some new thumbnails to be loaded,
and as I scroll around -- does the browser have to have
cached all of the thumbnails that have ever been viewed, in
order to meet this MUST requirement?  This seems like an
unreasonable requirement that might not be met by any
practical implementation. Of course there are buffer limits.
In a specification that is attempting to be precise,
reasonable implementations shouldn't be non-conformant.

Why is something that can't actually be promised -- that all
images on a page MUST be cached once they have been loaded
-- a requirement at all?

If the requirement had been written in terms of constraints
instead, then some of the conformance constraints could be
"SHOULD" and others left as "MUST", at a minimum, e.g.,
something like:

# The image width MUST be 0 or else equal to the CSS width (if
# the image is displayed) or the natural width (if the image
# is non-zero); similarly for image height.

# Image.width and image height SHOULD be both simultaneously
# available. Once they are available (even if the image is
# only sufficiently loaded as to determine that the image
# format is supported and the width and height are known), an
# image MAY later become unavailable due to network errors,
# for example, or if the cache holding their information is
# flushed.

(I know, in my previous example, i used 'is' instead of
'MUST be', but I didn't think that was significant.)

Authors of software and JavaScript libraries would be able
to read and interpret the compliance statements and
understand which constraints they can depend on, without
having to decipher an (incompletely specified) algorithm.

Is there a direct way to check conformance to a 'normative
algorithm' which requires a state ("available") which isn't
actually visible from the API? The implications of the
algorithm-- the only things you can actually check if you're
writing test cases-- are the invariants. And invariants that
might depend on cached, stored state... well, maybe they
should be SHOULD instead of MUST invariants, if there are
plausible implementations that can't guarantee those
invariants in all situations.

Larry
--
http://larry.masinter.net

Received on Wednesday, 3 June 2009 01:51:40 UTC