Re: Protocol registery? (fwd: Java Applet element proposal)

Walter Ian Kaye (boo@primenet.com)
Mon, 5 Jun 1995 15:47:39 -0700


Message-Id: <v01510101abf9395cf1b1@[198.68.46.155]>
Date: Mon, 5 Jun 1995 15:47:39 -0700
To: www-html@www10.w3.org
From: boo@primenet.com (Walter Ian Kaye)
Subject: Re: Protocol registery? (fwd: Java Applet element proposal)

Time for y'all to speak up, for the HTML Working Group...

>Date: Mon, 5 Jun 95 06:39:47 EDT
>Reply-To: lilley@afs.mcc.ac.uk
>Originator: html-wg@oclc.org
>Sender: html-wg@oclc.org
>Precedence: bulk
>From: lilley <lilley@afs.mcc.ac.uk>
>To: Multiple recipients of list <html-wg@oclc.org>
>Subject: Re: Java Applet element proposal
>X-Comment: HTML Working Group
>
>I suspect this thread is a little premature for html-wg. However, one
>item caught my eye and is worth commenting on:
>
>Sorry, all the attributions had been stripped but > is Terry Allen:
>
>> | > |     <APPLET CLASS=3DThreeD SRC=3D"applets/3D/" ALIGN=3Dmiddle WIDTH=
=3D100
>>HEIGHT=3D100>
>> | > |     <PARAM NAME=3Dmodel VALUE=3D"applets/3D/cube.obj">
>> | > |     <PARAM NAME=3Dscale VALUE=3D0.8>
>> | > |     If you where using <A HREF=3D"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 noth=
ing,
>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=C1ois Yergeau        |
>+-------------------------------------------------------------------+
>

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Walter Ian Kaye: (602) 942-6390  FoxPro/Excel Programmer; Guitarist     #
# Correspond to:   boo@primenet.com, boodlums@genie.com                   #
# BinHex files:    boo@primenet.com   WWW: http://www.primenet.com/~boo/  #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #