Re: style assignment

Thanks for the embarrassingly kind comments. But enough of that.

Some things I want to emphasize about the Core Styles:

These particular styles aren't offered as canonical models of taste, for
all the world to adopt. I hope that most are more appropriate than the
defaults for many documents, but that's not the point. Not everybody will
want to offer 14K stylesheets that "blot out the sun" in their
comprehensiveness.

The point, as I see it, is in the modular, cascadable architecture of the
stylesheets. The fact that these style families consist of almost randomly
chosen modules - and that they still work - means that the promise of
author-user stylesheet cascading might not be ready to retire yet. It also
means that CSS authors everywhere can write Core-compatible modules
themselves and be assured of tolerable results when cascaded with other
core-compatible materials, or when used "stand-alone" (i.e., cascaded with
the Mosaic browser default stylesheet).

Don't like a certain color or type scheme? Margins too wide/narrow? Omit,
substitute, or override. Don't let the floor models confuse you. This is
about getting what you want, while still giving your readers a chance to
override or ignore any module.

CSS1 specifies how cascading should work technically, as a set of policies.
These policies alone offer no help toward achieving attractive, usable
results; in fact, it's much too easy to write sheets that cascade poorly.
The Core Styles offer a model of how cascading can work at a typographic
and usability level, without constraining oneself to a very small subset of
CSS1's functionality. The styleserver's conditionalization services make
this possible even in these dark, early implementation days. This is not
the only possible model, but I hope that the community can help turn it
into the best of all possible.


So I'm calling for 3 kinds of participation:


1. During a shake-down stage, help me tune the "compatibility layer" (see
http://style.verso.com/stylist.html#styleserver) to avoid sending any
released UA style that it cannot handle. Usually this means withholding the
offending module entirely, but if the problems can be fixed with a few
lines of UA-specific crutch code, I'm game to include it. I'll try to
handle patches in a timely way, but bear with me.


2. Suggestions for improvement to the selector/property structure of the
"source layer" modules; i.e., everything but the descriptors. A quick
vocabulary review (I had it wrong myself recently):

  H1, H2, H3   { color:      red; }
      ^	           ^          ^
   selector    property   descriptor

The selector/property stuff is very verbose now in the Core Styles. This is
for editability - to encourage experimentation. (That means you!) Once the
workable options are exhausted to most peoples' satisfaction, the syntax
can be "compiled" to shorthand for performance's sake. (A programmatic
means of compiling longhand cascades to shorthand would be a godsend.)


3. New/better descriptor sets (color/affordance schemes are easy.
Composition modules are hard.)  I'm working on a few additions myself. You
can either use these as personal stylesheets (WinIE4 only at present), or
you can submit them for inclusion to the styleserver for public use. I'll
include your module if it's valid and makes no references to fixed,
device-dependent units (pixels, points, inches, cm, etc.).



Todd Fahrner
mailto:todd@lowbrow.com
http://www.verso.com/agitprop/

The printed page transcends space and time. The printed page, the
infinitude of books, must be transcended. THE ELECTRO-LIBRARY.
	- El Lissitzky, 1923

Received on Wednesday, 13 May 1998 17:20:43 UTC