Re: Various HTML questions

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 3 May 1994 14:15:34 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <94050312062201@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Various HTML questions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

connolly@hal.com says:

> Where does it say this in the spec? I don't think any HTML spec says
>_exactly_ how HTML is to be rendered. 

Depends on how much emphasis you want to put on the exactly. True you will not 
find "render this heading in Palatino demiblog 14.7 point with 3 point leading 
and +4.7% kerning"

>Seems reasonable to me that an HR
>following an Hn might be rendered without intervening space if you
>so desire -- you just need a smart enough renderer, I guess.

Or rendered on a different page, or upside down, or in white on white 
background. So you cvan make no assumptions at all, is what you are saying. I 
think not.

> [I said:]
>> And I remember that the spec says an Hn element includes all the space needed 
>> to set it off from the body text.

>Could you give a specific citation? If it's really in there, I'll take it
>out in the next revision. "Typical rendering" suggests are part of the spec...
>rendering edicts are not.

Are you referring to the spec you are producing, or the official CERN one, btw?

As I said, I was going from memory. I suspect I had remembered 

  Heading elements in HTML
  http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html

"The rendering software is responsible for generating suitable vertical white  
 space between elements, so it is NOT normal or required to follow a heading 
 element with a paragraph mark."

and

"When writing documents, you should assume that whatever is done it is designed 
 to have the same sort of effect as the styles above."

though I may have made those quotes stronger in the remembering. But I feel thay 
the second quote there supports my position. Yes, renderings will differ, but 
you can assume that Hn elements _will_ be rendered as titles.

<? rant>
I also feel that the world has moved on a ways since CERN started the WWW 
project. All this insistence on "we have absolutely no way of knowing what a 
renderer will do with this" reminds me of the GKS specification. When it was 
first being written, graphics output devices were so massively variable in 
capabilities - like, some could only erase the whole screen, not parts of it - 
that saying nothing about presentation  was the only way. By the time the spec 
came to be published, things has settled down. Raster graphics were standard and 
widely available, as was colour.

We can now assume at least a bitmapped screen, can we not? And a PostScript 
printer or some approximation thereto? The major platforms - Unix with X, PCs 
with Windows and Macs with the Mac interface - and also the minor ones (OpenVMS 
with X, Atari ST and Amiga) all provide this. It has become standard. Bending 
over backwards to support a 40 column caps-only text terminal seems a lot of 
hassle for little gain. This is the 90s, not the 70s, or didn't we learn 
anything?
<? /rant>

Me:
>>Now that HTML is being re-DTD'ed based on current practice - an excellent 
>>idea - it would be timely to make this change too.

>What a contradiction!!! "make this change" when describing "current practice"!!

I think maybe you read this too fast ;-)

Make this change _to _the_DTD_ which is what you are doing:

>I'll take it out in the next revision. 

are you not? To document current practice? Such as, for example, the fact that 
at least two browsers support an HR inside an Hn

Paul "S." Wain:
>>Just from a presentation point of view I think that the 1st one looks a
>>little cleaner. (No it isnt just a Mosaic-ism *grin* Look at it in Lynx
>>too)... 

>>Does anyone else support this move? Can anyone see any problems?

>Not in the near term... my take on the DTD I'm spinning is: if it works
>today, fine.

That's what I thought you were saying.

> Current practice includes current browser implementations.

Excellent! Even clearer, even less ambiguous. So to comply with your stated aim 
of making a DTD that describes current practice, current browser 
implementations, if the current revision of your DTD does not support this then 
you would have to change it, would you not. I see no contradiction here (and I 
suspect you do not either, now)

--
Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit,        |  Internet: C.C.Lilley@mcc.ac.uk            |
| Manchester Computing Centre,   |     Janet: C.C.Lilley@uk.ac.mcc            |
| Oxford Road,                   |     Voice: +44 61 275 6045                 |
| Manchester, UK.  M13 9PL       |       Fax: +44 61 275 6040                 |
| X400:  /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/  |
|  <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A>   | 
+-----------------------------------------------------------------------------+