Re: image width & height, summary

On Tue, Jun 2, 2009 at 10:45 PM, Larry Masinter <masinter@adobe.com> wrote:
> 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.  In the
> case of image width and height, that would involve expressing the
> constraints on the values of width and height; if it's
> necessary to describe the states an image can be and
> constraints on state transition, that's fine but it's
> not clear that it's even necessary.
>
> 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.

I think this is where the core of the difference in views comes from.

Many people, not just you, have suggested what basically comes down to
"If we tell people they can't rely on X, they won't". At its most
extreme, this manifests itself in the argument "people won't rely on
unspecified behavior". As a browser developer, this does not match my
experience.

My experience is that people develop by writing a page, test it mostly
in one browser, and then deploy. Good developers, generally
professional companies, test in several browsers before releasing.

As a direct consequence of this, as long as something works
consistently in a few browsers, it's likely that developers will
become dependent on it. So to use the example used here, if one
browser load all the images before firing the 'load' event, and keep
all the image data around for synchronous access, it's likely that
sites will come to depend on it, no matter if the spec doesn't have
this as a requirement, or even if the spec explicitly says that it's
undefined.

For a while, when IE had a 90+% marketshare, it was enough that
something worked in one browser for people to become dependent on it.
innerHTML is an example of one such thing. It was originally available
only in IE, but we eventually had to add support for it to gecko (i.e.
netscape at the time) since sites wouldn't work without it.

I'd love it if we were able to catch this in a design principle.
Something to the effect that many HTML authors write HTML without
looking at the spec and instead just test in a user-agent (or HTML
interpreter, consumer, or whatever was decided was the appropriate
term). And that we should write the spec with this reality in mind.

The only way that I can think of to ensure that authors won't come to
depend on a given behavior is to ensure that depending on it breaks in
all browsers, and break a lot. For example if we made image.width
return 0 25% of the time in all browsers, whether they have the
information available or not, developers would probably not come to
depend on it always being available. But I'm not sure how we could get
all browsers to do that, other than explicitly specifying that that is
what is they MUST do. (apart from the fact that they still wouldn't do
it since it'd currently break too many sites).

I hope this makes sense? I'd love it if we could leave thing
explicitly undefined and be able to trust that people wouldn't rely on
it. But so far I have simply not found that to be true.

/ Jonas

Received on Thursday, 4 June 2009 02:18:13 UTC