Re: Proposed extensions to HTML

Murray Maloney writes:
| Hmmm.  Actually I seem to the forest ranger, having to
| walk from camp to camp and trying my hardest not to
| settle in for the night at any one of them.  

And doing a good job here.

| > >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.
| Ya, I understand and actually appreciate that point of view.  
| I just don't agree entirely.  Certainly I agree that the reader
| should always win.  I also agree that, ultimately, style sheets
| are a much happier solution to the problem.  But, there are
| plenty of information providers who want to specify some author
| or publisher preference information in with the data.  They are 
| going to do it whether we like it or not, so we had better make
| it easy enough to put some style info into the document and 
| make it just as easy for a reader to ignore it.

Good points.  The combination of an easy to use but powerful tag
set (the next major revision of HTML?) and a flexible and powerful 
style sheet mechanism (DSSSL Light?) should give the user and 
reader the means to manage some "preference information" through
tagging (as they do now with HTML, but they'll get better results).
Some things they won't be able to do easily, and yet others they
won't be able to do without being devious or employing another DTD.

Thanks to Murray's rangering, the principle suggests itself that
formatting information to be considered seriously for inclusion in
HTML should be what's needed to get common desired formatting effects
that can't be provided by DTD+style sheet.  That's a step forward
from thinking that all style info should go in the style sheet.
(Of course, one could ask that a style sheet be able to modify
a single element or range of elements by pointed to them by their IDs, 
and get as flexible effects as you like out of plain old HTML, but
let's not for present purposes.)

| After all, the information provider is at least as important
| on the Web as the reader.  If they can't achieve what they 
| need to achieve -- even if we think that they just don't understand
| -- then they will just litter the Web with PostScript or RTF.
| Other browsers are coming down the pike.  Let them try to answer
| the needs of publishers and readers of info-domain-specific markup.
| There is just no way that HTML can ever be everything to everyone.
| So why not think of it as a Volks-language?  It's not what you
| would drive under many circumstances, but its easy enough to use
| and gets you where you are going.

Good design goal.  So the formatting information to be considered 
seriously for inclusion in HTML should be what's needed to get 
*common* desired formatting effects (those most desired by the folk).  
Can't do everything, want what can be done to be doable simply.
No power steering or cruise control, but we can have a good sound
system.

| > Regarding <UL TYPE=value> we wrote:

[omitted]  

The Netscape mechanisms could stand comparison with other designs, and
may allow some unintended effects when combined.  Please don't anyone
argue that any effect possible is desirable; I'm picking up my folkish
thread from Murray, and following it further to assert that to keep
things easy to use it is desirable to avoid creating new typographic
effects (e.g., mixed numbers and bullets in a list, which would seem
to be possible with these extensions) that don't have established 
conventions.  One wants economy of means as part of and to enable
ease of use.

[re WIDTH:]
| My experience with SGML has led me to conclude that
| "attributes are cheap, anybody will give you one".
| So, I have little problem with adding attributes 
| that only a small set of applications will actually use.
| No harm.  No foul.

Attributes *are* cheap, but they're also visible to writers. In line with 
my previous assertion, I'd be inclined to argue that too many attributes 
could decrease ease of use, so each one should be evaluated against other 
info that might also be conveyed by attributes.  Is there really a
common unit of measure that can be used here, and is it not obtainable
from the object itself, or is this just the kind of dubious info that
you'd expect cheap attributes to pick up?

| > >> >>         <IMG BORDER=value>

Now this is a richer attribute than WIDTH; it can be expanded to include
BaroqueFrame, Shadowbox, Bunting, and BlackCrepe, for example (seriously).
Unless BORDER is to be defined as NUMBER, which would be kinda crude.  

| > 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.
| I'm not so sure about the conclusion that you have reached.
| Is it not the case that most browser developers are adding
| features to the language even as we exchange mail?  Certainly
| Dave Ragget is with Arena, and I suspect that Spyglass has.
| I know that we, at SCO and IXI, have experimented with our
| browsers and will have ideas to offer as a result.

I have to agree with Murray.  Procedure aside, Netscape tried to get some 
effects they desired and that appear to be desired by the folk.  At
least some of the folks.  At least at this stage of the discussion.

I think better means can be found to achieve those effects within
the bounds of the principles I suggested above:  formatting elements
or attributes in a suitably revised DTD should be only what is needed 
to get what a style sheet can't give you, and what is now conventional
usage (e.g., that a numbered list has no items that have dingbats instead
of numbers) while keeping the whole package easy to use by plain folks
and maintaining an economical design.

The present HTML manages to do much of that without a style sheet; that
is quite interesting but no predictor of success with a more complex
HTML that still lacks a style sheet.

| I think it is a shame that Marc and his team took so much heat.
| I also think that it was regretable that they did not work
| with the HTML Working Group before they announced these extensions.
| And while I do not have a copy of Netscape running here, I have
| heard a lot of positive remarks about what they have done.

Their pages sure look different---which was the point, and is 
something a lot of folks want.  But if you allow for a style sheet,
much of that effect can be achieved without inserting the formatting
information in the coding, and thus requiring mods to the DTD.  
There's some other stuff left over, and that's what we need to 
identify for use in a revised HTML DTD.

One specific comment for those of you who have read thus far.
The following Netscapade is not good reasoning:

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

The anonymous author seems not to have understand a detail of 
typesetting and, as a result, he implemented the effect incorrectly in 
Mosaic.  There's nothing wrong with the original set of attributes; the fix 
should be to correct the implementation, not duplicate the set of 
correctly-named-but-wrongly-implemented attributes as alternatively-
named-and-correctly-implemented attributes.  This much breakage
of rather small and easily located details of existing documents
must be considered acceptable, or no blunder will be too grave to
back out of.


-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    103A Morris St.
			       Sebastopol, Calif., 95472
A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html

Received on Saturday, 19 November 1994 02:37:28 UTC