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

Re: HTML interpreter vs. HTML user agent

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 28 May 2009 03:17:32 -0700
Cc: Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Message-id: <3ADF21A2-E0F7-4D93-9EF7-CFCCE1F18379@apple.com>
To: "Roy T. Fielding" <fielding@gbiv.com>

On May 28, 2009, at 12:52 AM, Roy T. Fielding wrote:

> HTML application = {HTML interpreter, HTML generator}

Please see my post on this thread for why the term "HTML interpreter"  
is inaccurate and grating.

> I think it is useful to distinguish them.  I don't think
> this has anything to do with the user agent terminology.
> OTOH, I do agree with your underlying points.  The fact is
> that different applications of HTML will have very different
> operational behavior, particularly in the presence of errors,
> so a specification that defines HTML in terms of operational
> behavior of just one type of implementation is broken for all
> applications that don't happen to be of that type.

What kinds of HTML processors/implementations/whatever have different  
requirements and would have different behavior in the presence of  

> That's why the title of the document matters.  If the title
> applies to all HTML applications, then the specification must
> define HTML in a way that is suitable for all applications.

The spec is meant to apply to any software that generates or processes  
HTML. Some requirements are scoped to particular conformance classes.  
If you feel it does not do so, then please describe how, rather than  
debating the title.

> If the title applies only to browsers, then the applications
> that are not browsers are not bound by its requirements
> beyond their need to interoperate with browsers.  Consensus
> here would then be reduced to a more tractable problem.

The whole point of the spec is to enable interoperability, including  
among different classes of implementations. I can't think of any piece  
of useful HTML-processing software that has no need to interoperate  
with either browsers or existing deployed HTML content on the Web,  at  
the very least through some chain of indirection. I suppose you can  
imagine completely closed ecosystems of HTML where the content is  
never authored using a standard tool, or consumed by a standard  
browser, search engine, mail client, assistive technology, etc. But I  
don't think it is worth it to make a separate spec to cater to such  
walled garden use cases. Inside a walled garden you can do whatever  
you want, regardless of specs.

> Hence, there should be one specification of the language
> in terms of syntax and declarative semantics (that applies
> to all applications) and separate specifications of behavior
> during application-specific processing of HTML.

I continue to disagree, and I once again point out that things are not  
generally done this way for other languages, even other W3C languages.

Received on Thursday, 28 May 2009 10:18:14 UTC

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