Bugzilla CSS plan

[Myk Melez]

Here's the revised Bugzilla CSS plan.  Significant changes include:

    * third-party skins live in skins/ instead of skins/other/;
    * page-specific stylesheets live in page-specific subdirectories of
      skins/standard/;
    * pages get classified rather than identified by installation and CGI;

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

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 in a page-specific 
subdirectory (f.e. skins/standard/buglist/buglist.css).

[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.  We're putting 
page-specific stylesheets into page-specific subdirectories to group 
them together with their images and reduce the likelihood of moving them 
in the future, which would break existing custom styles and third-party 
skins.]

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/20040729/52cb0686/attachment.html>