LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Java Applet element proposal
From: "Terry Allen" <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Fri, 2 Jun 95 19:05:27 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (194 lines)




Thanks, Arthur.

| > | 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  ([log in to unmask])   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



Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager