W3C home > Mailing lists > Public > www-tag@w3.org > September 2009

image width, height, algorithmic specifications

From: Larry Masinter <masinter@adobe.com>
Date: Thu, 3 Sep 2009 10:56:57 -0700
To: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118DB9AC575@nambx04.corp.adobe.com>

I wanted to try to wrap up the question about
width and height depending on "available" --
probably impossible, but I thought I would
at least summarize where I thought things stood,
will probably not be able to respond for
a couple of weeks.

I was trying to chase down examples of the comment
the document frequently states requirement specifications
in terms of implementation techniques for "browsers",
and to do so by looking at a random sample of pages. 

The first page I looked at  contained the
algorithm for "image.width" and "image.height".

(The second page contained the "outline" algorithm;
the next page has the "select" element, won't 
have time for that, although the charset sniffing
algorithms also fit into this category.)

In the discussion of image.width and image.height,
some additional requirements that aren't clearly
stated in the document became apparent (the document
was updated.)

The document requires a state "available", and a 
transition diagram between states, that 
images can go from "not available" to "available"
once they have started loading, but (I am told,
but don't see from the document) an image
can go from "available" to "not available" if the
fetch of the image fails. To model this properly,
an implementation would need at least 3 states
for an image (not-yet-available, available,
once-available-but-failed) and a real implementation
would probably have more, but the requirements
would have to have at least three.

I described a hypothetical implementation -- 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 browser constraint.

I'm not sure where this data comes from -- 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? Is this an
argument by authority, on what Javascript programmers
do or don't do? Was this requirement in any
previous specification?

I argued that this might be an unnecessary
constraint, but if there's some evidence
that it's actually necessary, perhaps
it SHOULD be that both .width and .height
are simultaneously available or not, but
I’m not convinced the requirement needs to
be a MUST.

It's more of a concern that the requirement
that an image not be able to go from
"available" to "not available" and then
back to "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", because if fetching it
a second time were to fail, have an network
error, then it should be "unavailable", no?

So, if I'm running Chrome on Flikr, and I
open up my "set" of 70,000 photos, and there
are only some thumbnails visible, and I scroll
the window, which causes some new thumbnails
to be loaded, and then go back -- 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.

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.

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.

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 a (incompletely
specified) algorithm.

But there is actually no 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.

Received on Thursday, 3 September 2009 17:57:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:15 GMT