Re: image width & height, summary

Larry Masinter wrote:
>> The browser needs to load all images the page script has access to 
>> before firing the 'load' event.  Anything else breaks pages.
> 
> Where does it say this?

I believe Ian covered this in his reply.

> If I have 5 images, they all have to be available
> before any script runs?

No, before you fire the page's load event.  Note that there are 
exceptions for things like "browsing with images turned off" mode, etc. 
  Also, they don't have to be available; you just have to have finished 
trying to make them so.

Or in non-spec terms, "don't fire the load event until you finish 
loading what you plan to load".

> Well, there are a lot of pages that "assume" things that aren't true;

While true, if they assume things that are currently true in all 
commonly used browsers it might make sense to define these things as 
required from a UA that's trying to actually render the web.

If a UA is not trying to do that, of course, it has a lot more leeway.

> The fact that some high-profile site made an assumption,
> ("all images are available at load time") and some other 
> site made a different assumption ("there is no limit to
> the number of images on a page, because only the visible
> segment of the page images are cached or guaranteed to
> be loaded") and it's impossible to build a browser that
> always satisfies both sets of assumptions, even though
> both sets of assumptions are true *most* of the time  -- 
> what's the design  principle for deciding who wins?
> High-profile sites assumptions are more valuable?

Yes.  And in general, assumptions which would cause things to break more 
for users if violated are the ones you don't want to violate.  This can 
in fact lead to tough choices.

In practice, many many pages rely on the "all images are available at 
load time" assumption and pretty much none rely on the "there are no 
resource limits" assumption, so the choice is easy, in my opinion.

This is all with my browser implementor hat on.

> I believe that from many points of view, it is better to
> have an incomplete set of normative constraints that 
> authors *can* depend on, along with an informative "sample"
> or "example" implementation; if there is an implementation
> guide, it is better for that part to be explanatory.

I'm fine with having an incomplete set of normative constraints authors 
can depend on.  What's needed in addition to that is a complete set of 
normative constraints an implementation must satisfy...  If you think 
those should be the same set, that's fine by me too, as long as the 
latter set is complete in some reasonable sense (there's always a long 
tail effect here, where exact compat with a particular implementation 
might make that one more site work or something, of course).  Yes, 
there's a judgement call as to what constitutes "complete" here.

> This would allow careful authors and authoring tools to create
> robust code that does not rely unnecessarily on assumptions
> that are difficult to ensure, while the algorithmic description
> provides guidance on how to implement something that doesn't
> "break" current pages, or those written with incorrect
> assumptions, while allowing more vendor flexibility.

If in practice all UAs have to implement things a certain way due to the 
fact that current pages in fact rely on it, I'm not sure what we win by 
pretending that a UA could somehow do it some other way and making life 
harder for careful authors by telling them to avoid certain actions on 
the off chance this happens.

Note that in the above paragraph "have" in the first clause is a 
judgement call, as are "rely" and "harder"...  All need to be examined 
on a case-by-case basis; I suspect with the image case in particular UAs 
really do need to behave as the spec says to be usable by actual users 
right now.

> I think what is "normative" -- what is "must" vs 
> what is "should" matters a lot in a technical specification.

Yes, I agree.

> The normative algorithms basically don't distinguish
> between those constraints that are mandatory and those
> that are advisory.

If so, that would be a bug in the algorithm, in my opinion.  But see 
above about must vs should for various cases where "must" might not 
change any actual UA behavior but lead to a more pleasant authoring 
experience.  In this particular case it actually makes sense to have a 
MUST requirement, in my opinion.

> I'm picking on this little example, which doesn't matter
> much in the grand scheme of things, to keep the discussion
> focused on the technology.

And I appreciate that.

> But I think an examination
> of other sections (chosen at random) will bring more
> clarity to the discussion, and make it clear that we're
> actually talking about specification quality, 
> applicability and scope, and not just name-calling.

I don't think anyone's accused you of name-calling.  You'd brought up 
specific technical issues that are very much appropriate to bring up.  A 
number of places in the spec make judgement calls about how something 
should work and whether something should be a SHOULD or MUST 
requirement, and questioning such judgement calls is not at all 
unreasonable....

-Boris

Received on Wednesday, 3 June 2009 16:14:26 UTC