Re: W3C Core Styles

Thus spake Gayle Kidder:
 
> Todd,
> I'm referring to this in the composition nodule:
>
> A, ABBR, ADDRESS, BDO, BLOCKQUOTE, BODY, BUTTON, CITE, CODE, DD, DEL, DFN,
> DIV, DL, DT, EM, FIELDSET, FORM, H1, H2, H3, H4, H5, H6, IFRAME, IMG,
>INS, KBD,
> LABEL, LI, OBJECT, OL, P, Q, SAMP, SMALL, SPAN, STRONG, SUB, SUP, UL, VAR,
> APPLET, B, BIG, CENTER, DIR, FONT, HR, I, MENU, PRE, S, STRIKE, TT,  U	{
> 	height: auto;
> 	margin-top: 0;
> 	margin-bottom: 0;
> 	padding-top: 0;
> 	padding-bottom: 0;
> 	border-top: 0;
> 	border-bottom: 0;
> 	vertical-align: baseline;
> 	}
>
> At first glance it seemed to me that the margin and padding properties
> might be what's being interpreted wrongly, and I can't see why these
> need to be declared on these elements at all in a basic core style
> sheet. (I confess I was wrong to refer to them as positioning
> properties--that's just intuitive.) I think it's fair to assume these
> are browser default values.

Lots of things going on here. First, the Core styles are intended to leave
nothing to the browser default or Base
(http://www.verso.com/corestyle/base.html). They wouldn't be complete if
they did. At one point I began stripping the Core set of all but deltas
from the Base, intending simply to import the latter. However, because the
Base uses the shorthand syntax for brevity, while the Core uses longhand
for modularity and editability, this became more and more clearly a bad
idea as I proceeded. So I reversed myself. Accordingly, there remain a
number of deliberate redundancies with the Base in the Core.

As for declaring block formatting properties on inline elements, I found
this confusing initially, as well, as I was preparing the Base sheet:

Consider the element ADDRESS. In the DTD, this is an inline element, but it
typically renders as a block, which realization caused me some stress.
Should I define all of the block-level property values for it, or what? And
if I did it for ADDRESS, why not also for other inline elements? What do
block and inline level elements really mean, anyway, when they can
apparently go back and forth between states?

After discussing with Hakon, I think I have this right: HTML's content
model, defined in a DTD, does not necessarily correspond with its rendering
model (which before CSS had no language, even, much less a communicable
model). The document tree and the rendering tree are distinct, though often
morphologically similar. It does not aid understanding that the same
descriptive terms - block and inline - are shared across trees. There is no
redundancy in saying that block level elements may render as blocks, nor
any contradiction in saying that they may render inline.

Briefly:
The significance of declaring "block" formatting properties on the inline
elements above is to disambiguate what should happen if their display type
is changed to "block" in this or any cascaded sheet. As long as their
display type is inline, these properties will simply not apply. It is
necessary to cover these bases only for the non-inherited properties.

Meanderings:
You could do some really cool and interesting stuff if implementations
supported the CSS1 display type properties. Some examples:

* Look at the web and you'll frequently see navigational items arranged in
a single line, delimited by virgules or nasty little GIFs or whatever. The
semantically appropriate markup for such would be the now deprecated MENU
or DIR elements, I think. Nobody used these, though, because the LI
elements each sat on their own line, as blocks. Through CSS you could
simply set the display type of LI to inline, and ... well what about those
markers? There'd be work to do, but it's an interesting direction that I'm
sad to see appears not to have been taken by implementors.

* Look at the paragraphs here: http://www.tiro.com/ . This is an ancient
mode of delimiting them - not with line breaks, but with inline markers.
Scribes using one color of ink would write out the text, leaving gaps
between the paragraphs. They'd then pass the sheet on to another scribe
using red ink - the "rubricator", who would scan for gaps and make marks in
them. (This was a very economical way to do layout when paper was dear,
just as pixels are now. The dense, uniform field of text on a sheet
resembled woven cloth, and was accordingly called a "textus", whence text
and textile.) Anyway, the rubricator could work faster and more accurately
if he could just scan the left edge of the textus for gaps, so the scribes
started putting the new paragraphs on new lines, leaving a little gap as
before. Then somebody realized that these *indents* made the rubricator
and his expensive red ink totally superfluous - and there you have it. Much
later, when fashion and cheaper paper meant that something had to give,
somebody came up with the extravagantly barbarous idea of hacking up the
textus with big gaps between paragraphs.

Meanwhile, on the Web, where we've regressed all the way back to the
cumbersome scroll, we still cling to the convention of starting paragraphs
on new lines, even with gaps. Sometimes I'd much prefer P { display: inline
}, especially now that red is cheap. For WebTV or a handheld, this could
make a huge difference.

* Inset headers:  Hn { display: inline }

___

If you, like me, have been confused by Microsoft's talk of "HTML/CSS flow
objects" as the output of their XSL interpreter, realize that these would
be nonsensical if they'd just support the CSS1 display types. As it is now,
their main need to invoke HTML as a display format is to patch the gaps in
their CSS implementation. Otherwise they could style a lot of XML directly
with CSS, with XSL serving as just the transformation language.

__________________
Todd Fahrner
mailto:fahrner@pobox.com

Received on Monday, 16 February 1998 15:23:55 UTC