252278 - Enable the use of alternate stylesheets in Bugzilla

Status: RESOLVED WORKSFORME

(Bugzilla :: User Interface, enhancement)

Description

[Christian Reis]

It would be neat to enable the use of alternate stylesheets in Bugzilla: this
would allow (apart from offering multiple visual designs) offering CSS to filter
or enhance displays based on certain aspects of a bug.

For instance, alternate stylesheets for buglist.cgi would allow us to offer a
style that visually enhanced bugs by severity, by priority, by the amount of
time they have been left open, by the amount of time spent on a bug, etc.

This is an easy fix that could use the JS code from
http://www.alistapart.com/articles/alternate/ to make the CSS style setting
persistent (via cookies). I have an implementation but it's sorta blocked by
other changes to header.html.tmpl that need to be checked in first.

Comment 1

[Christian Reis]

Attachment: kiko_v1: enable alternate styles and offer JS functions

This patch does two things:

  - adds an alternate_styles argument to header.html.tmpl that allows
specifying multiple styles; I moved around the JS to allow JS to manipulate the
styles after they are linked from
  - adds a styleswitcher.js file that implements cookie-persistence
functionality and a JS API.

To have this, just use something like this to your template file:

[% PROCESS global/header.html.tmpl
  title = title
  javascript_urls = ["js/styleswitcher.js"]
  alternate_styles = [
      ["css/priority.css",     "Priority"],
      ["css/severity.css",     "Severity"],
      ["css/timetracking.css", "Time Tracking"],
  ]
%]

It works through magic.

Comment 2

[Tobias Burnus]

Comment on attachment 153776 [details] [diff] [review]
kiko_v1: enable alternate styles and offer JS functions

You should update the INTERFACE description.

Besides: There is a problem with the current implementation: the default
stylesheed has no title. It is then regarded as "Basic Page Style". If it has a
title the browser's default stylesheet is the "Basic Page Style".
Whether this makes a difference or not depends on the values set in the default
and the choosen alternative stylesheet.
At least on one of my pages it makes a huge difference. I don't know whether
this is a real problem, but at least it may create suprising effects.

Comment 3

[Jouni Heikniemi]

Comment on attachment 153776 [details] [diff] [review]
kiko_v1: enable alternate styles and offer JS functions

Ok... This code is pretty clean, but I think the concept still needs some work.
Denying review based on a couple of things:

1) Burnus is right re the persistence/preferred -thing on style sheets. See
<http://www.w3.org/TR/html401/present/styles.html#h-14.3> for details. My take
is that we should make the default stylesheet the preferred alternative, not a
persistent one - so in terms of code, add |title="Basic Bugzilla style"| or
something equal to the default style <link>. The same goes for the local style
sheet perhaps added in bug 251740. How does this patch work re multiple default
style sheets? 

2) From a broader perspective: In bug 251740 it came up that we should be ready
to support page-specific CSS; this is a major challenge for this patch, since
the JS that sets the cookie persistence should be able to store page-level
style selections ("style=buglist:xxx;show_bug:yyy") without bloating the
cookiespace totally. Also, the question on how to write the identifiers
("buglist", "show_bug") in the example above is an interesting question (CGI
naming fails at "page", if not earlier ;-))

3) Although adding this support is fine per se, it's just bloat unless we do
something useful with it... Adding the links should be pretty straightforward.
Even though it'll probably require some debating, I think the global page
header should provide a minimalistic default UI for selecting the stylesheet if
alternatives are provided - that would make this so much more useful. At least
we should discuss this alternative, if we plan on checking the JS lump in.

Comment 4

[Christian Reis]

(In reply to comment #3)
> sheet perhaps added in bug 251740. How does this patch work re multiple 
> default style sheets? 

Well, my test install has multiple, non-alternate style sheets installed (the
site.css and global.css files). Nothing special that I can see happened -- both
stylesheets are used, and there is only one non-alternate option: "Basic Theme".

The alternate stylesheets apply *in conjunction* with the basic theme, which is
exactly what we want. To demonstrate, I've styled my local installation to use
Verdana in custom.css. You can navigate it and try the multiple styles in
buglist.cgi; just click on the URL link.
   
> 2) From a broader perspective: In bug 251740 it came up that we should be ready
> to support page-specific CSS; this is a major challenge for this patch, since
> the JS that sets the cookie persistence should be able to store page-level
> style selections ("style=buglist:xxx;show_bug:yyy") without bloating the
> cookiespace totally. 

This is easy to do as an additional patch; just make the create and read cookie
work with page prefixes. I'd be happy to do that once the basic support (this
patch) is included.

> Also, the question on how to write the identifiers  ("buglist", "show_bug") in 
> the example above is an interesting question (CGI  naming fails at "page", if 
> not earlier ;-))

I'm not sure what you mean here.

> 3) Although adding this support is fine per se, it's just bloat unless we do
> something useful with it... Adding the links should be pretty straightforward.

It's very useful right now -- just being able to mark up bugs by certain
attributes dynamically has been a very interesting feature for dependency tree
and the buglist, in customer sites. My intention is of course to fold back these
changes into Bugzilla.

> Even though it'll probably require some debating, I think the global page
> header should provide a minimalistic default UI for selecting the stylesheet 
> if alternatives are provided - that would make this so much more useful. At 
> least we should discuss this alternative, if we plan on checking the JS lump 
> in.

This patch is just infrastructure. It doesn't do any user-visible change, and
that's why I think it's so uncontroversial. It's trivial to add alternate styles
and use them as you wish. If we want to have global "default" alternates, it's a
matter of providing a way to set the default and push on to it page-specific
alternates. Is that what you're asking about?

Comment 5

[Jouni Heikniemi]

> The alternate stylesheets apply *in conjunction* with the basic theme, which 
> is exactly what we want. To demonstrate, I've styled my local installation to 
> use Verdana in custom.css. You can navigate it and try the multiple styles in
> buglist.cgi; just click on the URL link.

It may be exactly what _you_ want _in this case_ but is it what most people want
in the general case?

It may be. That applies, IF most of the uses for this technology are like yours:
decorations/additional visual information over the normal view of Bugzilla. If
they're more structural and possibly show different visual elements, having all
of the stylesheets apply is probably a recipe for disaster and maintenance
headaches.

> > the JS that sets the cookie persistence should be able to store page-level
> > style selections ("style=buglist:xxx;show_bug:yyy") without bloating the
> > cookiespace totally. 
> This is easy to do as an additional patch; just make the create and read 
> cookie work with page prefixes. I'd be happy to do that once the basic 
> support (this patch) is included.

Why not do it properly at once?

> > Also, the question on how to write the identifiers  ("buglist", "show_bug") 
> > in the example above is an interesting question (CGI  naming fails at 
> > "page", if not earlier ;-))
> I'm not sure what you mean here.

The style cookie format example quoted above consists of key/value pairs. The
question is how the keys for different pages should be named.

> > 3) Although adding this support is fine per se, it's just bloat unless we do
> > something useful with it... Adding the links should be pretty 
> > straightforward. 
> It's very useful right now -- just being able to mark up bugs by certain
> attributes dynamically has been a very interesting feature for dependency tree
> and the buglist, in customer sites. My intention is of course to fold back 
> these changes into Bugzilla.

I agree, your ideas have lot of merit. I don't think we have to provide default
CSS styles for this - although it might be a good idea to throw in some examples
in contrib or documentation.

But:

> > Even though it'll probably require some debating, I think the global page
> > header should provide a minimalistic default UI for selecting the stylesheet 
> > if alternatives are provided - that would make this so much more useful. At 
> > least we should discuss this alternative, if we plan on checking the JS lump 
> > in.
> This patch is just infrastructure. It doesn't do any user-visible change, and
> that's why I think it's so uncontroversial. It's trivial to add alternate 
> styles and use them as you wish.

As already said, I don't think we need "default alternatives", but the default
UI is another thing. I'm talking about adding something like the following into
the global header template (pseudocode):

[% IF alternative_stylesheets %]
  <p>Alternative viewing styles:
  [% FOREACH style in alternative_stylesheets %]
    <a href="#" onClick="setActiveStyleSheet('[% style.name FILTER js %]');">
      [% style.name FILTER html %]</a>
    [% "," IF !loop.last() %]
  [% END %]
  </p>
[% END %]
 
This would make it very easy for administrators to plug in alternative
stylesheets; you'd only have to add the url to the template in question, and
Bugzilla would show the UI. Even though the UI would be pretty rough, it would
probably suit most of the people, and it would certainly be an easy start for
customization.

Anyway, my point is that it makes little sense to check in the lump of JS code
unless we also check in code that uses it. I'm not sure whether throwing in the
default UI is wise or not, but that option shouldn't be ignored.

Comment 6

[Frédéric Buclin]

You can add as many stylesheets as you want since Bugzilla 3.0.