StyleServer Development Interface

Check out the new "extended" and "compact" interfaces!

Note: this service will undergo some major changes in the near future. Every effort will be made to preserve existing functionality, but there are no guarantees. Analysis of StyleServer logs suggests that many people are using the service in ways that may be affected. If you use (or plan to use) StyleServer for live Web materials, please let me know so I can contact you with details of upcoming changes. This will help avoid disruptions.

This is work in progress, last modified 5 December 1998. Comments to Todd Fahrner of Verso. General discussion is welcome in either the stylesheets newsgroup, or the www-style mailing list. See also the original project description page for background information, some of it still current.

The W3C Core Styles sampler interface lets users select stylesheets by name. Each of these named selections is composed of six stylesheet modules, each available in several variants. The form interfaces here let authors select their own stylesheet modules to compose complete or partial stylesheets. There are many thousands of permutations possible, ready for application to any valid, structural HTML document.

1. Compose a stylesheet

2. Stylesheet options

3. Select a test document


Usage Notes

To inspect or apply an individual module, select it, leave all other selections at "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-h=4&comp-v=1&compatibility=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&compatibility=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&compatibility=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>

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."

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:

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 (parser.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 source layer materials 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. Query parsing, UA conditionalization, and includes are currently implemented using only the Apache Web server's eXtended Server Side Include (XSSI) functionality.

Source for functional subsets of the Verso StyleServer 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.0/" -->
/* 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 configure 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?

Legal stuff

StyleServer is a trademark of Studio Verso, Inc. Contents copyright © 1998 Studio Verso. All rights reserved. Permission to link Web documents to the StyleServer is granted, though this service may change or become unavailable at any time. Permission to copy and re-use stylesheet materials is also granted; however, such use may lead to unexpected results due to the UA-specific nature of the materials served.

Portions (The W3C Core Styles) Copyright © 1998 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. See http://www.w3.org/Consortium/Legal/ipr-notice.html

ALL MATERIALS ON THIS SITE ARE PROVIDED "AS IS." STUDIO VERSO MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. AS TO DOCUMENTS, STYLESHEETS AND GRAPHICS PUBLISHED ON THIS SITE, STUDIO VERSO MAKES NO REPRESENTATION OR WARRANTY THAT THE CONTENTS OF SUCH ARE FREE FROM ERROR OR SUITABLE FOR ANY PURPOSE; NOR THAT IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

IN NO EVENT WILL STUDIO VERSO BE LIABLE TO ANY PARTY FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES FOR ANY USE OF THIS SITE, OR ON ANY OTHER HYPERLINKED WEB SITE, INCLUDING, WITHOUT LIMITATION, ANY LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER DATA ON YOUR INFORMATION HANDLING SYSTEM OR OTHERWISE, EVEN IF STUDIO VERSO IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.