Re: For the future - requests for the W3C

You, MegaZone wrote:
++ 
++ Once upon a time Warren Steel shaped the electrons to say...
++ >                   block elements

Let me first say I very much agree with Warrens article.

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

I agree, MD is not very important. However, it cannot hurt to put it
in the DTD. Most browsers won't do anything with MD, but that doesn't
degrade the document - it is an attribute which can safely be ignored.
However, if there would be a browser which deals with it, it would
be convenient to have it in the DTD; if only to validate documents.

Same for LANG. Most mentioned feature of LANG is the style of quotes.
But whether << >>, " " or `` '' is used for quotes isn't really
important, people will still know what is meant. However, for speech
devices, it might be very important. Perhaps less on the American market,
where almost all pages will be in English. But people in the Netherlands,
Germany, France, etc, will read a significant number of pages in
their own language. To know in which language a piece of text is
written is important for the pronouncation. The majority of browsers
can safely ignore the attribute, but let it be allowed for the few
who do use it. Just like <ABBREV> and <ACRONYM> (of which you do agree
they should be there.)

++ >   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?

Allowing SRC to <LI> allows for different bullets in the same list.
(For instance, an index with different bullets for "advanced" topics).
Adding SRC to <UL> in stead of repeating it in each <LI> is just
convenience for the author. I don't see anything wrong about that.

[ Snip ]

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

If you do not have ID and TO, wouldn't <TAB> give the same problems
as graphics now? That is, give very ugly effects on browsers which
already indent paragraphs? I think indenting paragraphs should be
dealt with in style sheets -- that would give me an opportunity 
to turn it off. *grin*


Abigail

Received on Monday, 13 May 1996 21:15:10 UTC