Bugzilla CSS plan, v3

[Myk Melez]

Here's one last rev of the CSS plan.  It reduces directory structure 
complexity by moving CSS files back to skins/standard/ (i.e. 
skins/standard/<page>.css) instead of a page-specific subdirectory (i.e. 
skins/standard/<page>/<page>.css).  For pages with images and other, 
related files, we'll still store those files in a page-specific 
subdirectory, but the CSS files themselves will live in the root 
directory, making them easier to manage.

------------------------------------------------------------------------

We move the Bugzilla stylesheets, which currently live in css/, to 
skins/standard/, and we call them the standard skin.  We style all 
Bugzilla pages with skins/standard/global.css, and we style pages 
needing special styling with page-specific files (f.e. 
skins/standard/buglist.css).  Images and related files go into a 
page-specific subdirectory (f.e. skins/standard/buglist/image.png).

[We're moving from css/ to skins/ because modern style often includes 
images, and we need to store them somewhere, and it'll be easier to 
install a third-party skin into a single directory, and "css" is 
misleading if we're storing images there too.]

Custom styles live in skins/custom/.  Standard stylesheets tell 
customizers to hack equivalent files in skins/custom/ instead.  They 
also mention that customizers can put all rules, including page-specific 
rules, into skins/custom/global.css for file management simplicity, but 
they note the selector complexity and performance cost of this approach.

checksetup.pl creates skins/custom/ and a set of subdirectories/empty 
stylesheets equivalent to the files in skins/standard/.  
skins/.cvsignore tells CVS to ignore skins/custom/.

[skins/custom/ shouldn't be managed by CVS so it doesn't complicate the 
output of "cvs diff" and installations can store it in local CVS.  It 
should be global (i.e. affect all skins) so installations can use it to 
make changes that apply regardless of the user's choice of skin.]

Installation admins can install third-party skins by adding them to the 
skins/ directory and then adding their name to the "skins" parameter.  
Skins can be either single CSS files (skins/<name>.css) or directories 
of files (skins/<name>/) with the same directory/file structure as the 
default skin.  Multiple skins show up as alternate stylesheets, and 
users can switch to them via their browser's standard mechanism for 
switching between alternate stylesheets.

Bugzilla uses the standard skin by default.  Admins can make Bugzilla 
use a third-party skin by default via the "default_skin" parameter.  
Multiple skins appear to the user as alternate stylesheets.  Bugzilla 
populates the list of alternate stylesheets with the contents of the 
"skins" parameter, excluding the current default skin.

header.html.tmpl generates persistent stylesheet tags for 
customizations, preferred stylesheet tags for the default skin, and 
alternate stylesheet tags for other skins.  Pages thus take on the 
default style, as modified by custom styles, until the user selects an 
alternate style, whereupon they take on the alternate style, as modified 
by custom styles.

More on persistent, preferred, and alternate stylesheets:
  http://www.w3.org/TR/html4/present/styles.html#h-14.3.1
  http://www.alistapart.com/articles/alternate/

We classify rather than identify pages by installation (i.e. we move the 
installation-specific value of body tags' "id" attributes to their 
"class" attributes).  We additionally classify pages by CGI.  We give 
pages unique IDs where appropriate.  For example, a show_bug.cgi page 
may be identified by the bug number it displays.

Implementation of this proposal will happen in stages.  In the first 
stage, we move existing files to their new locations, make checksetup.pl 
create the custom directory/file hierarchy, make header.html.tmpl 
include custom stylesheets, and classify pages by installation and CGI.

------------------------------------------------------------------------

-myk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20040819/e3e3784e/attachment.html>