StyleServer Development Interface

Usage Notes

To inspect or apply an individual module, select it, set all other selections to "none", and then submit the form.

The form above composes a query string, which is parsed by the styleserver to return the expected result. On an experimental basis, Web authors may link their documents to the styleserver with a query string, e.g:

...</title>
<link rel="stylesheet" type="text/css" 
href="http://style.verso.com/styleserver/parser.css?body=1,head=1,marg=1,affo=1,comp=4,safety">
</head>

Edit the query string to change the stylesheet. Study the strings that appear in the location/address field following form submissions to learn the vocabulary. Note that the query string may reference any number of modules, including only one. CSS authors may wish to import one or more modules, then override selectively or expand the stylesheet for document-specific applications. This technique may be used to great effect for pages with very specific formatting requirements. Some examples:

...</title>
<link rel="stylesheet" type="text/css" 
href="http://style.verso.com/styleserver/parser.css?body=1,safety">  
<!-- requests only a body type module, to be withheld from nonconformant UAs --> 
</head>

...
...</title>
<style type="text/css"><!--
@import url("http://style.verso.com/styleserver/parser.css?affo=4,head=6,safety"); 
/* imports an affordance and header module, to be withheld from nonconformant UAs */
H1 { color: red; background: black; } 
/* overrides a rule imported with the head module */
--></style>
</head>

The "comp" item in some of these query string examples refers to 1-4 composite selections of vertical and horizontal composition modules. To select manually, substitute comp-v=n and/or comp-h=n.

Users of Microsoft Internet Explorer 4.0 can surf to arbitrary documents on the Web and apply Core modules immediately by entering the following line into the location field: javascript:void(document.createStyleSheet("http://style.verso.com/styleserver/parser.css?body=1,head=1,marg=1,affo=1,comp=4,safety")). Again, edit the query string to change the stylesheet as desired.

Authors may find that application of these stylesheets in better CSS implementations offers a far more stringent test of quality portable markup than validation or linting alone. The project thus has value as a "visual lint."

About fonts: lacking a cross-browser embedded font technology harmonious with CSS, this project makes heavy use of the free TrueType fonts released by Microsoft for Macintosh and Windows. For the most pleasing results, get all of these fonts. Anti-aliasing ("smoothing") software is also recommended, such as the free Windows 95 font smoother, or Greg Landweber's shareware SmoothType for Macintosh.

Browser sniffing and style conditionalization

The "safety" keyword in the query string examples above turns on the styleserver's browser-conditionalization features. With this feature engaged, certain modules are withheld from most CSS browsers to avoid serious implementation problems. Typically:

• Microsoft Internet Explorer 3.0.x and Netscape Navigator 4.0.x for all platforms do not receive the composition modules, and receive only safe subsets of the Header and Body type modules. These browsers do receive the "body box" and "affordance" modules in nearly all cases.
• Microsoft Internet Explorer 4.0 for Macintosh receives a more complicated subset of the requested modules. The 4.01 release receives all modules. Encourage your friends to upgrade.
• Internet Explorer 4.0 for Windows receives all modules, though sometimes with minor modification, and it does not correctly support all of the rules in the modules as specified.
• All unknown or pre-release UAs are served all style unmodified as an encouragement to achieve an interoperable level of conformance.

In time, effective workarounds may be developed to serve more style to more UAs. The ultimate goal, however, is to phase out the need for any negotiation by encouraging a uniformly high level of conformance to the CSS1 and later specifications. Browser sniffing and style conditionalization impose performance penalities and cannot take advantage of the Web's caching mechanisms.

To investigate the quality of CSS support in your browser, visit the W3C CSS1 Test Suite for a systematic approach. Less isolated tests can be devised by disabling the "safety" feature of this styleserver and letting your browser deal with the output. Save all work before attempting this.

How the styleserver works

This styleserver consists of three tiers or layers of files: an assembly layer, a compatibility layer, and a source layer.

Assembly layer

This layer, at the root of the styleserver, consists of a query string parser as the index (index.css), and any number of "frozen query strings" or named style families (e.g., Midnight.css). Both classes of file contain XSSI logic to include files in either the compatibility or source layers. Named style families generally include files in the compatibility layer, while the query parser includes files in the source layer unless the "safety" keyword is present in the query string.

Compatibility layer

This layer consists of .css files containing XSSI logic either to withhold, to include, or to provide substitute CSS for the modules requested in the assembly layer, based on the name, version, and platform of the requesting UA. There is one compatibility file for every file in the source layer, with each file-pair representing a module. This allows for compatibility filtering on a module-by-module basis. This is where the browser bug workarounds live. All unknown/untested browsers get the corresponding source layer file included without modification.

Source layer

This layer consists of nothing but raw CSS module files. The CSS generally goes beyond what is supported completely in any browser at this time, and is in this sense "pure". CSS authors wishing to bypass all server parsing and enjoy the performance benefits of caching may import or link directly to files in the source layer, albeit without any protection against the severe implementation problems of first-generation CSS browsers. Example CSS import statements to the source layer are:

@import url("http://style.verso.com/styleserver/source/s_affo_1.css");
@import url("http://style.verso.com/styleserver/source/s_comp-h_4.css");

Note that the functions of the compatibility layer could conceivably be implemented in client-side scripting languages in combination with the above approach. This could eliminate the caching problems, though it places a relatively high burden on CSS authors and is not entirely reliable.

Extensions and source

CSS authors might eventually develop and submit their own module variants for inclusion in the core set, or as part of non-public styleservers. A valid module variant is defined as one which differs from existing core modules only in its descriptor values, not in its rule structure. The rule structure will not be finalized, however, before more extensive public testing and feedback establishes its soundness.

Authors wishing to study the project in detail or to experiment with extensions can download the CSS source in MS Excel Worksheet format (95K). The first two columns of any sheet - selector and property - are not to be edited. Only the descriptor columns may be edited. Other formats available soon. Query parsing, UA conditionalization, and includes are currently implemented using only the Apache Web server's eXtended Server Side Include (XSSI) functionality.

Source for complete "StyleServers" will soon become available. In the meantime, here's a sample "compatibility layer" CSS file containing XSSI directives to include UA-specific stylesheet information:

<!--#if expr="$HTTP_USER_AGENT = /Win/ && $HTTP_USER_AGENT = /MSIE/ && $HTTP_USER_AGENT = /4./" -->
/* WinIE4 */
<!--#include virtual="localpath/foo.css" -->
and/or any UA-specific overrides here....

<!--#elif expr="$HTTP_USER_AGENT = /Win/ && $HTTP_USER_AGENT = /MSIE/" -->
/* WinIE3 */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /Win/ && $HTTP_USER_AGENT != /ompatible/ && ( $HTTP_USER_AGENT = /4./ )" -->
/* WinNS4 */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /ac/ && $HTTP_USER_AGENT = /MSIE / && $HTTP_USER_AGENT = /4.01/" -->
/* MacIE4.01 */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /ac/ && $HTTP_USER_AGENT = /MSIE / && $HTTP_USER_AGENT = /4./" -->
/* MacIE4.0 */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /ac/ && $HTTP_USER_AGENT = /MSIE/" -->
/* MacIE3.x */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /ac/ && $HTTP_USER_AGENT != /ompatible/ && ( $HTTP_USER_AGENT = /4./ )" -->
/* MacNS4.x */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /ac/ && $HTTP_USER_AGENT != /ompatible/ && ( $HTTP_USER_AGENT = /4./ )" -->
/* X11IE4 */
<!--#include virtual="localpath/foo.css" -->

<!--#elif expr="$HTTP_USER_AGENT = /X11/ && $HTTP_USER_AGENT != /ompatible/ && ( $HTTP_USER_AGENT = /4./ )" -->
/* X11NS4 */
<!--#include virtual="localpath/foo.css" -->

<!--#else -->
<!--#include virtual="localpath/foo.css" -->
<!--#endif -->

To get Apache to parse CSS files for XSSI directives, add a file called ".htaccess" to the directory containing the CSS. The file's contents should read:

AddHandler server-parsed .css

Anybody want to contribute an ASP equivalent? PHP? Others?