summary of proposed revisions

Warren Steel (mudws@mail.olemiss.edu)
Tue, 21 May 1996 11:51:00 -0500


Message-Id: <199605211644.LAA28945@sunset.backbone.olemiss.edu>
Date: Tue, 21 May 1996 11:51:00 -0500
To: www-html@w3.org
From: Warren Steel <mudws@mail.olemiss.edu>
Subject: summary of proposed revisions

   Dan's point about maintaining focus is well taken.  The
release of the "Wilbur" draft spec and DTD give us a place
to start.  If anyone wishes to make changes in these materials,
or retain more from the 3.0 draft, then that person needs to
offer changes in as specific language as possible, along with
persuasive reasons why they are necessary or desirable.  The
participation of major developers and vendors on the ERB is
positive sign, and shows that they value standards and inter-
operability.  The 3.2 materials, for the most part, describe
what these vendors have already implemented--but this is by
no means the sum of HTML as currently used on the Web.  Many
members of this mailing list have experiences with browsers
like Arena, Lynx-FM, UdiWWW, speech browsers, searchers,
indexers, and other user agents--this experience can be of
great value to the great powers that sit on the ERB.  

   From an author's point of view, especially those conscientious
authors who use DTDs and validation tools, it would be a shame if
we had to remove markup that is currently useful (if only to a
minority), in order to pass validation.   Some of these items do 
not *require* immediate implementation by "market leaders" to be 
useful, and they hurt no-one.  Others are requested almost daily 
in the authoring newsgroup and other forums, and offer these 
vendors a golden opportunity to respond to real needs of real 
authors on the real Web.

   There was some useful discussion last week of list attributes--
not total agreement, but almost everyone felt that some additions
from the 3.0 draft would be useful today, as part of HTML, and would
do no harm.  Discussion subsided not because the ideas were rejected,
but because there was at least a rough consensus.  The same with other
enhancements proposed last week.  Those who are able to write formal
proposals, specs, and DTDs have the advantage over me, but I'm
certainly willing to try once more to express the mind of authors
seeking solutions to current problems.  My personal preference was
for as minimal a change as possible from the 3.2 drafts.  Several
correspondents pointed out, however, that a group of attributes
currently in documents, but not used by today's browsers, would 
enable these authors to validate their work, while pointing the
way to useful implementations in the future.  And again, I'm
ignoring Tables, Objects, and Style Sheets, since these are part
of the next wave of standards revision.  Here's what I have left
from last week:

________________________________________________________

                   block elements

Attributes: CLEAR, CLASS, ID 
    [see MegaZone's comments; some would add LANG, MD]

   All block elements need to allow the CLEAR attribute.
There is no reason why this should be implemented only for 
<BR>.  CLASS, at least, is in use in many current documents, 
and will help ease the way to Style sheets.

   Many say that <BANNER> is still needed, even if Frames
are implemented.  Perhaps <MARQUEE> can be admitted as an
alias to <BANNER>, and the specifications reconciled.

   The <BLOCKQUOTE> may be aliased as <BQ>, but it still needs 
an optional <CREDIT> element, as in the expired draft.  

   For lists and list items, we have a little more detail, 
thanks to Charles Peyton Taylor, Foteos Macrides, and others,
who have labored to improve the meager capabilities of the
3.2 draft:

_________________________________________________________________
<UL>  
    CLASS= , CLEAR= , ID                [common to block elements]
    PLAIN, COMPACT, TYPE= , SRC=

<OL>  
    CLASS= , CLEAR= , ID                 [common to block elements]
    COMPACT, CONTINUE, TYPE= , START=/SEQNUM= [mutual aliases]

<LI>  
    TYPE= , VALUE= , SRC=

                 Also for horizontal rules:
_________________________________________________________________
<HR>  
    CLASS= , CLEAR=                     [common to block elements]
    NOSHADE, ALIGN= , SIZE= , WIDTH= , SRC= 
_________________________________________________________________
 
 
                 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>.  Paul Fidler argued convincingly
for speech-browser-friendly elements like <ABBREV> and <ACRONYM>,
which are currently used by authors, though not distinctively
rendered by visual browsers, Others mentioned <AUTHOR> and 
<PERSON> for their aid in indexing.

   <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.  The issue
(which I have taken up at length) is probably moot anyway, since
we will have major browsers that implement style sheets before
we have major browsers that allow users to completely disable
Font markup (the only condition under which <FONT> could exist 
without unavoidable and unpredictable data loss).
 
   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>?
James Tauber has suggested removing PCDATA from its content.

   Finally, there was some discussion of <TAB>.  Foteos provided
a rather complex test of this element.  Did anyone try it out?
It's certainly in demand by authors, but is a workable solution
within reach?  Many would be content with a fixed width space,
while a true "tabulator" function could obviate the need for
some HTML Tables.  Demand for this function may be expected to
subside, but not disappear, with the advent of style sheets.

   The foregoing is not at all what Dan was inviting, but instead
a summary of recent suggestions, to serve as a starting point for 
the formal descriptions and DTDs for individual elements and markup
classes.  Any takers?



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