Ka-Ping Yee <[log in to unmask]> writes:
>I think all of you who have been making comments in this thread have
>made some very worthwhile points, and i appreciate being challenged
>to rethink what i proposed.
>Murray Altheim wrote:
>: But specifying browser error handling behaviour is quite beyond the
>: bounds of either the HTML specification or this working group.
>I'm not by any means suggesting we take this to any level of
>detail. This is not supposed to be a detailed specification of
>behaviour -- it only goes as far as to say there must *exist*
>an error indicator. In much the same way we say there must *exist*
>rendering, though we don't specify how. (Not much, anyway.)
I guess I was not clear enough. It's not a matter of what level of detail.
Specifying error behavior is beyond the scope of either the spec or the
HTML working group. You'll note that RFC 1866 _recommends_ informing the
user of errors. That is as far as it goes; it is a markup language
specification. There is also a big difference between 'should' and 'must'.
Required application conventions apply to rendering behavior, for example:
EM must be somehow emphasized from body text, but the method of emphasis is
left unspecified. I think the analogy of a rendering requirement is
invalid. The same argument would also say there must *exist* a display or
presentation device. Application conventions apply to UA implementation of
language constructs as an SGML _language application_, not the methods by
which a _software application_ implements the language. The scope of the
specification and the working group is the HTML language, not the UA
implementation of that language.
I don't disagree with your intent, but this is just the wrong forum. The
scope is stated succinctly in the IETF HTML working group charter.
Murray Altheim, Program Manager
Spyglass, Inc., Cambridge, Massachusetts
email: [log in to unmask]