PROPOSAL, Re: New HTML 3.2 specification

Tom Gerber wrote:
>Has anyone reviewed the new specification?   I think it would be nice if
>all the browsers would support it quickly and for ONCE include all the
>official options, like "SRC" for <UL>!

   There have been several reviews, or partial reviews, of the
HTML 3.2 materials, here and in the authoring newsgroup.  I've
been encouraged to offer some suggestions here, and I do so in
an encouraging spirit, as one concerned with accessibility and
interoperability, who also understands the desire of some authors
to "influence" presentation.  Since I'm new to most of you, 
I'll say that I have an artistic, not a technical background,
and that I maintain several sites and at last count roughly 120 
documents.  My views on Web Authorship are open to the curious at
   http://www.mcsr.olemiss.edu/~mudws/webhints.html

   Along with most people, I welcome the draft spec, and especially 
the DTD.  This is of immediate use, since it will allow many authors 
to improve and validate their existing documents.  I understand that 
the 3.2 "spec" is really an interim measure, soon to be supplemented 
by <OBJECT>, a more complete <TABLE>, and Style Sheets, and perhaps 
modified in other ways.  

   Some of us who follow the authoring newsgroup and the mailing
lists, and are aware of what authors want and can reasonably 
expect over a multifarious Web, would suggest a few minor 
additions to or deletions from the published DTD and summary.  
Your <UL SRC= > has been mentioned more than once, as one of 
the good ideas from the 3.0 draft that is clearly in demand, 
but inexplicably has not yet been sufficently implemented.

    Most of these ideas are asked for weekly, even daily,
in the authoring newsgroup.  Every one of them would 
eliminate the need for several awkward, anti-structural
hacks that have been devised to work around their absence.
Authors who have been using these ideas in their markup should
not be penalized by seeing their work fail validation, but 
should be rewarded by seeing these elegant and useful 
constructs implemented in the next generation of browsers.
By the same token, those developers who have worked so hard 
to test and implement much of the 3.0 draft should see
their work recognized and emulated by their larger and
more conservative competitors. 

   As a basis for discussion, I'd like to offer the following
as ideas whose time has come.  While some of them could be
incorporated in style sheets, I believe they would nonetheless
be useful as HTML.  For the most part, they have already been
implemented in browsers such as UdiWWW, w3-emacs, and Lynx-FM,
and are already used transparently and gracefully in existing
Web documents.  I shall confine myself to the HTML 3.2 materials
themselves, avoiding changes to the <OBJECT> and <TABLE> drafts.

________________________________________________________

                   block elements

   All block elements need to allow the CLEAR attribute.
There is no reason why this should be implemented only for 
<BR>.  Other common attributes for blocks, such as ID, MD,
LANG, etc. are unnecessary at this time, but CLASS is
currently put to good use in many existing documents, 
and will help ease the way to Style sheets.

   Many say that <BANNER> is still needed, even if Frames
are implemented, or Marquees are slowed down to a standstill.

   The <BLOCKQUOTE> element need not be superseded by <BQ>,
but it still needs an optional <CREDIT> element, as in the 
expired draft.  (As a substitute for <FIG>, the new <OBJECT>
element may also need <CREDIT> and <CAPTION>.) 

   The <UL> element may keep its new TYPE attribute, but needs
to add PLAIN, SRC= and CLEAR.  UL PLAIN and UL SRC= are desired
every day by real authors on the Web, and would allow authors
to formulate good-looking lists without ugly and counter-intuitive
hacks.  They are implemented seamlessly in UdiWWW and Lynx-FM.
One could even specify TYPE and SRC: this would display the
specified bullet shape on graphical browers when image-loading is 
turned off, or the custom bullet image when turned on.

   <OL> may keep its TYPE attribute, though there appears to be
a problem in validation, perhaps due to the case-insensitive
nature of attribute values.  Just add CLEAR.

   <LI> should also allow SRC as well as TYPE.

   <HR> may keep its Netscapish attributes, but should also
allow SRC= to produce custom rules on graphical browsers,
which decay to standard horizontal rules on the non-graphical.

                 character-level markup

   While the 3.0 draft presented logical text markup before
physical, the 3.2 summary has the reverse order.  This should
be restored, along with realistic warnings about reliability
over the Web.  While <STRIKE> may legitimately replace <S>,
authors still frequently request underline <U>, and often
inquire about <INS> and <DEL>.  

   <FONT> should be entirely relegated to style sheets, maybe 
with <FONT SIZE="+1"> and <FONT SIZE="-1"> allowed as synonyms 
for <BIG> and <SMALL>, for backward compatibility.  As currently
implemented, the existing <FONT> element is a positive hindrance
to communication over the World Wide Web, as many have pointed
out.
 
   Finally, the situation of <DIV> needs to be clarified;
is it still a super-block element (<DIV CLASS=Chapter> or
<DIV class=abstract>), or has it been changed to character-
level markup, as a mere pretext for disguising <CENTER>?

   I believe that these suggestions, if implemented and available,
would make the Web a friendlier place both for authors and users.
Any comments?

-- 
  Warren Steel                     mudws@mail.olemiss.edu
  Department of Music           University of Mississippi
          URL: http://www.mcsr.olemiss.edu/~mudws/


Warren Steel                        mudws@mail.olemiss.edu
Department of Music              University of Mississippi
          URL: http://www.mcsr.olemiss.edu/~mudws/

Received on Monday, 13 May 1996 12:34:24 UTC