That depends on who is defining what is necessary.
I think that an author/publisher should have the ability
to specify their formatting preferences in a document that
they are providing over the Web. I also think that it would be
a mistake for browsers not to provide a way to override
the author's preferences, or to assign weighted ranking
to author/reader preferences.
>
> >>
> >> <UL>
> >> We have added a TYPE tag
> >> to the UL element so no matter what your indent level you can
> >> specify whether you want a TYPE=disc, TYPE=circle, or
> >> TYPE=square as your bullet.
>
> Nope. A browser might reasonably put this under control of the user, or
> maybe a style sheet, but in the markup? No way.
Yes way. Again, as a provider of information I need some control
over presentation of information. Many DTDs that I have worked with
have offered a means to specify the mark that I want to use in
unordered (or marked) lists. I don't see why HTML should not offer
a similar mechanism through attributes. It is up to the browser
implementors to provide a mechanism through which a reader can override.
>
> >> <OL>
> >> Your average ordered list counts 1, 2, 3, ... etc. We have also
> >> added the TYPE tag to this element to allow authors to specify
> >> whether the want their list items marked with: capital letters
> >> (TYPE=A), small letters (TYPE=a), large roman numerals
> >> (TYPE=I), small roman numerals (TYPE=i), or the default numbers
> >> (TYPE=1).
>
> Again, style sheet maybe. In the markup, no way.
Yes way. See my argument above.
There is a technical reason not to use the specific TYPE values
that have offered. An SGML parser is not going to differentiate
between "A" and "a" or "I" and "i". In other DTDs, I have seen
"ucalpha", "lcalpha", "ucroman", "lcroman" and "1" or "cardinal".
It might be interesting to add "ordinal" to the list also.
Furthermore, it might be useful to add PREFIX and APPEND attributes
so that I can specify values that might yield "(a)" or "[1]" or
even "1."
>
> >> For lists that wish to start at values other than 1 we have the
> >> new tag START. START is always specified in the default
> >> numbers, and will be converted based on TYPE before display.
> >> Thus START=5 would display either an 'E', 'e', 'V', 'v', or '5'
> >> based on the TYPE tag.
>
> Maybe, as an attribute, but definitely not as a tag.
Yes, I think that there is probably a terminology problem here.
I am sure that they meant attribute.
>
> >> <LI>
> >> To give even more flexibility to lists, we thought it would be
> >> nice if the author could change the list type,
>
> To make lists even more confusing to the reader, we thought it would be
> clever to allow the author to totally screw with the reader's mind.
>
> Again, no.
I think that I would have to be convinced of the merit of this one.
I really can't see why this is not better achieved by closing one
list and starting another.
>
> >> To ordered list we have added the
> >> VALUE element so you can change the count, for that list item
> >> and all subsequent.
>
> Perhaps.
I think that what is meant here is that <LI VALUE="NUMBER"> is
interpreted by a browser to reset the counter for the remainder
of the list. Again, I wonder why it is not better achieved by
closing the existing list and starting another with the
appropriate starting number.
>
> >> <IMG>
> >> The IMG tag is probably the most extended tag.
>
> The IMG tag is probably the most mangled tag. HTML3 uses FIG for left, right
> and center alignment of images. The other alignments strike me as excessive.
>
> >> <IMG WIDTH=value HEIGHT=value>
> >> The WIDTH and HEIGHT tags were added to IMG mainly to
> >> speed up display of the document. If the author specifies
> >> these, the viewer of their document will not have to wait
> >> for the image to be loaded over the network and its size
> >> calculated.
>
> These might have value, but should be strictly treated as hints.
What else could they be used as?
>
> >> <IMG BORDER=value>
> >> This lets the document author control the thickness of
> >> the border around an image displayed.
>
> This is something that should be under user control, not author control. The
> thickness of borders should be consistent throughout a document.
Maybe, maybe not. This is, again, something that the author
should be able to declare a preference for. If you don't
provide the author with control at this level, they will
exert control at the graphic level. You can't win.
>
> >> <IMG VSPACE=value HSPACE=value>
> >> For the floating images it is likely that the author
> >> does not want them pressing up against the text wrapped
> >> around the image. VSPACE controls the vertical space
> >> above and below the image, while HSPACE controls the
> >> horizontal space to the left and right of the image.
>
> This is unnecessary. Establishing a convention that text flowing around
> an image is to clear the image by one blank space and that lines before and
> after the image may not impinge upon it is sufficient.
That convention might satisfy your needs, but not those of many others.
It is not necessary for you to use these attributes, and if your
browser provides you a way to override author preferences, you might
not have to ever know about author preferences, but the author
should have the ability to specify them somehow.
>
> >> <BR>
> >> With the addition of floating images, we needed to expand the
> >> BR tag. Normal BR still just inserts a line break. We have
> >> added a CLEAR tag to BR, so CLEAR=left will break the line, and
> >> move vertically down until you have a clear left margin (no
> >> floating images). CLEAR=right does the same for the right
> >> margin, and CLEAR=all moves down until both margins are clear
> >> of images.
>
> Maybe. I suspect that a special-purpose tag for this would be better than
> perverting the BR tag.
I'd like to be convinced.
>
> >>
> >> New Elements
> >>
> >> <NOBR>
> >> The NOBR element stands for NO BReak. This means all the text
> >> between the start and end of the NOBR elements cannot have line
> >> breaks inserted between them. While NOBR is essential for those
> >> odd character sequences you really don't want broken, please be
> >> careful; long text strings inside of NOBR elements can look
> >> rather odd.
>
> HTML3 uses the WRAP attribute on <P> or the <LIT> tag to do this. Another
> tag is not necessary.
I need to be convinced.
>
> >>
> >> <WBR>
> >> The WBR element stands for Word BReak. This is for the very
> >> rare case when you have a NOBR section and you know exactly
> >> where you want it to break. Also, any time you want to give
> >> Netscape help by telling it where a word is allowed to be
> >> broken. The WBR element does not force a line break (BR does
> >> that) it simply lets Netscape know where a line break is
> >> allowed to be inserted if needed.
>
> The first use of <WBR> is completely redundant. Using <BR> or simply starting
> a new line in the markup is sufficient.
If I were convinced of the merits of <NOBR> I might appreciate <WBR>
>
> The second use of WBR sounds like it should be a conditional hyphen entity.
Yes, the soft-hyphen which is not currently available in most
browsers is what is needed here.
>
> >>
> >> <FONT SIZE=value>
> >> Surprise! You can change the font size. Valid values range from
>
> Surprise! is right. This is another area that should be under control of the
> user. If there are specific semantic places where a font size change makes
> sense, then a style tag should be defined for that style. BASEFONT is also
> unacceptable.
Again, I think that browsers could be trained to ignore the author's
preferences if that was desired by the reader. No harm, no foul.
However, I have to agree with Michael and Liam that <BASEFONT>
is unacceptable -- especially in light of <FONT SIZE=value>
>
> >>
> >> <CENTER>
> >> You aren't dreaming, yes you can center your text.
>
> HTML3 does this quite adequately with ALIGN attributes on various tags.
I need to be convinced.
>
> Michael Johnson
> Relay Technology, Inc.