Note that Netscape doesn't allow viewing the source of secure documents.
At 5:24 PM 5/24/95, Murray Altheim wrote:
>Isn't this where the problem comes in? If the server embeds a document in
>place of the tag upon download, the user won't see the original tag in the
>source, but the embedded document's content where the original embed tag
>was in the source. This would tend to imply to a user that it was part of
>the downloaded document.
Isn't this really just a matter of a browser with a bad interface? I see a
potential here for a bad interface to increase the likelihood that someone
might accidentally violate a copyright. But you could easily argue the same
thing of a photocopier.
At 2:32 PM 5/24/95, Brian Behlendorf wrote:
>to a tree-like structure. Besides, just replacing the <a rel=3Dembed> with
>the HTML text it includes could make the document no longer a valid HTML
I have mixed feelings about that one. I often use server-side includes to
include files (e.g. footer.html) which are by themselves invalid HTML, and
which are included in my document in order to make it valid HTML. Is there
an argument that client side inclusion would somehow push down a level and
require a complete document who's tags would not affect the includer?
At 2:48 PM 5/24/95, Brian Behlendorf wrote:
>One way in which java applets could help though: let's say instead of
>having 5 different representations for different browsers, you had one
>representation which was a superset of those 5, and you wrote a java app
>to downconvert from that superset into the browser's preferred set. The
That has a lot of appeal. The major issue then becomes one of whether
browsers are going to be any more open to Java about what features they
support than they are to the server. (Browser/HotJava developers, pay
Kee Hinckley Utopia Inc. - Cyberspace Architects=81 617/721-6100
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate