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