Bugzilla CSS plan

[Myk Melez]

Bugzilla is being converted to structural HTML and stylistic CSS for 
both skinnability <http://bugzilla.mozilla.org/show_bug.cgi?id=251068> 
and customizability 
<http://bugzilla.mozilla.org/show_bug.cgi?id=251740>, and we need a CSS 
plan that works for both.  Here's what I'm thinking:

------------------------------------------------------------------------
We move the Bugzilla CSS files, which currently live in css/, to 
skins/default/.  We style all Bugzilla pages with 
skins/default/global.css, and we style pages needing special styling 
with page-specific files named after the page they style (f.e. 
skins/default/buglist.css).

[Why move from css/ to skins/?  Because modern CSS often includes 
images, and we need to store them somewhere, and it'll be much easier to 
install skins into a single directory instead of breaking out the 
stylesheet and image files, and "css" is misleading if we're storing 
images there too.]

checksetup.pl creates a skins/custom/ directory.  We add notes to the 
skins/default/ files telling customizers to override default rules by 
putting them into the equivalent files in skins/custom/.  We also point 
out that customizers can put all their rules, including page-specific 
rules, into the single file skins/custom/global.css to make things 
easier.  We give all body tags page-specific IDs to make this possible.  
We add a caveat about the performance cost of this approach.

checksetup.pl creates a skins/other/ directory.  We tell installation 
admins who want to add skins as alternate stylesheets to put them into 
this directory.  Skins can be either a single file named 
skins/other/<name>.css or a directory of files named 
skins/other/<name>/.  The <name> of the file/directory will be the title 
of the alternate stylesheet.

[Why make checksetup create the skins/custom/ and skins/other/ 
directories?  Because we don't want them managed by CVS, since that 
complicates the output of "cvs diff".]

Bugzilla automatically adds custom and alternate stylesheets to pages 
via a template plugin that trawls skins/custom/ and skins/other/ and 
provides a list of available custom/alternate stylesheets to 
header.html.tmpl.

header.html.tmpl generates persistent stylesheet tags for custom 
stylesheets, preferred stylesheet tags with the title "standard" for 
default stylesheets, and alternate stylesheet tags with the titles 
"<name>" for other stylesheets.  Thus pages take on the default style, 
as modified by custom styles, until the user selects an alternate style, 
whereupon they take on the default 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/

Installations admins can choose a different default skin via a 
parameter, in which case the skin they choose becomes the preferred 
stylesheet.

Portions of this proposal that can be usefully implemented independently 
should be.
------------------------------------------------------------------------

Thoughts?

-myk

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