Bug 69654

[Ludovic Dubost]

Let's add my 2 cents about the CSS discussion and share a little my 
experience with making bugzilla CSS aware.
First what I was trying to do because it was not only making bugzilla 
CSS but also included several interface changes.

- modify the core template code to be able to apply CSS and decide where 
to put the different actions that use to be in the footer
- add a action menu bar on top instead of having the action spread 
throughout the page
- allow the creation of a 'standard' and 'advanced' section in all pages 
(with optionally the advanced mode being hidden by default)
- allow the creation of a switchable 'read-only' and 'edit' view for bug 
views
- trying to have a common look accross the different features

--> these changes came after 4 years of usage of bugzilla with users 
with less tech experience using it and having to face resistance to the 
usage of the tool from time to time by potential users (Marketing team, 
etc..)

- Especially being able to have the actions in a menu bar at the top of 
a page is more similar with the usual experience non-tech users have 
with computer applications.
- The hidding of the advanced mode allows new users to bugzilla to not 
be confuse with less critical fields easing the adoption of the tool.
- Changing the look to use CSS buttons not only allows to change it more 
easily but gives a 'sexy' look that is quite important to easy the 
adoption of the tool to a resisting non-tech audience..

Typical problems/choices that occured:

  - Definitively using a standard way of using H1/H2/H3 for titles and 
sections is usefull to reduce the amount of CSS to be written.
  - It was impossible to completely use CSS without JS for certain 
effects (menu drop downs using a click or show/hide the 'advanced' 
block). Note that it would be nice that the CSS design allows to created 
drop-down even if it is not the path the the mainstream bugzilla wants 
to take.
  - Forms are definitively easier to layout using tables especially when 
you dynamically show/hide certain form elements. I choose to keep the 
table layout for each section and use DIVs for surrounding each 
section.. Like this:
  - Also using a standard naming for the 'standard' and 'advanced' DIV 
allows to apply the same CSS/JS code. Creating a separate div for the 
header of each section was a way to apply a style.

<div id="editadvtitle"><h1>Advanced</h1></div>
<div id="editadv">
<table>... with form elements</table>
</div>
<div>

A different choice could have been to put the <h1> in the <div id="editadv">

  - The footer is at the bottom of the page. The only way to get it back 
at the top is absolute positioning. So float positioning is kind of 
forbidden if you want to keep the footer at the bottom in non CSS mode.

  - form elements in actions (like the Find box) are a bug pain to embed 
in CSS buttons (big source of CSS hacking) especially when you want it 
to work the same way in different browsers. It is better to split them 
in different elements and give the and different 'id' or 'class' to 
allow to apply specific styles to them.
  - I first used <li> for each action, search query or admin menu item. 
But in fact there is a neat solution to keep the '|' as separators so 
that the no-style view looks like it does in the current footer. Like this:

<div id="actions">
        <a href="enter_bug.cgi">New</a><span> | </span>
        <a href="query.cgi">Search</a><span> | </span>
</div>

with the following styles, it will create buttons:      

#actions a {
    display: block;
    float: left;
    list-style-type: none;
    margin: 0.2em;
    padding: 0.4em;
    background-image: url(button_c.gif);
    background-repeat: repeat-x;
    background-color: #4A946B;
    font-size: 11px;
    font-weight: normal;
    font-style: normal;
    font-family: verdana;
    color: white;
    text-decoration: none;
    text-align: center;
}
    
#actions span {
    display: none;
}

  - One of the major issue when it comes to flexibility is the fact that 
all actions lists are dynamic (some actions don't always appear). This 
clearly forces to use a certain level of 'float' positioning and not 
'absolute'.. This probably means that all layouts are not possible 
depending on the way the fields are named and grouped together. For 
example it will be painfull (and maybe impossible) to change the order 
of actions using CSS.
  - IE especially 5.x have problems with certain directives and 
especially block sizes.. It might be needed to use some box level 
hacking to counter this when creating buttons using CSS
   - IE 6 has a problem with the <!-- bugzilla.org 1.0 --> comments 
place before the DOCTYPE (which allows to switch IE6 to the W3C 
standard). See http://bugzilla.mozilla.org/show_bug.cgi?id=225938
   
Lastly I want to defend a little the 'skin' system that was used which 
Gervase commented in the bug 
(http://bugzilla.mozilla.org/show_bug.cgi?id=69654#c43):
   - It was easy to implement so I don't think there are a log of 
maintenance issues.
   - It allows to create slightly modified looks, for example for PDAs 
of for specific browsers when you cannot workaround a browser bug.. This 
was inspired by the way http://www.csszengarden.com/ allows to switch 
CSS styles.
   - I don't say that bugzilla should be delivered with many skins and 
that there should be a skin trading mecanism.. But it could be a way to 
more easily apply other peoples work on your bugzilla installation 
without patches..

I hope this helps in creating a CSS aware bugzilla which would allow to 
create different looks for bugzilla without having to patch templates..

Ludovic