Re: Support Existing Content (was: Proposed Design Principles review)

Hi Murray,

On Apr 30, 2007, at 7:41 AM, Murray Maloney wrote:

> There are several "we". In the language spec, "we" need to  
> understand each construct,
> its behaviour and its default appearance in visual, aural and  
> tactile media.
>
> In the browser spec, "we" need to be able to identify and replicate  
> each other's
> behaviour and appearance.
>
> In other client specs, "we" need to convey whatever meaning is  
> intended for that client.

[...]

> That's the thing. HTML is a language spec. I agree that there  
> should be
> a browser spec. I would even agree that it should be closely tied
> to the language spec -- which is why we have hyperlinks and triples.
> I don't think that the language spec and the browser spec should be
> written on the same page.

I think I see why we are failing to communicate. Your assumptions  
about what we will be doing seem to differ drastically from my own. I  
expect that we will be writing a single technology specification that  
defines multiple conformance classes. These conformance classes will  
likely include at the very least:

- conforming documents
- conforming implementations
- conforming conformance checkers
- conforming visual interactive user agents (i.e. what we commonly  
call "web browsers")

It is common practice and indeed a good practice to have a single  
specification that addresses multiple conformance classes. For  
example, the HTTP specification addresses all three of clients,  
endpoint servers, and proxy servers.

The idea that there would be a separate "language spec" and "browser  
spec", and possibly still other specs, is something I hadn't  
considered. But at first glance at least, it seems like it would be  
worse than having a single spec.


> No reluctance to acknowledge that browsers exist. That would be an  
> absurd
> and extreme position. However, I would prefer to maintain a layer  
> of abstraction
> between the language and the human being. I think that it is  
> possible to describe
> what you mean with respect to preserving the existing meaning of  
> extant HTML
> without resorting to descriptions that are based on browser  
> behaviour and performance.

The problem is, the expected presentation of extant HTML is de facto  
defined by existing browsers. So making such an abstraction abstracts  
away too much. We can't just look at a document in isolation and  
guess what the author intended without checking how it renders and  
behaves in browsers (and other user agents).

Regards,
Maciej

Received on Monday, 30 April 2007 15:31:58 UTC