Re: Properties applicable to root?

David wrote:
" >From: Todd Fahrner <todd@verso.com>
" >3. For HTML explicitly, the BODY (and HEAD) elements should accept all
" >normal box properties, just like any other blocks. The HTML element itself
" >should take most CSS properties excepting those outlined in (2).
"
" I'm not sure what you mean by the HEAD element accepting box
" properties.  The question of rendering the HEAD element is left
" somewhat open in the HTML 4.0 specs, but I tend to think it is not
" advisable.

I don't think CSS implementors shouldn't concern themselves with what they
think is or isn't a reasonable application of the language. Each
implementor answers differently, and the result across implementations is
an interoperable subset smaller than any single implementor envisioned, and
almost certainly smaller than what creative authors might like.

" The only renderable (not SCRIPT or STYLE elements) content
" of the HEAD element is usually the TITLE element.  (I can't think of
" anything else.)  I guess if one wants to render the TITLE as part of
" the page this could be useful.

Yes, for example. It's often simply redundant with H1. A future display
type might present markup naked, too. This would expose such trivialities
as the meta tags, the doctype, and even the stylesheet (actually, the
stylesheet should display with existing display types: style { display:
block; whitespace: pre } )
. Or alternate stylesheets available. Does the typical user want this?
Perhaps not now, but only geeks wanted desktop computers in 1975. Might the
typical author? Absolutely. View Source on steroids, and standardized
across browsers.

This is an aside, really. The main thing is putting BODY on a firm
conceptual foundation. You'd have to go out of your way to do this and
*not* treat HEAD the same way. More system, fewer special cases.

" Therefore the default user-agent (UA)
" value for HEAD would be display:none, and the default UA value for
" TITLE would be display: block.  (If such a change were made to the
" specs, this should be added to the sample UA style sheet.)

Agreed. Maybe. <g>

" A problem with such an implementation is that it could encourage people
" to put BODY content within HEAD.

I don't think so. Anyway I don't believe the thoroughness of a CSS
implementation should be penalized by the probability that it might
encourage bad markup. Incomplete implementations are far more pernicious in
this regard, witness the ascendancy of DIV and SPAN at the expense of more
descriptive elements, which are not used because their renderings are not
so malleable. Can't get rid of the margins on ADDRESS? Use DIV instead. etc.

" There is one other side issue, and that is the meaning of CSS
" properties on the FRAME and FRAMESET elements.  I don't want it to
" sidetrack Todd's proposal, but it is something to think about.

My assumption is that anything in 4.0 Transitional and not in 4.0 Strict is
for a style-based solution to supercede, or simply to be left behind.

" If my
" memory is correct, Netscape treats attributes on FRAMESET as if they
" were on BODY.  There ought to be a way to duplicate the HTML attribute
" FRAMEBORDER (on FRAME) and the Netscapism (the only non-HTML attribute
" that I use) BORDERCOLOR (on FRAMESET) using CSS, and possibly do some
" other things with frames.  I seem to be in a minority among supporters
" of standards in believing that frames are a good thing, because they
" preserve bandwidth and simplify development.

I can't agree that they simplify development. As for bandwidth, I still
hope more specification work can be done with OBJECT or entities to nullify
this consideration. Getting CSS well-enough implemented, broadly enough to
retire GIF-and-table will take years enough, by which time I expect
frames-as-bandwidth-savers will seem quaint.
--
Todd Fahrner                    The printed page transcends space and time.
mailto:fahrner@pobox.com        The printed page, the infinitude of books,
http://www.verso.com/agitprop/  must be transcended. THE ELECTRO-LIBRARY.
                                                   - El Lissitzky, 1923

Received on Wednesday, 30 September 1998 19:00:15 UTC