Re: Agenda

Daniel W. Connolly (connolly@beach.w3.org)
Thu, 13 Jul 95 11:51:23 EDT

In message <199507130439.VAA17008@blob.best.net>, "Peter K. Sheerin" writes:
>
>I think it is imperiative though, that a document produce meaningfull, and
>consistent (in terms of content, and usefullness) interpretation by all
>browsers. If I specify that a word is surrounded by <b><i>bold and
>italics</b></i>, I'd like to know that the meaning is carried over through
>every browser, and not that some browsers randomly decide to apply only one
>of the two styles to the text.

For a little history, you might check out the debate on thiss issue,
back in June of '94:

http://www.acl.lanl.gov/HTML/html-archive.messages/58.html
Date: Wed, 15 Jun 94 14:56:09 EDT
Message-id: <CMM.0.90.4.771706472.reed@hades.cshl.org>
From: Corprew Reed <corp@oclc.org>
To: Multiple recipients of list <html-ig@oclc.org>
Subject: whither <u>...</u>?

and:

http://www.acl.lanl.gov/HTML/html-archive.messages/64.html
Message-id: <9406152321.AA02123@ulua.hal.com>
From: "Daniel W. Connolly" <connolly@oclc.org>
Subject: New Highlighting.html [Was: whither <u>...</u>? ]

Those two messages spawned a few threads on this subject.

> I don't care if Netscape shows it as bold
>and italic, and that Lynx displays it as underlined and brighter (if that
>terminal supports it), or underlined and surrounded *by asterisks*, or
>_*like this*_. Or, at the very least, a browser should indicate to the
>user that there were aspects of the markup it couldn't handle, because of
>system or configuration related issues.
>
>Some of this is clearly in the domain of the specs the WG produces, but
>I'm concerned that the charter not be worded (or interpreted) from
>preventing us from specifying small, but important details like this.

Well... there's more to it than that. We could write what you
described above in the spec, but then none of the existing browsers
would be conforming, right?

The HTML 2.0 spec is intended to be largely descriptive of current
practice (as of June '94). The working group agreed that this was the
most valuable first step.

Consider the alternative: we write the spec the way we believe HTML
_should_ be done. Then information providers build their documents
to that spec. Then the existing browsers make no sense of their
documents. Who wins?

The spec kinda works like this: if you create documents that conform,
you can count on the behaviour that's in the spec. If you're
disappointed at the scope of assurances you get from the spec, the
way to make changes is:

1. propose a change
2. get some implementation experience (and buy-in)
3. we standardize the change

I believe the IETF is successful because it's standards are largely
descriptive of existing implementations, and not prescriptive of
stuff that doesn't exist.

Dan