[ZT]我建议在HTML中增加一个新的标记：<img>

再转贴个好玩的：

reddit上nearfar同学最近挖出来了一个很好的坑，值得大家参观。

Quote:

proposed new tag: IMG
Marc Andreessen (marca@ncsa.uiuc.edu)
Thu, 25 Feb 93 21:09:02 -0800
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Tony Johnson: "Re: proposed new tag: IMG"
Previous message: Bill Janssen: "Re: xmosaic experience"
Next in thread: Tony Johnson: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
I'd like to propose a new, optional HTML tag:
IMG
Required argument is SRC="url".
This names a bitmap or pixmap file for the browser to attempt to pull
over the network and interpret as an image, to be embedded in the text
at the point of the tag's occurrence.
An example is:
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
(There is no closing tag; this is just a standalone tag.)
This tag can be embedded in an anchor like anything else; when that
happens, it becomes an icon that's sensitive to activation just like a
regular text anchor.
Browsers should be afforded flexibility as to which image formats they
support. Xbm and Xpm are good ones to support, for example. If a
browser cannot interpret a given format, it can do whatever it wants
instead (X Mosaic will pop up a default bitmap as a placeholder).
This is required functionality for X Mosaic; we have this working, and
we'll at least be using it internally. I'm certainly open to
suggestions as to how this should be handled within HTML; if you have
a better idea than what I'm presenting now, please let me know. I
know this is hazy wrt image format, but I don't see an alternative
than to just say ``let the browser do what it can'' and wait for the
perfect solution to come along (MIME, someday, maybe).
Let me know what you think.........
Cheers,
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu
--------------------------------------------------------------------------------
Next message: Tony Johnson: "Re: proposed new tag: IMG"
Previous message: Bill Janssen: "Re: xmosaic experience"
Next in thread: Tony Johnson: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tony Johnson (TONYJ@scs.slac.stanford.edu)
Thu, 25 Feb 1993 23:13 PDT
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Guido.van.Rossum@cwi.nl: "Re: xmosaic experience"
Previous message: Marc Andreessen: "proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
>I'd like to propose a new, optional HTML tag:
>
> IMG
>
>Required argument is SRC="url".
>
>This names a bitmap or pixmap file for the browser to attempt to pull
>over the network and interpret as an image, to be embedded in the text
>at the point of the tag's occurrence.
>
>An example is:
>
> <IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
>
>(There is no closing tag; this is just a standalone tag.)
I have something very similar in Midas 2.0 (in use here at SLAC, and due for
public release any week now), except that all the names are different, and it
has an extra argument NAME="name". It has almost exactly the same
functionality as your proposed IMG tag. e.g.
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
The idea of the name parameter was to allow the browser to have a set of
"built in" images. If the name matches a "built in" image it would use that
instead of having to go out and fetch the image. The name could also act as a
hint for "line mode" browsers as to what kind of a symbol to put in place of
the image.
I don't much care about the parameter or tag names, but it would be sensible
if we used the same things. I don't much care for abbreviations, ie why not
IMAGE= and SOURCE=. I somewhat prefer ICON since it imlies that the IMAGE
should be smallish, but maybe ICON is an overloaded word?
>Browsers should be afforded flexibility as to which image formats they
>support. Xbm and Xpm are good ones to support, for example. If a
>browser cannot interpret a given format, it can do whatever it wants
>instead (X Mosaic will pop up a default bitmap as a placeholder).
I was proposing to use the file extension (.xbm above) to tag what format the
image was in, but with the intention that in future, when HTTP2 comes along,
the same format negotiation technique would be used to access images.
Xbm and Xpm sound resonable to me, but do they sound reasonable for non-X
based applications??
While we are on the subject of new tags, I have another, somewhat similar tag,
which I would like to support in Midas 2.0. In principle it is:
<INCLUDE HREF="...">
The intention here would be that the second document is to be included into
the first document at the place where the tag occured. In principle the
referenced document could be anything, but the main purpose was to allow
images (in this case arbitrary sized) to be embedded into documents. Again the
intention would be that when HTTP2 comes along the format of the included
document would be up for separate negotiation.
An alternative I was considering was:
<A HREF="..." INCLUDE>See photo</A>
I don't much like adding more functionality to the <A> tag, but the idea here
is to maintain compatibility with browsers that can not honour the INCLUDE
parameter. The intention is that browsers which do understand INCLUDE, replace
the anchor text (in this case "See photo") with the included document
(picture), while older or dumber browsers ignore the INCLUDE tag completely.
Comments?????
Tony
--------------------------------------------------------------------------------
Next message: Guido.van.Rossum@cwi.nl: "Re: xmosaic experience"
Previous message: Marc Andreessen: "proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tim Berners-Lee (timbl@www3.cern.ch)
Fri, 26 Feb 93 14:04:55 +0100
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Tony Johnson: "Handling + in document searches"
Previous message: Kim Peter Nyberg: "re: xmosaic experience"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Jim Davis: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
I had imagined that figues would be reprented as
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
where the relation ship values mean
EMBED Embed this here when presenting it
PRESENT Present this whenever the source document
is presented
Note that you can have various combinations of these, and if
the browser doesn't support either one, it doesn't break.
A see that using this as a method for selectable icons means nesting
anchors. Hmmm. But I hadn't wanted a special tag.
Annother way would be to declare an entity with SYSTEM attribute
giving the URL and then invoke that entity, but that would mean an
extendable entity dictionary which is not currently needed.
--------------------------------------------------------------------------------
Next message: Tony Johnson: "Handling + in document searches"
Previous message: Kim Peter Nyberg: "re: xmosaic experience"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Jim Davis: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Jim Davis (davis@dri.cornell.edu)
Fri, 26 Feb 1993 10:07:34 -0500
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Peter Lister, Cranfield Computer Centre: "patch to exec from httpd"
Previous message: Tony Johnson: "Handling + in document searches"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
I like the functionality of Marc's proposal. (I am indifferent
to the syntax, so long as we get a standard.) While I daresay
that HTPP2 and Mime will oneday achieve the same power and more,
I like the idea of getting it soon.
Note that Tim's proposal
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
is less general, since it can only be used inside anchors. (Maybe
I don't understand it, though... do you have to click on the
anchor, or does PRESENT mean that it is "automatically" clicked?
If so, what happens to the text between the A and /A ?
As I understand it, I can use Marc A's scheme for inline pictures
(which might be big) or icons in anchors.
As for specifics of Marc A's proposal, two comments
1) why have SRC instead of HREF?
2) It would be nice if there was a way to specify the content type,
e.g.
<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>
But I am completely willing to live with the requirement that I specify
the content type by file extension. It's good enough for me.
--------------------------------------------------------------------------------
Next message: Peter Lister, Cranfield Computer Centre: "patch to exec from httpd"
Previous message: Tony Johnson: "Handling + in document searches"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Marc Andreessen (marca@ncsa.uiuc.edu)
Fri, 26 Feb 93 13:29:45 -0800
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Marc Andreessen: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "re: xmosaic experience"
In reply to: Jim Davis: "Re: proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Jim Davis writes:
> As for specifics of Marc A's proposal, two comments
>
> 1) why have SRC instead of HREF?
Because I wanted to avoid overloading HREF -- doesn't really make
sense in this context, I don't think.
> 2) It would be nice if there was a way to specify the content type,
> e.g.
>
> <IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>
>
> But I am completely willing to live with the requirement that I specify
> the content type by file extension. It's good enough for me.
Actually, in Mosaic this will be possible by doing something like:
<A HREF="http://nsa.gov/pub/sounds/gorby.au"><IMG SRC="myimage.xbm></A>
Simple.....
Marc
--------------------------------------------------------------------------------
Next message: Marc Andreessen: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "re: xmosaic experience"
In reply to: Jim Davis: "Re: proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tim Berners-Lee (timbl@www3.cern.ch)
Fri, 26 Feb 93 18:12:45 +0100
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Jay C. Weber: "Re: proposed new tag: IMG"
Previous message: Tim Berners-Lee: "Re: info.cern.ch from rs6k"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
> Date: Fri, 26 Feb 1993 10:07:34 -0500
> From: Jim Davis <davis@dri.cornell.edu>
>
> I like the functionality of Marc's proposal. (I am indifferent
> to the syntax, so long as we get a standard.) While I daresay
> that HTPP2 and Mime will oneday achieve the same power and more,
> I like the idea of getting it soon.
>
> Note that Tim's proposal
>
> <a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
>
> is less general, since it can only be used inside anchors.
No ... it is just that the thing is seen as a type of link rather
than something totally new. Note that in the Microsoft world the
work "Link" always mean "embed the thing referred to here" --
this explains much of the confusion when explaining W3 to windows
users.
If you consider that often the reader (rather than the author) might
want to chose which figues are expanded inline rather than put in a
separate window, and also that the reader (rather tham the author)
might want to chose whether related things are PRESENTed
automatically or not, then the use of <A> with switches looks
more appropriate. As Tony points out, an advantage is that it will
be handled relatively well by browsers which can't do it or
old ones which don't understand it.
> (Maybe
> I don't understand it, though... do you have to click on the
> anchor, or does PRESENT mean that it is "automatically" clicked?
You didn't quite but you do now. yes ... PRESENT means
CONSIDER-THIS-CLICKED.
> If so, what happens to the text between the A and /A ?
It is replaced by the object because of the EMBED relationship.
> As I understand it, I can use Marc A's scheme for inline pictures
> (which might be big) or icons in anchors.
If you allow an image, then suppose we also allow some content which
includes anchors with x,y coordinates within the image. Then the
document can intercept mouse clicks and allow hypergraphics
I don't want to change HTML now if I can help it, until it has gone
to RFC track
Tim
--------------------------------------------------------------------------------
Next message: Jay C. Weber: "Re: proposed new tag: IMG"
Previous message: Tim Berners-Lee: "Re: info.cern.ch from rs6k"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Marc Andreessen (marca@ncsa.uiuc.edu)
Fri, 26 Feb 93 13:32:09 -0800
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Jay C. Weber: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "Re: proposed new tag: IMG"
In reply to: Tim Berners-Lee: "Re: proposed new tag: IMG"
Next in thread: Jay C. Weber: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Tim Berners-Lee writes:
> I don't want to change HTML now if I can help it, until it has gone
> to RFC track
I absolutely agree in all cases -- my purpose in suggesting IMG is
that things are reaching the point where some browsers are going to be
implementing this feature somehow, even if it's not standard, just
because it's the logical next step, and it would be great to have
consistency from the beginning -- so that when HTML2 comes along,
we're all still in lockstep.....
Cheers,
Marc
--------------------------------------------------------------------------------
Next message: Jay C. Weber: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "Re: proposed new tag: IMG"
In reply to: Tim Berners-Lee: "Re: proposed new tag: IMG"
Next in thread: Jay C. Weber: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Jay C. Weber (weber@eitech.com)
Fri, 26 Feb 93 10:28:38 PST
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Eelco van Asperen: "Re: patch to exec from httpd"
Previous message: Tim Berners-Lee: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Jay C. Weber: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
While images are at the top of my list of desired medium types in a
WWW browser, I don't think we should add idiosyncratic hooks for media
one at a time. Whatever happened to the enthusiasm for using the
MIME typing mechanism? I made a concrete proposal a few months ago,
where HREFs can point to other parts in a MIME multipart (and thereby
to an "external-body"), and I've seen a similar idea recently regarding
embedding media clips in a "simplemail" format. Don't we want to
take on something like this in HTML2?
Jay
---------------------------------------------------------------------
Jay C. Weber weber@eitech.com
Enterprise Integration Technologies weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100 (415)617-8002
Palo Alto, CA 94301
--------------------------------------------------------------------------------
Next message: Eelco van Asperen: "Re: patch to exec from httpd"
Previous message: Tim Berners-Lee: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Jay C. Weber: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Jay C. Weber (weber@eitech.com)
Fri, 26 Feb 93 14:00:12 PST
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: ebina@ncsa.uiuc.edu: "Re: xmosaic experience"
Previous message: Marc Andreessen: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Pei Y. Wei: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
> From marca@wintermute.ncsa.uiuc.edu Fri Feb 26 11:12:42 1993
>
> Yup. BTW, someone mentioned ``what happened to MIME'' -- this isn't a
> substitute for the upcoming use of MIME as a standard document
> mechanism; this provides a necessary and simple implementation of
> functionality that's needed independently from MIME.
Wait a minute -- let's temporarily forget about MIME, if it clouds the
issue. My objection was to the discussion of "how are we going to
support embedded images" rather than "how are we going to support
embedded objections in various media".
Otherwise, next week someone is going to suggest 'lets put in a new
tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">' for audio.
There shouldn't be much cost in going with something that generalizes.
Jay
---------------------------------------------------------------------
Jay C. Weber weber@eitech.com
Enterprise Integration Technologies weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100 (415)617-8002
Palo Alto, CA 94301
--------------------------------------------------------------------------------
Next message: ebina@ncsa.uiuc.edu: "Re: xmosaic experience"
Previous message: Marc Andreessen: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Pei Y. Wei: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Pei Y. Wei (wei@xcf.berkeley.edu)
Fri, 26 Feb 93 17:37:29 -0800
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Tim Berners-Lee: "Re: proposed new tag: IMG"
Previous message: Bill Janssen: "Re: xmosaic experience"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
To: marca@ncsa.uiuc.edu, timbl@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
Cc: davis@dri.cornell.edu
> > Tim Berners-Lee writes:
> > I don't want to change HTML now if I can help it, until it has gone
> > to RFC track.
>
> Marc wrote:
> I absolutely agree in all cases -- my purpose in suggesting IMG is
> that things are reaching the point where some browsers are going to be
> implementing this feature somehow, even if it's not standard, just
> because it's the logical next step, and it would be great to have
> consistency from the beginning -- so that when HTML2 comes along,
> we're all still in lockstep.....
Yup, yup... Since this is becoming an issue, I might as well mention
that viola too has a number of bitmap tags, but for a DTD other than HTML,
because it'd be a mess to mix such things with the current HTML. At this
point, HTML should stay stable.
Yup, we obviously need to agree upon the namings, etc, from the start,
or it's gonna be a sincere pain to converge later... I don't have any
particular preference for the names/syntax, as long as there is some
accounting for the format used (not by file extension, but preferably
by using MIME format identifiers).
-Pei
--------------------------------------------------------------------------------
Next message: Tim Berners-Lee: "Re: proposed new tag: IMG"
Previous message: Bill Janssen: "Re: xmosaic experience"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tim Berners-Lee (timbl)
Sat, 27 Feb 93 16:49:48 MET
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Willem van Leeuwen: "Re: patch to exec from httpd"
Previous message: Pei Y. Wei: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Dave_Raggett: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Ok, so for HTML2 let's have something for inclusion.
I don't see any reason to limit it to images. Like
it could be more text or whatever.
SGML does provide an official way of doing this folks
and even if Dan C ain't here to round us up we maybe
ought to stick to the track. It might have some useful
spinnoffs like people assuming that any SYSTEM attribute,
instead of being a "system defined" path for an
entity, would be a URI.
How about
<!ENTITY ICON6 SYSTEM "http://blah..">&ICON6;
Tim BL
--------------------------------------------------------------------------------
Next message: Willem van Leeuwen: "Re: patch to exec from httpd"
Previous message: Pei Y. Wei: "Re: proposed new tag: IMG"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Dave_Raggett: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Dave_Raggett (dsr@hplb.hpl.hp.com)
Mon, 1 Mar 93 9:29:50 GMT
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Sheaffer Gad: "Reading news via WWW browsers"
Previous message: Willem van Leeuwen: "Re: patch to exec from httpd"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
> While images are at the top of my list of desired medium types in a
> WWW browser, I don't think we should add idiosyncratic hooks for media
> one at a time. Whatever happened to the enthusiasm for using the
> MIME typing mechanism? I made a concrete proposal a few months ago,
> where HREFs can point to other parts in a MIME multipart (and thereby
> to an "external-body"), and I've seen a similar idea recently regarding
> embedding media clips in a "simplemail" format. Don't we want to
> take on something like this in HTML2?
True indeed! I want to consider a whole range of possible image/line art
types, along with the possibility of format negotiation. Tim's note
on supporting clickable areas within images is also important
Dave Raggett, HPLabs
--------------------------------------------------------------------------------
Next message: Sheaffer Gad: "Reading news via WWW browsers"
Previous message: Willem van Leeuwen: "Re: patch to exec from httpd"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Marc Andreessen (marca@ncsa.uiuc.edu)
Mon, 1 Mar 93 13:05:08 -0800
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: putz.parc@xerox.com: "Re: Reading news via WWW browsers"
Previous message: Edward Vielmetti: "Re: Reading news via WWW browsers"
In reply to: Dave_Raggett: "Re: proposed new tag: IMG"
Next in thread: Bill Janssen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Dave_Raggett writes:
> True indeed! I want to consider a whole range of possible image/line
> art types, along with the possibility of format negotiation. Tim's
> note on supporting clickable areas within images is also important
Actually, maybe we should think about a general-purpose procedural
graphics language within which we can embed arbitrary hyperlinks
attached to icons, images, or text, or anything. Has anyone else seen
Intermedia's capabilities wrt this? It's one of their most impressive
capabilities, actually.
Something like a cross between PostScript and CGM might work...
actually, maybe we should just use one or the other, and add the
extensions we need for the links. Also we'd want to make sure that
it's completely editable.
Cheers,
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu
--------------------------------------------------------------------------------
Next message: putz.parc@xerox.com: "Re: Reading news via WWW browsers"
Previous message: Edward Vielmetti: "Re: Reading news via WWW browsers"
In reply to: Dave_Raggett: "Re: proposed new tag: IMG"
Next in thread: Bill Janssen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Bill Janssen (janssen@parc.xerox.com)
Mon, 1 Mar 1993 14:55:57 PST
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Nathan Torkington: "Internal links"
Previous message: Bill Janssen: "Re: Reading news via WWW browsers"
In reply to: Marc Andreessen: "Re: proposed new tag: IMG"
Next in thread: Thomas A. Fine: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Excerpts from ext.WorldWideWeb: 1-Mar-93 Re: proposed new tag: IMG Marc
Andreessen@ncsa.uiu (884)
> Actually, maybe we should think about a general-purpose procedural
> graphics language within which we can embed arbitrary hyperlinks
> attached to icons, images, or text, or anything. Has anyone else seen
> Intermedia's capabilities wrt this? It's one of their most impressive
> capabilities, actually.
Other systems to look at which have this (fairly valuable) notion are
Andrew and Slate. Andrew is built with _insets_, each of which has some
interesting type, such as text, bitmap, drawing, animation, message,
spreadsheet, etc. The notion of arbitrary recursive embedding is
present, so that an inset of any kind can be embedded in any other kind
which supports embedding. For example, an inset can be embedded at any
point in the text of the text widget, or in any rectangular area in the
drawing widget, or in any cell of the spreadsheet. Each ``embedding''
consists of some direct information which specifies the display area of
the embedded information, and a pointer to the actual data object
(actually, in most current usage the embedded data object is directly
contained, but references do in fact work).
This business about embedding the display information is interesting, as
it seems to contradict the standard separation of data and display so
pervasive in Andrew. In Andrew text, embedded insets are thought of as
single characters in rather strange fonts, so the rectangular area
information tells the text display widget the size of the ``character''.
Similarly for embedded insets in the drawing widget.
Bill
--------------------------------------------------------------------------------
Next message: Nathan Torkington: "Internal links"
Previous message: Bill Janssen: "Re: Reading news via WWW browsers"
In reply to: Marc Andreessen: "Re: proposed new tag: IMG"
Next in thread: Thomas A. Fine: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Thomas A. Fine (fine@cis.ohio-state.edu)
Mon, 1 Mar 93 15:21:36 -0500
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Bill Janssen: "Re: Reading news via WWW browsers"
Previous message: Marc Andreessen: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
Here's my opinion.
The best way to do images in WWW is by using MIME. I'm sure postscript
is already a supported subtype in MIME, and it deals very nicely with
mixing text and graphics.
But it isn't clickable, you say? Yes your right. I suspect there is
already an answer to this in display postscript. Even if there isn't
the addition to standard postscript is trivial. Define an anchor
command which specifies the URL and uses the current path as a closed
region for the button. Since postscript deals so well with paths, this
makes arbitrary button shapes trivial.
Let's call this specially modified postscript HTPS. Until HTPS becomes
some sort of standard, every copy of HTPS should include a piece of code
that asks the interpreter if it knows about the anchor command, and if
it doesn't it will substitute in a null command.
As far as implementation, this is easy, though not necessarily trivial.
Ghostscript already provides the ability to bind arbitrary functions to
mouse events. It shouldn't be too horrible to set up anchor to keep
a table of button paths, and have mouse clicks call a function that looks
up what button they are in.
Let me point out that it wouldn't be hard to make such a system deal
with html too. Many people already have code that converts html to
postscript.
tom
--------------------------------------------------------------------------------
Next message: Bill Janssen: "Re: Reading news via WWW browsers"
Previous message: Marc Andreessen: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Tim Berners-Lee: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tim Berners-Lee (timbl@dxcern.cern.ch)
Tue, 2 Mar 1993 23:25:51 +0100
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Edward Vielmetti: "Re: Reading news via WWW browsers"
Previous message: Tim Berners-Lee: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
HTTP2 allows a document to contain any type which
the user has said he can handle, not just registered MIME
types. So one can experiment. Yes I think there is a case
for postscript with hypertext.
I don't know whether display postcript has enough.
I know Adobe are trying to establish their own postscript-based
"PDF" which will have links, and be readable by their
proprietory brand of viewers.
I thought that a generic overlaying language for anchors
(Hytime based?) would allow the hypertext and the graphics/video
standards to evolve separately, which would help both.
Let the IMG tag be INCLUDE and let it refer to an arbitrary
document type. Or EMBED if INCLUDE sounds like a cpp include
which people will expect to provide SGML source code to be
parsed inline -- not what was intended.
Tim BL
--------------------------------------------------------------------------------
Next message: Edward Vielmetti: "Re: Reading news via WWW browsers"
Previous message: Tim Berners-Lee: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Tim Berners-Lee (timbl@dxcern.cern.ch)
Tue, 2 Mar 1993 23:25:51 +0100
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Edward Vielmetti: "Re: Reading news via WWW browsers"
Previous message: Tim Berners-Lee: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
--------------------------------------------------------------------------------
HTTP2 allows a document to contain any type which
the user has said he can handle, not just registered MIME
types. So one can experiment. Yes I think there is a case
for postscript with hypertext.
I don't know whether display postcript has enough.
I know Adobe are trying to establish their own postscript-based
"PDF" which will have links, and be readable by their
proprietory brand of viewers.
I thought that a generic overlaying language for anchors
(Hytime based?) would allow the hypertext and the graphics/video
standards to evolve separately, which would help both.
Let the IMG tag be INCLUDE and let it refer to an arbitrary
document type. Or EMBED if INCLUDE sounds like a cpp include
which people will expect to provide SGML source code to be
parsed inline -- not what was intended.
Tim BL
--------------------------------------------------------------------------------
Next message: Edward Vielmetti: "Re: Reading news via WWW browsers"
Previous message: Tim Berners-Lee: "Re: Reading news via WWW browsers"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
Next in thread: Marc Andreessen: "Re: proposed new tag: IMG"
Re: proposed new tag: IMG
Guido van Rossum (Guido.van.Rossum@cwi.nl)
Sat, 13 Mar 1993 11:56:26 +0100
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Marc Andreessen: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "binary file access via Mosaic"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"
--------------------------------------------------------------------------------
>We're not prepared to support INCLUDE/EMBED at this point; it raises a
>number of nasty issues that are quite separate from the idea of
>inlined images. For example, what happens if one EMBEDS a document
>that in turn EMBEDS the first document? Oops.
I would consider this an error of the author that needs to be detected
to protect the browser. It only requires maintaining a stack of
nested EMBEDS.
>Aside from this, I'm
>not sure I see the point in allowing arbitrary EMBED's for things like
>chunks of texts: this is a hypertext system, after all, and it ought
>to be possible to get the functional effect of an EMBED by using an
>ordinary link. Right?
Some other hypertext systems do this, in a sense: in Guide there are,
apart from real GOTO stype hyperlinks, also "folds" (I think they are
called) which are sort of embedded documents that you can open and
close. The advantage in certain situations is that opening a fold
retains more context than following a link. It feels like using an
outline processor, which is rather pleasant (for certain kinds of
information).
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
PS. I keep hearing about supporting MIME. Is there consensus on the
form this should take? (I remeber getting in an unpleasant fight with
Dan Connolly about this once -- BTW is he still with us?)
--------------------------------------------------------------------------------
Next message: Marc Andreessen: "Re: proposed new tag: IMG"
Previous message: Marc Andreessen: "binary file access via Mosaic"
Maybe in reply to: Marc Andreessen: "proposed new tag: IMG"

没有发疯，这是1993年的讨论。好遥远的时代~