Re: Proposed extensions to HTML

Michael Johnson (michaelj@relay.relay.com)
Fri, 18 Nov 94 08:29:08 EST


>> <ISINDEX>
>> To the ISINDEX element we have added the PROMPT tag. ISINDEX
>> indicates that a document is a searchable index. PROMPT has
>> been added so the document author can specify what message they
>> want to appear before the text input field of the index. The
>> default is of course that unfortunate message: This is a
>> searchable index. Enter search keywords:

Ok, this is a reasonable extension.

>> <HR>
>> The HR element specifies that a horizontal rule of some sort
>> (The default being a shaded engraved line) be drawn across the
>> page. To this element we have added 4 new tags to allow the
>> document author some ability to describe how the horizontal
>> rule should look.

This strikes me as unnecessary fluff.

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

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

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

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

>> To ordered list we have added the
>> VALUE element so you can change the count, for that list item
>> and all subsequent.

Perhaps.

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

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

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

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

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

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

The second use of WBR sounds like it should be a conditional hyphen entity.

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

>>
>> <CENTER>
>> You aren't dreaming, yes you can center your text.

HTML3 does this quite adequately with ALIGN attributes on various tags.

Michael Johnson
Relay Technology, Inc.