RE: "Technical specification"

On Fri, 22 May 2009, Larry Masinter wrote:
> 
> I think "A vocabulary and associated APIs for HTML and XHTML" doesn't 
> match closely what's in the document. There is a vocabulary (the HTML4 
> vocabulary with additional terms and some terms dropped), but more 
> accurately the document normatively defines functional requirements for 
> implementations of HTML+JavaScript interpreters.

Sure. Defining how a vocabulary works is the most important part of the 
definition of any vocabulary. The fact that HTML4 (amongst other specs) 
fails to do this properly (or at all) is a massive problem which has cost 
the Web community dearly, and it is certainly no excuse to continue making 
the same mistake with new specs. I'm glad to say that more modern specs, 
like XForms or SVG 1.2, are in fact doing the right thing here, as we are 
doing with HTML5.


> So I might suggest something like:
>
> "HTML5: Implementation Requirements for HTML5 interpreters and Related 
> JavaScript APIs"

HTML5 defines the implementation requirements for all conformance classes, 
including validators, editors, authoring tools, search engines, data 
mining tools, interactive renderers (browsers), and static renderers (e.g. 
HTML to PDF converters). Browsers are an important case, but by no means 
the only case that is covered by HTML5.

HTML5 also defines the authoring requirements for producers of HTML5 
content, and indeed it is possible to hide all the content that is not 
intended for HTML5 producers, so focusing on the implementation 
requirements for interpreters rather misses the point, IMHO.


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

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


> Let me try to be more specific. To picked a paragraph at random (but 
> there are hundreds like this):
> 
> " The DOM attributes width and height must return the rendered width and 
> height of the image, in CSS pixels, if the image is being rendered, and 
> is being rendered to a visual medium; or else the intrinsic width and 
> height of the image, in CSS pixels, if the image is available but not 
> being rendered to a visual medium; or else 0, if the image is not 
> available or its dimensions are not known. [CSS21] On setting, they must 
> act as if they reflected the respective content attributes of the same 
> name."
> 
> This tells one how to implement image.width and image.height and what 
> they "must return". The term "available" is not well-defined--

The very same section, a few paragraphs earlier, says:

#   If the image's type is a supported image type, and the image is a 
#   valid image of that type, then the image is said to be available [...]

It is in fact quite well-defined.


> except through providing algorithms for fetching images and predicting 
> the behavior. There's no particular reason to know whether, for example, 
> an image specified through a "data:" URI is "available" or not (I could 
> guess, but I'm not sure) [...]

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.


> A language definition would define the terms more abstractly, not from 
> the perspective of the implementer of an interpreter.
> 
> For example:
> 
> "The DOM attributes width and height are the width and height of the 
> image, in CSS pixels, if known, or else 0 if not known. Typically, if 
> the image is being rendered visually, the width and height are of the 
> rendered image; unrendered images may have an intrinsic width and 
> height. Width and height may not be known if the image is not currently 
> "available" -- still being retrieved, not loaded, or in an otherwise 
> unknown format."

This text contains no testable implementation conformance criteria and as 
such would be inadequate for a technical specification.


> I think it's a better language -- allows a more extensible, 
> well-defined, and ultimately a more predictable web, to not tie down 
> forever the exact mechanisms of "available".

I couldn't disagree more strongly.

We must have clear conformance criteria to get the interoperability that 
we so desperately need on the Web to keep it a credible platform for 
application development.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 22 May 2009 22:28:42 UTC