<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:
® -> Registered Trademark -> ®
© -> Copyright -> ©
_________________________________________________________________
[2]in...@mcom.com
Copyright © 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.
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:
> ® -> Registered Trademark -> ®
> © -> Copyright -> ©
>
> _________________________________________________________________
>
> [2]in...@mcom.com
> Copyright © 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...
===============================================================================
> 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."
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
---------------------------------------------------------------------
: 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
> : 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