- From: Brian Behlendorf <brian@organic.com>
- Date: Wed, 24 May 1995 14:15:49 -0700 (PDT)
- To: Murray Altheim <murray.altheim@nttc.edu>
- Cc: www-html@www10.w3.org, nazgul@utopia.com
On Wed, 24 May 1995, Murray Altheim wrote: > I too believe a great number of the features of the proposed 3.0 feature > set hold great promise for solving some technical hurdles. From reading the > DTD I'm sure that all those involved spent considerable time trying to > maintain some compatibility with legacy documents. Legacy documents are no problem. For the most part, valid HTML 2.0 documents will also be valid HTML 3.0 documents. If they aren't, the differences are minor enough that any browser author should be able to support 2.0 without much trouble. I can't imagine any browser company refusing to do that. > Breaking the browser may not be a serious problem for you, but there are a > great number of people on the net who don't have the most up-to-date > equipment or software, including government sites, educational sites and > others, not to mention text-only and Braille browsers. What may for you > seem like an aesthetic issue is for others an inability to read a document. Absolutely correct. Content negotiation, when used correctly, will ensure that (for example) HTML 2.0-only browsers are *not* given HTML 3.0 documents. Somewhere a downtranslation will happen, where 3.0 documnents will be reduced to 2.0. There will definitely be some loss - instead of using <table> to represent a table, the downconversion utility will format it out for some default width and use <pre>, for example. Where and how that translation happens isn't all that important - it can be done in the server at the time of the request, or it could be done at production time creating two separate files, etc. Will downconversion be sufficient? That's mostly a quality of implementation issue, i.e., how good your downconversion utility is. Hopefully W3O will have a pointer to a reference utility for this purpose... the only issue for the development of HTML 3.0 is that we try and avoid tags which will be impossible to downconvert (and I can't think of an example). > Not to harp on Netscape (more than has already been done), but how many > times have you been browsing and came upon a page that looked absolutely > horrendous or was unreadable because it relied on code that your browser > didn't support? Unless the language truly supports an alternative display > method (such as ALT for images) it will inevitably create this have and > have-not division. Relying on the server rather than the structure of the > language seems to me to be stopgap. If Netscape had put "Accept: text/x-Mozilla-html" in their HTTP headers, this would not have been a problem! :) > Kee, on the issue of legality, having a user jump to a new Web page lets > them know that they have possibly changed sites. If we assume that the only > way an included document will make sense when inserted into a display is > that the author's header and footer graphics are absent (it would look > pretty cnofusing if they were included), then it seems altogether unclear > how a reader would ascertain authorship or the intellectual property status > of the current page. I don't believe we can legislate behaviour via HTML, > but that's where I see the legal problems arising. These issues currently > exist in other easily-copied content. I don't see a legal distinction between (on a document that sits on organic.com) <A rel="embed" src="http://hyperreal.com"> and <IMG rel="embed" src="http://hyperreal.com/hyperreal.gif"> It would behoove the HTML browser to be able to note included text somehow (make the mouse change shape when it passes over, have a "highlight included text" mode, etc), but as long as the source can be viewed there's no question where something came from. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Received on Wednesday, 24 May 1995 17:16:27 UTC