[OK, but I didn't see many conclusions reached there]
> 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?
Yep; I retract that point (about alternate rendering of <b> and <i>). We
shouldn't specify things to that level of detail. We might want to suggest
it, though.
After all, the spec _does_ suggest that an alternate rendering of
<blockquote> be using the > character just like we're doing in this e-mail
quoting. Small point, but you might want to consider it for 3.0, or 2.1.
> 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?
I see the point. Thanks.
> 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
Got it.
> 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.
True. But there are some grey areas that are confusing, and I think this
might be the point to deal with them (or at least one of them).
Mind if I dig up some old words, and quote you again?
>Perhaps somebody could run some tests on existing browsers to see
>whether it's reasonable to say whether other chars 0-8, 14-31 should
>be ignored altogether or treated as wordbreaks.
>
>Also... do we leave open the possibility that folks will want to use
>these unused characters for special purposes (such as graphic code set
>switches) in the future?
Gotchya! At one point, you clearly wanted to choose one of these approaches,
and made no hint that the behaviour in this case should be completely
unspecified.
I think the current wording in the spec, stating how to map characters
which appear in ISO 10646, deals quite nicely with your second paragraph
above. It's not what Netscape is doing now, it's not what Mosaic is doing
now, but it seems the most logical course, and it's not really breaking
any existing implimentations because they're all doing it differently, in
a manner in which no consensus could be reached.
That leaves open the question of how to specify what to do with control
characters. Should they be treated as word breaks? Ignored all together?
Displayed as-is? If the latter, this works OK under Windows, for most of
them get mapped to the big open "box" character, making it clear to the
document reader that something is wrong.
But we can't count on that for other platforms. I think we should specify
some particular handling of those control characters (whose positions in
the browser's character set don't contain characters which are in 10646).
******************************************************************************
* Peter K. Sheerin Technical Editor, | Work : psheerin@mfi.com *
* CADENCE Magazine & AutoCAD Tech Journal | CompuServe: 71621,3173 *
* 600 Harrison Street, San Francisco, CA | Personal : psheerin@best.com *
* *
* <URL:http://www.mfi.com/cadence/> <URL:http://www.best.com/~psheerin/> *
* <URL:http://www.mfi.com/atj/> *
******************************************************************************