Re: HTML 3.2: TEXTFLOW is confusing

Gerald Oskoboiny <Gerald.Oskoboiny@ualberta.ca> wrote:
> Joe English writes:
> > [Gerald Oskoboiny]
> > > Are there any other SGML hacks that can be used to make <TEXTFLOW>
> > > unnecessary for empty APPLETs?
> > I don't think a "hack" is what is needed here.
>
> Isn't TEXTFLOW already a "hack"?

Yes, and I don't think it's what is needed here either :-)

> I was just hoping for something that doesn't require authors to supply a
> bogus element whenever they want to create APPLETs with empty content.
> [...]
> If not (if this is the only way to handle this problem), is it worth
> renaming the bogus TEXTFLOW element to NOAPPLET, just so it makes more
> sense to authors who have to include it explicitly?


It would make more sense (to me anyway) to require <NOAPPLET>
start- and end-tags when and only when the user wants to
include a NOAPPLET element.


    <!ELEMENT APPLET - - (PARAM*, NOAPPLET?)>
    <!ELEMENT NOAPPLET - - (%text;)*  -- or "ALTERNATE" -->

    <applet>
	<param>
	<noapplet>
	Get a  new browser!
	</noapplet>
    </applet>

I think this would be clearer, since it explicitly marks the
content as an alternate representation.   This would be
backward- and forward- compatible with deployed browsers (both
APPLET- aware and APPLET-unaware).  It would not be compatible
with current documents though.

To get backwards-compatibility with current documents that use
this feature, PARAMs in APPLETs could be handled the same
way that INPUT, SELECT, and TEXTAREA are handled in FORMS: add
PARAM to the %text; parameter entity with an application
convention that it's only valid inside APPLET elements.  Or,
PARAM could be made an inclusion exception on the APPLET
element.  (Since PARAM elements are not "contextual", this
wouldn't cause the same problems that using inclusions for
INPUT, SELECT, and TEXTAREA did.)

    <!ELEMENT APPLET - - (%text;)* +(PARAM)>

This is less restrictive than what is desired -- it would allow
PARAM anywhere inside an APPLET, instead of just at the
beginning -- but it would allow things like

      <applet code=foo.class width=100 height=100>
      Get a new browser!
      </applet>

which is all that's needed for compatibility.


Lastly, browser developers should be encouraged to write DTD
fragments *first*, instead of inventing a new syntax and hoping
that a DTD can be reverse-engineered for it.  That way it won't
be so hard to achieve backwards-compatibility with new features
in the future.


--Joe English

  joe@art.com

Received on Friday, 31 May 1996 20:18:55 UTC