re: W3C Core Style project progress

Thus spake Rasmus Kaj:

> I got approx the same thing (as Daniel Hale) using Netscape Navigator
> 4.04 on FreeBSD 2.2.2-RELEASE, but that seems to be fixed, it looks
> nice now.

I discovered and fixed an error in my SSI logic ("if" instead of "elif") so
am pleased to hear that this seems to have fixed things.

> Before I knew that you preprocessed your css files to match the
> browser I tried to get the stylesheet using fetch (a nice command line
> tool to fecth things over ftp or http) and got a number of SSI error
> messages.

I'll make links to the complete, un-negotiated families soon. Meanwhile,
you can grab all of the modules directly from the URLs given in the
"Development URLs" section.

You can also "roll your own" families by successively linking to the
desired modules in HTML, modulo:

<LINK REL=STYLESHEET TYPE="text/css"
HREF="http://www.verso.com/agitprop/corestyle/modulor/style/1_aff.css">
<LINK REL=STYLESHEET TYPE="text/css"
HREF="http://www.verso.com/agitprop/corestyle/modulor/style/2_body.css">
<LINK REL=STYLESHEET TYPE="text/css"
HREF="http://www.verso.com/agitprop/corestyle/modulor/style/1_head.css">
<LINK REL=STYLESHEET TYPE="text/css"
HREF="http://www.verso.com/agitprop/corestyle/modulor/style/4_comp.css">
<LINK REL=STYLESHEET TYPE="text/css"
HREF="http://www.verso.com/agitprop/corestyle/modulor/style/2_marg.css">

...but of course this will blow up in first-generation implementations.
That's why it will be best to conditionalize the modules. The original idea
of modularization wasn't to facilitate bug-negotiation, but it turns our to
be a nice basis for this as well. Generally speaking, if the UA can't
support all properties in a module, it shouldn't get any - not even those
it supports. This is easiest to understand in the affordances module -
e.g., don't specify a link color if you can't also specify a background
color - but it also holds for composition: don't bother with paragraph
indents if you can't also remove the inter-paragraph space. And so on.

Some directions for further development:

Break away from the "orthogonal" family/module model -

	     1  2  3  4
	a   x  x  x  x
	b   x  x  x  x
	c   x  x  x  x
	d   x  x  x  x
	e   x  x  x  x

and grow a less-contrived, more heterogeneous grid, e.g:

	     1  2  3  4  5  6  7  8  9
	a   x  x  x  x  x  x  x
	b   x  x
	c   x  x  x  x  x
	d   x  x  x
	e   x  x  x  x  x  x  x  x  x

This is in keeping with the fact that there are many more interesting
affordance schemes than, say, body margins - run in the most obvious
directions without the burden of coming up with complete new families. For
example, the "vertical" section of the composition module is exactly the
same for 3 of the 4 variants - it's silly to keep repeating very similar
modules just for the sake of keeping a square grid. The "mix and match"
functionality coming soon will make it relatively less desirable to have
fixed, complete families. People should of course develop their own sets of
property values, and especially successful ones can become part of public
collections, which will soon become form interfaces for synthesizing
arbitrary combinations of modules.

The families are long. Once "natural selection" produces favorite families,
these could be converted to shorthand notation, cascaded with the base
sheet, and stripped of redundancies for performance. These can then be
"canonized" with names and disseminated. I think it's important in the
beginning, however, to maintain a very open, verbose, editable style.

__________________
Todd Fahrner
mailto:fahrner@pobox.com
http://www.verso.com/agitprop/

Received on Tuesday, 3 March 1998 12:13:15 UTC