[Bodington-developers] CSS Processing

[Jon M. <jo...@te...>]

Comments on this welcome....

O.K. I've now got straight in my mind how to do the CSS stuff that I'm 
planning (for my own web site initally). It depends on XSLT 2.0 because 
the transforms need to do some maths and 2.0 allows you to define 
functions in the stylesheet thus avoiding the need for call outs to a 
potentially less portable code library. (Most important if a binary, 
i.e. non-Java transformer is preferred.) I'm testing with Saxon.

The process involves three different roles; designer, author, viewer.

The designer is the person who designs the web site and is knowledgable 
about CSS. The designer creates the basic structure of documents and 
tools but doesn't deal with aesthetics such as specific colour schemes.

The author is the creator and owner of documents created with tools 
provided by the designer who is allowed to change the appearance of 
their own or their group's documents and tools as seen by others within 
parameters defined by the designer.

The viewer can navigate through the documents of various authors and has 
options to alter the appearance for the purposes of accessibility and 
preference. The alterations will always attempt to preserve the 
essential differences between one author's documents and another's.

The web server will map *.css onto a url to a CGI script or servlet 
passing in the original path to the referenced css file. The script will 
find the original css file and a number of other files in a special 
sub-directory. In the special sub directory there may be a processed css 
file which is up to date. If that file is up-to-date it will be sent in 
place of the original css file. If it isn't up to date processing may be 
required to recreate the processed css file.


Step 0)
The designer creates one or more files that resemble standard CSS files. 
(Called designer CSS files.)
This is an optional step for designers who can't cope with XML files and 
will require some non-standard extensions to the CSS format to implement 
extra functionality.  (explained in the next step.)

Step 1)
An XML style file will represent what is essentially the designer CSS 
file but in a format that can be processed by XSLT. In addition to the 
normal content there will be a section that declares variables and the 
value part of any CSS declaration may be either a constant or reference 
a variable.  (Variable declarations will have default values.) The 
decision about whether to put a constant or a variable depends on the 
designer's wish to give the document author parameters which they can 
use to change the appearance of their documents. It is likely that 
colours will be added as variables, some font properties will be added 
as variables but dimensions are more likely to be constants. (Ideally it 
will also be possible to put arithmetic expressions in but that will 
have to wait for version 2.) This file is called the designer xml style 
file and it will only be generated if it is older than the designer css 
file.

Step 2)
The author xml style file is generated by XSLT. (Only if it doesn't yet 
exist or is older than the designer xml style file.) The XSLT file that 
does the work is passed an author data file as a parameter. The author 
data file is a simple XML file that names variables and defines values. 
It may only contain a foreground and background color for example. The 
transform substitutes variable values into the style declarations of the 
author xml style file. If the author data file lacks a definition for a 
particular variable then the default value is used. Outside the scope of 
the servlet/cgi script is the creation and editing of the author data 
file - however the designer xml style file lists all the variables and 
will have descriptions of them (in multiple languages) so another 
application can present a form to users where they can choose colors 
etc.  The number of these files generated = (num.  css files) * (num. 
different authoring areas)

Step 3)
The user xml style file is genereated by XSLT. (Only if it doesn't yet 
exist or is older than the author xml style file.) The XSLT file that 
does the work is passed a user preference file as a parameter. The user 
preference file is XML that describes things like colour preferences, 
preferences for line spacing etc. etc.  The transform looks at whole 
blocks of style, picking out specific declarations of interest and uses 
appropriate maths to bring the style sheet within constraints defined by 
the user's preferences while attempting to retain whatever individuality 
of the design it can.  The number of these files potentially generated = 
(num.  css files) * (num. different authoring areas) * (num. users with 
preferences) Users with default preferences are treated as a single user.

Step 4)
The user css style file is generated by XSLT. (Only if it doesn't exist 
or is older than the user xml style file.) I

My estimate is that a native code XSLT processor invoked from CGI can do 
all of the above in less than 250ms. A Java XSLT processor invoked from 
a Servlet will probably be faster since it's permanently loaded in 
memory and ready to run.

RGB to CSV
=========

Nearly all user colour preference work will operate in 
Hue-Saturation-Value space, not Red-Green-Blue space. However, the 
standard Java HSV colour space (which Bodington currently uses) is not 
very good so I've devised a better method. (Probably reinvented but it 
only took a couple of days work.) The standard HSV space is cylindrical 
where H is the perpendicular distance from the axis to the colour point, 
H is the angle of that line from the red plane and V is the distance up 
the cylinder.  All of the bottom face is black. (which means that if V=0 
then the colour is black regardless of the values of H or S) However, 
the top face has white only at the center and has bright rainbow colours 
around the edge.  This means that if V is non-zero, V and H are kept 
constant and S is varied then not only does the perceived saturation 
change but the brightness does too. The method used to map the cube rgb 
space onto the cylinder is also dodgy since for certain values of H 
changing S distorts the perceived hue.

My method also maps to a cylinder but the top face of the cylinder is 
completely white.  This means that V==100% always produces white no 
matter what the value of H or S. It also means that if H and V are kept 
constant and S is varied, the perceived brightness and hue keep 
constant. This is acheived by two rotations of the rgb cube so that the 
white to black vector lines up with the z axis. Then the shape is 
distorted so that vectors which run from the z axis to the cube surface 
and which lie parallel to the x,y plane are stretched uniformly to unit 
length.  The resulting cylinder is squashed down the z axis to unit length.

Jon