MCOM html extensions

10 views
Skip to first unread message

an10...@anon.penet.fi

unread,
Nov 11, 1994, 11:44:57 PM11/11/94
to

EXTENSIONS TO HTML

These are proposed extensions to the soon to be released HTML 2.0
specification. Mosaic Communications will be working with the
appropriate standards bodys, including W3O, and the authors of other
WWW browsers in an attempt to have these extensions available in all
browsers in the near future. All the Netscape extensions to HTML
take the form of additional tags and attributes added to the HTML
specification and are specifically designed not to break existing WWW
browsers.

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

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

<HR SIZE=number>
The SIZE tag lets the author give an indication of how
thick they wish the horizontal rule to be.

<HR WIDTH=number|percent>
The default horizontal rule is always as wide as the
page. With the WIDTH tag, the author can specify an exact
width in pixels, or a relative width measured in percent
of document width.

<HR ALIGN=left|right|center>
Now that horizontal rules do not have to be the width of
the page we need to allow the author to specify whether
they should be pushed up against the left margin, the
right margin, or centered in the page.

<HR NOSHADE>
Finally, for those times when you really want a solid
bar, the NOSHADE tag lets you specify that you do not
want any fancy shading of your horizontal rule.

<UL>
Your basic bulleted list has a default progression of bullet
types that changes as you move through indented levels. From a
solid disc, to a circle to a square. 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.

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

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.

<LI>
To give even more flexibility to lists, we thought it would be
nice if the author could change the list type, and for ordered
lists the list count index as they progressed. To this end we
added the TYPE tag to the LI element as well. It takes the same
values as either UL or OL depending on the type of list you are
in, and it changes the list type for that item, and all
subsequent items. For ordered lists we have also added the
VALUE element so you can change the count, for that list item
and all subsequent.

<IMG>
The IMG tag is probably the most extended tag.

<IMG
ALIGN=left|right|top|texttop|middle|absmiddle|baseline|botto
m|absbottom>
The additions to your ALIGN options needs a lot of
explanation. First, the values "left" and "right". Images
with those alignments are an entirely new floating
image type. A ALIGN=left image will float down and over
to the left margin (into the next available space there),
and subsequent text will wrap around the right hand side
of that image. Likewise for ALIGN=right the image aligns
with the right margin, and the text wraps around the
left.

The rest of the align options are my way of trying to
correct for the horrible errors I made when first
implementing the IMG tag, without destroying the look of
existing documents. ALIGN=top does just what it always
did, which is align itself with the top of the tallest
item in the line. ALIGN=texttop does what many people
thought top should do which is align itself with the top
of the tallest text in the line (this is usually but not
always the same as ALIGN=top). ALIGN=middle does just
what it always did, it aligns the baseline of the current
line with the middle of the image. ALIGN=absmiddle does
what middle should have done which is align the middle of
the current line with the middle of the image.
ALIGN=baseline aligns the bottom of the image with the
baseline of the current line. ALIGN=bottom does just what
it always did (which is identical to ALIGN=baseline but
baseline is a better name). ALIGN=absbottom does what
bottom should have done which is align the bottom of the
image with the bottom of the current line.

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

<IMG BORDER=value>
This lets the document author control the thickness of
the border around an image displayed. Warning: setting
BORDER=0 on images that are also part of anchors may
confuse your users as they are used to a colored border
indicating an image is an anchor.

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

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

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.

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

<FONT SIZE=value>
Surprise! You can change the font size. Valid values range from
1-7. The default font size is 3. The value given to size can
optionally have a '+' or '-' character in front of it to
specify that it is relative the the document basefont. The
default basefont is 3, and can be changed with the BASEFONT
element.

<BASEFONT SIZE=value>
This changes the size of the BASEFONT that all relative font
changes are based on. It defaults to 3, and has a valid range
of 1-7.

<CENTER>
You aren't dreaming, yes you can center your text. All lines of
text between the begin and end of CENTER are centered between
the current left and right margins. A new tag has been
introduced rather than using the proposed <P Align="center">
because using <P Align="center"> breaks many existing browsers
when the <P> tag is used as a container. The <P Align="center">
tag is also less general and does not support all cases where
centering may be desired.

Behavioral Changes

Font attributes are now properly cumulative. Text inside something
like
<i><tt><font size=6><b>Text here</b></font></tt></i>
will be italic fixed bold text of size 6.

Netscape should now properly deal with the awful HTML comment
sequence. This should be: <!-- Comment here --> These comments can
include other elements, and thus be used to quickly comment out large
chunks of markup.

Line breaking is a little more under control now. Unless specified
with a formatting element, lines can only be broken where empty space
occurs in the original document. This means any spaces, tabs, or
newlines. You should never again have the sequence <A HREF=url>Anchor
here</A>. broken between the highlighted anchor and the period.

New Entities

In addition to the [1]usual & escaped entities:
&reg; -> Registered Trademark -> &reg;
&copy; -> Copyright -> &copy;

_________________________________________________________________

[2]in...@mcom.com
Copyright &copy; 1994 Mosaic Communications Corporation.

-------------------------------------------------------------------------
To find out more about the anon service, send mail to he...@anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to ad...@anon.penet.fi.

Patrick Stickler

unread,
Nov 13, 1994, 5:37:21 PM11/13/94
to
In article <045303Z...@anon.penet.fi>, <an10...@anon.penet.fi> wrote:
>
> EXTENSIONS TO HTML
>
> These are proposed extensions to the soon to be released HTML 2.0
> specification. Mosaic Communications will be working with the
> appropriate standards bodys, including W3O, and the authors of other
> WWW browsers in an attempt to have these extensions available in all
> browsers in the near future. All the Netscape extensions to HTML
> take the form of additional tags and attributes added to the HTML
> specification and are specifically designed not to break existing WWW
> browsers.
>
> <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:

Don't you mean that you've added a PROMPT *ATTRIBUTE*?? Let's keep our
SGML terms straight (remember HTML is SGML...)

I personally find the default message quite appropriate and informative,
although I can certainly appreciate the usefulness of a custom message.

>
> <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.
>
> <HR SIZE=number>
> The SIZE tag lets the author give an indication of how
> thick they wish the horizontal rule to be.

Firstly, don't you think that THICKNESS is a more appropriate attribute name
(which conforms to common typographical usage)? Also, how can the author
know that his/her preferred width as it appears on his/her screen will be
appropriate for all display devices supported by HTML browsers?

>
> <HR WIDTH=number|percent>
> The default horizontal rule is always as wide as the
> page. With the WIDTH tag, the author can specify an exact
> width in pixels, or a relative width measured in percent
> of document width.
>

Again, how can an author know how wide the user's window is? Also, how
many authors work regularly with pixel sizes? Why not allow specifications
in any of the common units of measure (inches, mm, cm, picas, as well as
points)?

> <HR ALIGN=left|right|center>
> Now that horizontal rules do not have to be the width of
> the page we need to allow the author to specify whether
> they should be pushed up against the left margin, the
> right margin, or centered in the page.
>
> <HR NOSHADE>
> Finally, for those times when you really want a solid
> bar, the NOSHADE tag lets you specify that you do not
> want any fancy shading of your horizontal rule.

Isn't this based solely on typical style interpretations of HTML by common
browsers and really in the realm of how the browser is designed to display
horizontal lines?

>
> <UL>
> Your basic bulleted list has a default progression of bullet
> types that changes as you move through indented levels. From a
> solid disc, to a circle to a square. 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.
>

Nice. This can be very useful and is a good example of using attributes
for formatting specifications.

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

(ditto as above)

> <LI>
> To give even more flexibility to lists, we thought it would be
> nice if the author could change the list type, and for ordered
> lists the list count index as they progressed. To this end we
> added the TYPE tag to the LI element as well. It takes the same
> values as either UL or OL depending on the type of list you are
> in, and it changes the list type for that item, and all
> subsequent items. For ordered lists we have also added the
> VALUE element so you can change the count, for that list item
> and all subsequent.
>

WHOA THERE! Change the syntactic context of the list elements on the fly?!
Bad. Bad. Bad. This change is only addressing a need to override the default
styles defined by a browser. The specifications of list types are functional,
not stylistic. If the presentation of list items requires more flexibility,
then add attributes that define the general characteristics of list elements
in all contexts, and then define defaults for particluar contexts (OL,
UL, etc.).

These additions will be welcome. I would go further and add an attribute
for specifying image compression, allowing images to be stored and
transferred in a compressed format, then decompressed before presentation
(or does the http deamon support this already?).

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

This element may end up biting users if an author has a nice wide screen
and an end user doesn't (I can easily see PDA`s supporting HTML in the
near future, and these are often restricted to narrow screen widths...

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

This will be very useful with non-English languages where hyphenation
is much more of a challenge than most Americans encounter.

> <FONT SIZE=value>
> Surprise! You can change the font size. Valid values range from
> 1-7. The default font size is 3. The value given to size can
> optionally have a '+' or '-' character in front of it to
> specify that it is relative the the document basefont. The
> default basefont is 3, and can be changed with the BASEFONT
> element.


As with many of the MCC proposed extensions, this opens up a pandora's
box for difficult/impossible/annoying to read documents where authors
unskilled in page layout go font crazy and hence devaluate their
information. One of the nicest features IMHO of Mosaic/Lynx is that
there is a consistent uniformity to the style of presentation. Even
though many forms of information could be enhanced with more talented
layout commands, the user/ready should always IMHO be able to override
these extensions (even within Netscape) and view the information in
a "traditional" or "style neutral" format.

>
> <BASEFONT SIZE=value>
> This changes the size of the BASEFONT that all relative font
> changes are based on. It defaults to 3, and has a valid range
> of 1-7.
>
> <CENTER>
> You aren't dreaming, yes you can center your text. All lines of
> text between the begin and end of CENTER are centered between
> the current left and right margins. A new tag has been
> introduced rather than using the proposed <P Align="center">
> because using <P Align="center"> breaks many existing browsers
> when the <P> tag is used as a container. The <P Align="center">
> tag is also less general and does not support all cases where
> centering may be desired.
>
>Behavioral Changes
>

Do you mean for Netscape, not the default HTML interpretation?

> Font attributes are now properly cumulative. Text inside something
> like
> <i><tt><font size=6><b>Text here</b></font></tt></i>
> will be italic fixed bold text of size 6.
>
> Netscape should now properly deal with the awful HTML comment
> sequence. This should be: <!-- Comment here --> These comments can
> include other elements, and thus be used to quickly comment out large
> chunks of markup.
>


It's not the HTML comment sequence, it's the SGML comment sequence, and
I personally don't find it so terribly awful.

> Line breaking is a little more under control now. Unless specified
> with a formatting element, lines can only be broken where empty space
> occurs in the original document. This means any spaces, tabs, or
> newlines. You should never again have the sequence <A HREF=url>Anchor
> here</A>. broken between the highlighted anchor and the period.
>
>New Entities
>
> In addition to the [1]usual & escaped entities:
> &reg; -> Registered Trademark -> &reg;
> &copy; -> Copyright -> &copy;
>
> _________________________________________________________________
>
> [2]in...@mcom.com
> Copyright &copy; 1994 Mosaic Communications Corporation.
>
>-------------------------------------------------------------------------
>To find out more about the anon service, send mail to he...@anon.penet.fi.
>Due to the double-blind, any mail replies to this message will be anonymized,
>and an anonymous id will be allocated automatically. You have been warned.
>Please report any problems, inappropriate use etc. to ad...@anon.penet.fi.

Why was this posted anonymously? Isn't this an official posting on
behalf of MCC?

In a posting I made earlier this week regarding your proposed extensions,
I offered an alternative which maintains a content/functional based markup
for HTML docuemnts yet allows fairly liberal specification of the
presentation of individual elements. My propsal, in short (see the
earlier thread "Percieved misdirection in MCC HTML extensions" for a more
in-depth discussion), was to define a set of global attributes for style
(FAMILY, FONT, SIZE, etc.) which would have appropriate defaults defined,
but which could be overriden by the author as needed. I.e. the default for
an EM element would be <EM FONT="I">...</EM> yet an author could specify
that for a particular chase, an emphasized segment of text should be both
bold and italic <EM FONT "B I">...</EM>, etc. Note that font attributes
are defined as a cumulative set. This is far better than sequences such
as <B><I>...</I></B> which impose an artificial structure which does
not exist in the data itself. A single new element e.g. <F> could be added to
the HTML DTD for specifying formatting of arbitrary segments of character
data; e.g. ...<F FAMILY=Times FONT="B">...</F>...

Using a scheme such as this, list items (to use an example driving some
of the MCC propsed changes), could be formatted however the author
prefers, or use the defaults as defined in the standard HTML DTD; yet
the functional definition of the list remains separate from that of
style and thus the information is more "purely" defined.

Regardless as to which extensions are added to HTML, I *strongly* advocate
that components of the standard addressing purely stylistic markup be
considered as "suggested" presentation guidelines by the author and that
users/readers be able to ignore such formatting at their discretion, for
whatever reason.

I look forward to hearing others comments on MCC's proposal as well
as my alternate proposal. Let's please keep HTML from becoming
a glorified LaTeX or troff.


===============================================================================
Patrick Stickler Information Group
Senior Computer Systems Engineer Martin Marietta Corporation
email: pat...@voyager.gate.net MP1270, 12506 Lake Underhill Rd.
phone: (407) 356-6094, fax: 356-8949 Orlando, Florida 32825 U.S.A.
-------------------------------------------------------------------------------
Don't put off for tomorrow what you can do today; because if you enjoy
it today, you can do it again tomorrow...
===============================================================================

Sami-Jaakko Tikka

unread,
Nov 17, 1994, 2:28:51 AM11/17/94
to
In article <3a64f1$i...@hopi.gate.net>, stic...@news.gate.net (Patrick
Stickler) wrote:

> In article <045303Z...@anon.penet.fi>, <an10...@anon.penet.fi> wrote:
> >
> > EXTENSIONS TO HTML

> > <ISINDEX>


> I personally find the default message quite appropriate and informative,
> although I can certainly appreciate the usefulness of a custom message.

I have seen many pages where the search box isn't used for searching but
for specifying some other attributes. Take for example the Xerox map
server. It is a "seachable index" but words you type to the search box
are co-ordinates and other instructions (map details, etc..)

> > <IMG VSPACE=value HSPACE=value>


>
> These additions will be welcome. I would go further and add an attribute
> for specifying image compression, allowing images to be stored and
> transferred in a compressed format, then decompressed before presentation
> (or does the http deamon support this already?).

In my opinion httpd supports this already (at least the CERN server).
I'm just not sure if the browsers support this for inlined pictures.

There is an option in the CERN server config file like this:

---------------------------------------------------------------------
Binding Suffixes to MIME Content-Endocings

Suffixes are also used to determine the Content-Encoding of a file
(.Z suffix for x-compressed, for example). Syntax is:

AddEncoding .suffix encoding

EXAMPLE

AddEncoding .Z x-compress
---------------------------------------------------------------------

This should be enough if the browser is intelligent enough to cope with
the Content-Encoding header in the reply.

> As with many of the MCC proposed extensions, this opens up a pandora's

I think the "official" acronym for Mosaic Communication Corporation is
MCOM. I remember having seen MCC being used for another company that
also produces WWW software.

> Why was this posted anonymously? Isn't this an official posting on
> behalf of MCC?

I wouldn't know. This same document is available in public in the MCOM
WWW server.
--
<A HREF="http://www.cs.hut.fi/~sti/">Sami Tikka</A>
"Peace and Long Life."
"Live Long and Prosper."

Jann VanOver

unread,
Nov 17, 1994, 5:37:45 PM11/17/94
to
In article <3a64f1$i...@hopi.gate.net>,

Patrick Stickler <stic...@news.gate.net> wrote:
>In article <045303Z...@anon.penet.fi>, <an10...@anon.penet.fi> wrote:
>>
>> EXTENSIONS TO HTML
>>
>> These are proposed extensions to the soon to be released HTML 2.0
>> specification. Mosaic Communications will be working with the
>> appropriate standards bodys, including W3O, and the authors of other
>> WWW browsers in an attempt to have these extensions available in all
>> browsers in the near future. All the Netscape extensions to HTML
>> take the form of additional tags and attributes added to the HTML
>> specification and are specifically designed not to break existing WWW
>> browsers.
>>
>> <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:
>
>Don't you mean that you've added a PROMPT *ATTRIBUTE*?? Let's keep our
>SGML terms straight (remember HTML is SGML...)
>
Well, if you REALLY want the terms correct, the word "tag" wouldn't be used at
all. SGML has GIs (Generic Identifiers). These may represent ELEMENTs or
ATTRIBUTEs or other things.

In this case, they are talking about adding an ATTRIBUTE.

And I agree, let's try to use the correct SGML terminology whenever
possible.
--
---------------------------------------------------------------------
Van...@atc.boeing.com
"Why don't y'all go home?" Bette Davis in The Little Foxes
---------------------------------------------------------------------

William McBrine

unread,
Nov 23, 1994, 3:28:49 AM11/23/94
to
Patrick Stickler (stic...@news.gate.net) wrote:

: These additions will be welcome. I would go further and add an attribute


: for specifying image compression, allowing images to be stored and
: transferred in a compressed format, then decompressed before presentation
: (or does the http deamon support this already?).

Standard inline images are GIFs, which are already the maximum lossless
compression. MCOM is also supporting JPEGs as inline images, and I'd
encourage that.

--
William McBrine
wmcb...@clark.net

Snowhare

unread,
Nov 23, 1994, 5:34:36 PM11/23/94
to
William McBrine wrote in article <3auug2$9...@clarknet.clark.net>:
> Patrick Stickler (stic...@news.gate.net) wrote:

> : These additions will be welcome. I would go further and add an attribute
> : for specifying image compression, allowing images to be stored and
> : transferred in a compressed format, then decompressed before presentation
> : (or does the http deamon support this already?).

> Standard inline images are GIFs, which are already the maximum lossless
> compression.

ObDry comment: If you consider 8 bit color to be "lossless" when starting
from 24 bit color originals. >;-)

> MCOM is also supporting JPEGs as inline images, and I'd
> encourage that.

I definitely agree with that. I will begin using inlined JPEGs in a few
months as I am certain that successful new browsers will follow suit in
supporting them - and JPEGs of photographic originals both look better
and are smaller in size than GIFs.

--
Benjamin Franz

Reply all
Reply to author
Forward
0 new messages