For the future - requests for the W3C
MegaZone (megazone@livingston.com)
Mon, 13 May 1996 15:36:24 -0700 (PDT)
Message-Id: <199605132236.PAA08940@server.livingston.com>
Subject: For the future - requests for the W3C
To: www-html@w3.org
Date: Mon, 13 May 1996 15:36:24 -0700 (PDT)
From: MegaZone <megazone@livingston.com>
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