Re: Proposed extensions to HTML

Michael Johnson (
Fri, 18 Nov 94 14:30:30 EST

Subject: Re: Proposed extensions to HTML
Message-Id: <>
From: (Michael Johnson)
To: (Murray Maloney)
Cc: (HTML discussion list)
Date:    Fri, 18 Nov 94 14:30:30 EST

Murray, it seems to me that you are of the camp that thinks that HTML should
be a page description language, not a semantic markup language. I obviously
am of the other camp. There is a compromise between the two, and that is
style sheets.

You wrote:
>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.

>From my point of view (and there are others who share it) the author should
NOT be putting their formatting preferences in the document. Those belong in
a style sheet. If the user wants to override the author's preferences, then
the reader can have their own style sheet which can be merged with that of
the author. However, IMHO the reader's style sheet should always win.

Regarding <UL TYPE=value> we wrote:
>> 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.

Again, this should be a style sheet issue. One important aspect of presenting
information is that it should presented in a consistent way. A document that
had list dingbats that varied from one list to the next would be confusing to
the reader.

However, as it happens, there is a way for you to override the dingbats in
HTML3, which is to use <LI SRC=uri>.

Regarding START=value:
>> 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.

Upon re-reading it, I am sure they did too.

>> >>         <IMG WIDTH=value HEIGHT=value>
>> These might have value, but should be strictly treated as hints.
>What else could they be used as?

Absolute values which the browser has to scale the image to. Personally I would
rather not see that happen, simply because it adds that much more overhead to
using images in a document. Scaling images might be acceptable for something
which is going to be printed offline, but when it has to be accessed,
formatted, and displayed interactively, excess processing is to be avoided.

>> >>         <IMG BORDER=value>
>> 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.

See my previous comments about consistent presentation of information.

The remainder of the stuff we have varying levels of agreement on, but they
obviously need to be discussed.

This whole discussion is a clear example of why it is a bad thing for people
to do what MCOM (NCOM?) did, which is to unilaterally monkey with standards.

Michael Johnson
Relay Technology, Inc.