I stand corrected on this 7-bit business. This was more a
problem of the proliferating books than the standard, which
I have read. I have also browzed the almost endless threads
on "charset" issues. My point is:
Regardless of the HTTP protocal and the MIME header, a file
sits on the disk. An authoring program will create and edit
it and the server will send it. Something must tell these
programs about the encoding, if only to get the correct one
into the MIME header and get the correct glyphs on the
screen. The browzer receiving the file will have the MIME
header. The file when downloaded, lacks this information.
Many entries on digest 108 indicate that encoding is an
issue. Not all programs are perfect or failsoft!
-------------------------------
Another issue I see debated in this digest is the trend towards
hard and specific formatting in HTML. SGML did not specify
format, but structure. Various readers could use this
information and render on many medea. I think what comes
out on mosaic, et al, looks fine, and is platform
independent.
Once fonts, complex stylesheets, etc., become part of HTML,
this transportability will be lost. Maybe
my-favorite-browzer will give me good results but my
friend's may give him a "font not found" error and discard
the file (or if properly designed, give an alternate which
may not be what all my artistic fervor desired!).
Also, the proliferation of systems of units that depend on
target screens, portrayal font sizes, etc., is dangerous.
Netscape uses pixels and arbitrary font size numbers. EMs are a
small step better. Only the relative units (Netscape offers
percents) are in any way transportable.
Divorce from the SGML parentage may be the
future, but his is a major decision. The increasing
capabilities of even inexpensive platforms leads to greater
expectations. So we must think about it...