HTML 4.0 concerns

  I applaud nearly every item I've seen in the proposed spec.  This
message is plain ASCII E-mail, and no `yelling' is intended.  There
are just five questions, on first read-through (well since peeks at
`Cougar' over the past few months) that I should bring to your attention:


1. TABLES
   (Ref struct/tables.html within the spec)

   There seems to be no way to indicate the preference for empty
   outlined cells.  While each browser implementation may be free
   to default to either behaviour - and certainly that can be seen
   in current usages - the implication of `flat space' versus 
   `empty cells' visually carries different connotations.

   Backwards compatibility with browsers not supporting various invisible
   glyph markup has been a consistent problem that does not SEEM to
   be addressed in the proposed standard.  In the past, the most
   compatible markup to force outlining of otherwise empty cells was
   the inclusion of a single ( <BR> ) linebreak markup.  This causes
   most rendering engines to render the cell with no content, rather
   than not rendering the cell, and has found far more cross-system
   compatibility (not to mention contextual meaning) than the inclusion
   of a single non-breaking space ( &nbsp; ) glyph to force the cell
   to not be considered empty.

   Ideally, the desired behaviour would be designatable both as a default
   by table, and individually by cell, at least for optional compliance.
   In conjunction with the W3C move toward moving specific stylistic
   information to separate or in-line stylesheets, perhaps this should
   be ONLY specified there - although this makes the construction of
   user agents arguably more complex.

2. SCRIPT events and multi-scripting support
   (Ref interact/scripts.html within the spec)

   Since no user agents (at least currently - that I've seen)
   report "text/javascript", "text/tcl", "text/vbscript", "text/perl"
   among their ACCEPT type lists (although most still say that they
   accept */*), even active production (server-side includes or 
   CGI genration) of pages best tailored to a given browser is
   difficult at best - and the user agent creation of multiple
   support becomes even MORE complex if (for example) an onLoad
   arbitrarily points to BOTH a JavaScript method and Tcl function.

   One of two things seem POSSIBLE with slight alteration to the current
   4.0 specs:

     <SCRIPT TYPE="text/javascript>
      <!-- hide
        document.write("Hello world!<BR>");
      // unhide -->
       <NOSCRIPT>
        <SCRIPT TYPE="text/tcl">
        <!--  hide  
         document write "Hello world!<BR>"
        # unhide -->
         <NOSCRIPT>
         <SCRIPT TYPE="text/vbasic">
           etc ....
          <NOSCRIPT>
            Hello world!<BR>
          </NOSCRIPT
         </SCRIPT>
        </NOSCRIPT>
       </SCRIPT>
      </NOSCRIPT>
     </SCRIPT>

   Which alters the <NOSCRIPT> element from generic scripting support
  alternate, to SPECIFIC script alternative, and MOVES the NOSCRIPT
  markup within the <SCRIPT> ... </SCRIPT> range.

   This allows cascaded compliance in-document, and potentially within
  linked or meta-included scripting as well, but may break with
  established convention.  Use of markup like this, however, would
  eliminate the question of event-driven markup-to-script links, such
  as onLoad, onSubmit, and the like.  Such markups could be actively
  written within the SCRIPT or NOSCRIPT tags for proper behaviour,
  and the preference of ORDER of scripting language uses becomes the
  design question of the page, rather than selection of one among many,
  for those desiring the full functionality across user agents.

   Unlike the <FRAMES> <FRAMESET> ... <NOFRAMES>, we are not dealing
  here with a boolean YES or NO - but rather potentially MANY scripts
  both embedded and linked - in a variety of languages.  This method
  is RECOMMENDED with Objects, so the concept certainly is transferrable.

   The META header tag then becomes purely advisory and in some cases
  even misleading - if different preference orders are used for different
  scripts - merely indicating a default TYPE when not specified in the
  begin SCRIPT tag.

   THE ALTERNATIVE, as I see it - is to drop the NOSCRIPT tag entirely,
  allow user agents which do not implement a given script to render
  everything within the script tag, but outside the ``hide'' comment
  brackets.  This leaves compliance with multi-line comments a requirement
  but changes the definition of <SCRIPT> ... </SCRIPT>, slightly.

   Under this scenario, <SCRIPT> ... </SCRIPT> still alters the meaning
  of the <!-- ... --> comment tags, but in a logical manner.  The
  <SCRIPT> ... </SCRIPT> becomes a `choose-alternative' markup with ANY
  valid HTML permitted within it, but the first comment treated by
  enabled user agents as scripting to feed to the script processor.  IF
  the user agent is able to properly handle the script, then it does NOT
  render anything contained following that comment, until the </SCRIPT>
  tag.   If the SRC= attribute is present, the change-of-meaning for the
  comment tags is NOT invoked.
   
   The most extreme example under this would be (of other definitions
   are changed to permit)....

    <HTML>
     <SCRIPT TYPE="text/tcl">
      <!-- let's write the whole page in Tcl, including meta info
       proc ...
       proc ...
       inline invocations
      # end hide -->
      <SCRIPT TYPE="text/javascript">
       <!-- hide JavaScript write of entire page including meta info
        proc ...
        proc ...
        inline invocations
       // end hide -->
  etc. etc. for other scripting langauges
    ...
     </SCRIPT>
    </SCRIPT>
   </HTML>

   ... with the SHORTEST being ...
    <HTML>
     <HEAD>
      ... meta tags for this page ...
     </HEAD>
     <BODY possibly customized for unscripted presentation>
     <SCRIPT TYPE="text/javascript" SRC="url which loads Mocha page">
      <SCRIPT TYPE="text/tcl" SRC="url which loads Tcl based page">
       <SCRIPT TYPE="text/vbasic" SRC="url which replaces with VBScript">
        ... body for browsers which suppport NONE of the above scripts
       </SCRIPT>
      </SCRIPT>
     </SCRIPT>
     </BODY>
    </HTML>

     As a practical matter, this is VERY similar to the usage currently
  specified for FRAMES, and in most cases, frames pages might be loaded
  by one of the scripts.  In theory, however, this script-nest could
  logically be nested surrounding the <BODY> segment as NOFRAMES
  tags so often are - illegally perhaps, but QUITE logically.

     One thing to be defined here, though, is whether or not META
  information carries across to potential WHOLE PAGES done in scripting
  languages.  Can the script re-define stylesheet references?  If so
  in HTML or only via its own supported scripting methods and procedures?

3. Scripting where?

  BUT STILL NOT CORRECTED ...
   from the mistake in the Wilbur spec, is the inclusion of <SCRIPT>
  sequences in within the HEAD segment of a document.  While a script
  is arguably meta-data, it forms an intrinsic part of the document,
  has no use in an HTTP HEAD request, and breaks the optional </HEAD>
  where a HEAD end defaults when non-supported-in-head markup or CDATA
  is encountered.  This was a major departure for the W3c's longstanding
  endorsement of backward compatibility.

    Perhaps the REAL question here is if SCRIPT data belongs within
  the range of <HTML>...</HTML>, although Wilbur acceptance and massive
  current usage makes deprecation of the SCRIPT tag and content quite
  premature, until OBJECT uses are able to subsume all such.

    Perhaps too, this backwards incompatibility should continue to be
  ignored, as it now might allow the SCRIPT generation of meta info.


4.  Toggling Frames Support - easy for User Agents, hard for writers

    Currently, someone wishing to present frames, user-selected non-
    frames presentations, and non-frame-supported presentations must
    have SEVERAL copies of many things.  

    Would the W3C consider a RECOMMENDATION to the writers of user agents
    who support scripting and frames that a FRAMES SUPPORT toggle be
    implemented in the supported scripting languages.  This would allow
    for greatly reduced web traffic, reduced-source HTML management for
    HTTPd operators - and possibly benefits I've not yet thought of.

    <HTML>
     <HEAD>
       .. meta info
      <FRAMESET ...>
       <FRAME ...
        ...
      </FRAMESET>
     </HEAD>
     </BODY>
     <SCRIPT TYPE="language of choice MIME type">
      <!-- hide script pseudocoding
        create button target disableFrames() label "Toggle Frames"
       endcomment -->
     </SCRIPT>
     <NOFRAMES>
       page to display if frames are disabled or not supported
     </NOFRAMES>
     </BODY>
    </HTML>

    A frame in the above example would contain a comparable button,
  and with logical SCRIPT language support as in my recommendation #2
  above in point 2, the actual frames.  User agents could OPTIONALLY
  support the above button which is inside the alternative-to-frames
  text but outside the <NOFRAMES> markup during the load of the frames
  content.

     Currently, a variety of methods are being used across the web
  to insure best presentation of frame content, including redirection
  based upon HTTP REFERER - This should at least help that situation.

5.   Clarification from previous revisions of HTTP (and META HTTP-EQUIV)
  identification for i18n.

     The original HTTP drafts specified existing header standards for
  identification of content, many by reference, including:

        Content-Type: text/html
  and now Content-Type: text/html;charset=iso8859-1

  but also
        Character-Set: ISO-8859-1
        Media-Type: text/html;charset=iso8859-1

  Additionally:
        Content-Language: en-US

  but now LANG= attributes.

      Frankly, this brings a confusion into the standards arena, as does
   the fully legal (because of Usenet/E-Mail header inclusion by
   reference)

      <META HTTP-EQUIV="Keywords" CONTENT="keyword list">

  and growing use of 

      <META NAME="Keywords" CONTENT="keyword list">

  which would of course NOT be sent as meta information in HTTP protocol.

  And finally, 

   META HTTP-EQUIV="Version" CONTENT="d.dd"

  which for static documents are a document revision having NOTHING to do
  with the generation software, with ...

   META NAME="Generator" CONTENT="some-program-name-no-version-etc"

  versus

   META HTTP-EQUIV="Posting-Version" CONTENT="engine revdate; site fqdn"
  e.g.              Posting-Version         myWeb 1997/08/01; site w3c.org

  which slight modification (use of 4-digit year) addresses the Y2K
  changes, as well.

  As more and more active elements in pages come into being, as the trend 
  seems to be - the `claimed' source of a page may become more and more
  important.


THANKYOU

   ... for reviewing these concerns.  Feel free to accept or reject any
  just please don't ignore them outright.

    Also, you may find of interest my DTML draft specification (Display
  Technology Markup Language) proposal currently posted in a single
  HTML page at <URL: http://gtcs.com/dtml/ > - deliberately aimed at
  multi-object rendering in 3-D space in support of HTML.  This is
  not potentially quite a fancy as VRML, but could be embedded in
  HTML with only about 2 restriction changes.  It's been posted for
  review for several months had has had very little feed-back so far,
  so it may just be a little too forward looking.   I have not YET
  attempted to reconcile this draft with XML, nor created anything
  approaching a DTD.   It can be *ignored* for to-paper rendering, and
  has room for pseudo-display such as voice description of the scene
  bringing 3-D space more fully into the `enabled display' category.
  Since it is based on the same precepts as HTML, much of the
  implementation would require *only* tabular extensions to current
  parsing.

	Bruce Gingery	<bgingery@gtcs.com>
        Gateways to CyberSpace - and - Advanced Integrators, LLC

Received on Thursday, 10 July 1997 10:59:04 UTC