W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Language specification vs. user agent specification

From: Larry Masinter <masinter@adobe.com>
Date: Sun, 24 May 2009 13:26:06 -0700
To: HTML WG <public-html@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118CD8A48AC@nambx04.corp.adobe.com>
In the discussion around the document title (and process issues
around that), there is at least some actual technical content.

 (1) "traditional language"

In reply to my suggestion:
>> It might be possible to create a more traditional language definition 
>> using the bulk of the material, but expressed in less operational terms. 

Ian asked:
> What do you mean by "a more traditional language definition" and why would 
> this be desireable?

I think it is traditional to define a language and its semantics
first -- what does an utterance in the language *mean* and separately
and independently (even if the same document) define conformance
requirements for processors of that language. The current document
frequently does not do that, but defines the processing requirements
and then infers the language semantics from that.

I think this is why there are persistent discussions of it as a "browser spec" 
despite the attempts to define other conformance requirements.

Defining things as language-first is more useful and easier
to read than the current editorial style, especially for end-users
and authors of HTML documents, whose priority over implementers is
a stated design goal. Further, it allows clearer evaluation of
whether the design "goes too far" in locking down implementation
behavior unnecessarily, because, even though testable, in practice
the implementation conformance requirement is unnecessary.

I took as an example (randomly selected) image.width and image.height
defined in terms an algorithm for determining them based on whether
the image was "available", and that "available" wasn't well defined,
and that I would have to guess whether an image defined with "data:"
was or wasn't available. 

Ian replied: 
> Why would you have to guess? It is in fact fully-defined: the scheme is 
> orthogonal to the issue, it only depends on whether the image, once 
> obtained, is of a supported type and is a valid image of that type.

I think the notion of "available" isn't precisely defined, and I don't
think it can be defined precisely in a way that doesn't hamper future
implementation innovation unnecessary. 

For example, if the representation of an image URI has only been partly
retrieved, such that the width and height are known, but the rest of the
image data is not known -- is the image "available"? How much of the
image needs to be "available"? 

If I know the image width and height, but not whether it is of a supported
type, is it "available"? What if I have a processor for which support
for image types are dynamically downloadable, and so whether the image
is a "supported type" depends on the state of the download mechanism

Is an implementation which returns the correct width and height
even if the image itself is not "available" -- is it non-compliant?
What if I know with 95% certainty what the image width and height are,
but there is some asynchronous process checking the validity of that?
Are image.width and image.height allowed to change?

If I have some other way of inferring the width and height of an 
image without accessing the image itself, is the image "available"?

If, for example, I am building a summarizer which wants to know
which images are visible and which ones aren't, I might want 
JavaScript programs to have access to image.width and image.height
even if the image isn't retrieved or even retrievable.

I think defining image.width and image.height in terms of processing
requirements is unnecessary, introduces conformance requirements
that MUST be followed that at first look may seem to be precise
but in fact are not, and don't actually help end-users or authors.

Perhaps no browsers currently implement any of the extensions or
pipelined image retrieval, but authors should not be encouraged
to create JavaScript applications that depend on the fact that
image.width is known to infer that the image is "available" for
any other purpose, which is implied by the current spec.

Even if it were possible to nail down exactly what "available" 
is or isn't, doing so is a bad idea, unnecessary, and the basis
for what I was saying was "short-sighted": trading short-term
consistency against long-term extensibility. 

Received on Sunday, 24 May 2009 20:26:53 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC