| > | Subject: <APPLET> tag proposal
| > | Hi,
| > | As some of you may know the <APP> tag that is used in HotJava for
| > | defining applets is not compatible with the SGML standard. It uses an
| > read "HTML standard"
|
| No. Read "SGML standard". The <APP> tag is not compatible with SGML
| because its attribute list cannot be expressed in a DTD. Any extentions
| to HTML should first pass the SGML compliance test before even being
| considered. That is why we are changing it.
I understand now. Paul clued me in to some of the past discussion.
| > Better not to make width and height required; some applets
| > might not use them.
| I'd like WIDTH and HEIGHT to be required so that the document can
| be formatted correctly before the entire applet is loaded.
We can come at that one again another time.
..
| > | <!ELEMENT DATA - - CDATA>
| >
| > | *** Summary ***
| > |
| > | The <APPLET> tag has a required end tag and it can contain more than
| > | just parameters. Other browsers that do not recognize the tag will
| > | display this content, in HotJava it will be ignored.
| >
| > Not a good idea. Anything that shouldn't be displayed should be
| > in an attribute value, or pointed at, so as not to break the
| > (non-SGML, sigh, but hey, you've got to choose your issues ...)
| > convention that tags not understood are ignored and their content
| > displayed. The content of DATA should not be displayed as text.
| >
| > Why not make the DATA element empty and add an attribute that would
| > take a URI?
|
| It is already possible to specify an applet parameter using the <PARAM>
| tag to specify the location of the DATA. We would not need another tag
| for that.
What I mean is that you really don't want elements with content to
contain stuff that isn't human-readable text.
..
| > | The <DATA> tag can be used to supply the applet with raw data. For
| > | example, it could contain an XYZ list for an applet that displays
| > | chemical models.
| > |
| > | *** Example ***
| > |
| > | Here is an example of how an applet is currently defined
| > | with the <APP> tag:
| > |
| > | <APP CLASS=ThreeD SRC="applets/3D" MODEL="applets/3D/cube.obj"
| > | WIDTH=100 HEIGHT=100 SCALE=0.8 ALIGN=middle>
| > |
| > | With the <APPLET> tag the same applet would be defined as:
| > |
| > | <APPLET CLASS=ThreeD SRC="applets/3D/" ALIGN=middle WIDTH=100 HEIGHT=100>
| > | <PARAM NAME=model VALUE="applets/3D/cube.obj">
| > | <PARAM NAME=scale VALUE=0.8>
| > | If you where using <A HREF="http://java.sun.com/">HotJava</A>
| > | you would see a 3D cube here!
| > | </APPLET>
| >
| > Or maybe I'd see an error message. If interpreted according to the DTD
| > in the HTML 2.0 spec
| >
| > ftp://ftp.ds.internic.net/internet-drafts/draft-ietf-html-spec-03.txt
| >
| > in which %flow; can contain PCDATA, you'll break your parse at the
| > first <PARAM> tag, because the line break after the APPLET start
| > tag uses up the PCDATA and take you to the end of the content model.
| > If you keep to empty tags (PARAM) you're okay.
|
| Good point. How should the content model of the <APPLET> tag be
| specified so that this would work? Maybe we could allow an optional
| <P> tag at the end? For example:
|
| <ELEMENT APPLET - - (PARAM*, DATA? P?)>
Well, I'd ditch DATA and use a URI att on APPLET, but that wouldn't
cure the mixed content unless you allowed text intermixed with
PARAMs, (param|data)*, however
| > What text (in %flow;) would you want to put here that shouldn't be
| > part of the applet?
|
| The intention was that text between the <APPLET> and </APPLET> tag
| should be interpreted as the ALT attribute of IMG tag. It is displayed
| if the applet can not be displayed.
Then there should be an ALT att on APPLET. Instead of your
<!ELEMENT APPLET - - (PARAM*, DATA?, %flow)>
<!ATTLIST APPLET
CLASS NAME #REQUIRED -- the class name --
NAME CDATA #IMPLIED -- the applet name --
LANG NAME #IMPLIED -- the language name --
SRC CDATA #IMPLIED -- source URL --
WIDTH NUMBER #REQUIRED
HEIGHT NUMBER #REQUIRED
ALIGN (left|right|top|texttop|middle|
absmiddle|baseline|bottom|absbottom) baseline
VSPACE NUMBER #IMPLIED
HSPACE NUMBER #IMPLIED
>
<!ELEMENT PARAM - O EMPTY>
<!ATTLIST PARAM
NAME NAME #REQUIRED -- The name of the parameter --
VALUE CDATA #IMPLIED -- The value of the parameter -- >
and with minimal changes I'd suggest
<!ELEMENT APPLET - - (PARAM*)>
<!ATTLIST APPLET
CLASS NAME #REQUIRED -- the class name --
NAME CDATA #IMPLIED -- the applet name --
LANG NAME #IMPLIED -- the language name --
SRC CDATA #IMPLIED -- source URL --
DATASRC CDATA #IMPLIED -- URL for DATA *** added --
WIDTH NUMBER #REQUIRED
HEIGHT NUMBER #REQUIRED
ALIGN (left|right|top|texttop|middle|
absmiddle|baseline|bottom|absbottom) baseline
VSPACE NUMBER #IMPLIED
HSPACE NUMBER #IMPLIED
ALT CDATA #IMPLIED -- alternate text *** added -- >
<!ELEMENT PARAM - O EMPTY>
<!ATTLIST PARAM
NAME NAME #REQUIRED -- The name of the parameter --
VALUE CDATA #IMPLIED -- The value of the parameter -- >
Now that doesn't give you the ability to put markup in your ALT
text, and I now understand better what you want this text for.
If you really want to do it this way, you could just change
%flow; to %block; and require people to write in paragraphs:
<!ELEMENT APPLET - - (PARAM*, %block;)>
(and delete the ALT att I added)
Your example would then be
<APPLET CLASS=ThreeD SRC="applets/3D/" ALIGN=middle WIDTH=100 HEIGHT=100>
<PARAM NAME=model VALUE="applets/3D/cube.obj">
<PARAM NAME=scale VALUE=0.8>
<p>If you where using <A HREF="http://java.sun.com/">HotJava</A>
you would see a 3D cube here!
</APPLET>
where only the <p> was added.
| > In fact, why should this APP tag not be assimilated to a (discussed
| > but in no one's DTD) INCLUDE tag?
| Huh?
Sorry. Some people want to be able to include text by doing
<include href="http://someurl"> that. Here, you want to include
some application (mostly, it seems, visible in the flow of the
text). These are similar requirements, and if a general solution
can be found it might be to the good. Then again, might not.
Maybe something like
<!element include - - (includedtext|applet)>
<!element includedtext - - empty >
<!attlist includedtext src CDATA #required >
<!element applet ...
>
will be as general as we can get.
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472 occasional column at: http://gnn.com/meta/imedia/webworks/allen/A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html