For the future - requests for the W3C

Once upon a time Warren Steel shaped the electrons to say...
>                   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.

I would agree that both CLASS and CLEAR would be very welcome, but I
also feel that ID would be a good addition.  LANG needs more work, not
ready yet.  And I have to admit I'm blanking on MD... (look) oh, yeah.
No, I don't think we really need checksums in any hurry.

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

Yes.  *PLEASE* inpliment this!  It is not very complicated, and it would
be nice to have a generally accepted way of adding fixed navigation bars
to pages without having frames and the associated complexity.

>   The <BLOCKQUOTE> element need not be superseded by <BQ>,

I would just make <BLOCKQUOTE> alias to <BQ>

>but it still needs an optional <CREDIT> element, as in the 

Very much agreed.

>expired draft.  (As a substitute for <FIG>, the new <OBJECT>
>element may also need <CREDIT> and <CAPTION>.) 

I just addressed this in another email, I would like to see this done
to make <OBJECT> a real <FIG> replacement.

>   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

Or every couple of hours... ;-)

>   <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.

This I'm not sure about.  If we add SRC to UL, do we need SRC here?
Or better yet, vice-versa?

>   <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.

I'd like to see it be able to repeat an image end to end to fill
the percentage set, so you can specify a tiny image to dl once that
will draw a line, like a link in a chain to draw a chain.  But I
suppose this would require some kind of REPEAT=#, so it is probably
too much.

>                 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

Please.

>over the Web.  While <STRIKE> may legitimately replace <S>,
>authors still frequently request underline <U>, and often

What *is* the real reason underlining hasn't been added?  It has
been around for a long time now.

>inquire about <INS> and <DEL>.  

I haven't see these asked about actually...
---
INS 
  The <INS> element is used for inserted text, for instance in legal documents.
DEL 
  The <DEL> is used for deleted text, for instance in legal documents.
---

I must confess ignorance here - I'm not familiar with this usage.

>   <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.

They are only a hinderance if abused, IMHO.  Just as I can use other tags
to make documents that are hard to read.

>   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 certainly hope <DIV> retains the abilities of 3.0 - I'd like to see
CLASS, CLEAR, and ID added soon.

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

How about <TAB>?  I don't mean we have to do the full 3.0 thing with
ID and TO, but just a simple way to allow authors to do indenting?
Now we have people putting in single pixle high, transparent one color
gifs to add formatting.  Tabbing in text is a long time formatting
technique used in print for ages, and it does provide a very nice
visual cue.  Why can't we just have <TAB> which is used to indent
text, as a character element it could just display as a short blank
area.  We can add the ability to set tab stops and the 3.0 features
later.

I'd also like to see <ACRONYM> and <ABBREV> allowed in the DTD.  Text
browsers need not do anything special with them, but we should keep
in mind speech based browsers.

3.2 also seems to have lost align=justify - what is up with that?

Bring back the <LH> tag!  This should be simple, but it seems to be
missing in 3.2.

In ordered lists I have seen a number of people looking for something
like the CONTINUE attribute.

It would be easier to compare if we had a detailed spec on 3.2 as we do for
3.0 at <http://www.w3.org/pub/WWW/MarkUp/html3/>

-MZ
--
Although I work for Livingston Enterprises Technical Support, I alone am
responsible for everything contained herein.  So don't waste my managers'
time bitching to them if you don't like something I've said.  Flame me.
Phone: 800-458-9966  support@livingston.com  <http://www.livingston.com/> 
FAX: 510-426-8951    6920 Koll Center Parkway #220, Pleasanton, CA 94566

Received on Monday, 13 May 1996 18:36:34 UTC