Sorry, all the attributions had been stripped but > is Terry Allen:
> | > | <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>
> | > 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.
The ALT attribute for IMG has the elegance of a band-aid - better than nothing,
but not to be used as a model for future tage. The content model of the
draft HTML 3.0 FIG element is a better idea, IMHO.
<!--
The element contains text for use in non-graphical displays. Note that
you can use the shape attribute in anchors to specify hotzones on images.
This provides for local processing of pointer clicks and a unified method
for dealing with graphical and non-graphical displays.
Text is flowed around figures when the figure is left or right aligned.
You can request the browser to move down until there is enough room for
the next element, see the CLEAR and NEED attributes (in %needs)
Figures offer a path towards embedding arbitrary information formats
via some kind of OLE/OpenDoc mechanism.
-->
<!ELEMENT FIG - - (OVERLAY*, CAPTION?, FIGTEXT, CREDIT?) -(FIG|IMG)>
<!ATTLIST FIG
%attrs;
%needs; -- for control of text flow --
src %URI; #REQUIRED -- URI of document to embed --
%url.link; -- standard link attributes --
%block.align; -- horizontal alignment --
noflow (noflow) #IMPLIED -- noflow around figure --
width NUMBER #IMPLIED -- desired width in units --
height NUMBER #IMPLIED -- desired height in units --
units (en|pixels) pixels -- specifies units as en's or pixels --
imagemap (%URI) #IMPLIED -- pass background clicks to server --
>
<!ELEMENT FIGTEXT O O %body.content -- dummy element -->
> 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:
Yes. Actually, is there any reason (apart from network efficiency) why
FIG could not be used for a JAVA app with the src URI pointing to
whatever data the app needs? That would avoid having to specify the
app data in SGML-compliant form; it would avoid displaying
non-human-readable text, and the referencing the URI could return
something else (a broken JAVA logo?) using content negotiation for
non-JAVA-aware browsers.
Lastly, the word JAVA does not seem to appear in any of these proposals.
Is there a tacit assumption that JAVA is and will be the only form for
applets? Such assumption seems somewhat premature.
-- Chris Lilley, Technical Author +-------------------------------------------------------------------+ | Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html | +-------------------------------------------------------------------+ | "The first W in WWW will not wait." François Yergeau | +-------------------------------------------------------------------+