Bugzilla CSS plan

Christian Robottom Reis kiko at async.com.br
Fri Jul 23 23:47:22 UTC 2004


On Thu, Jul 22, 2004 at 05:47:37PM -0700, Myk Melez wrote:
>    Bugzilla is being converted to structural HTML and stylistic CSS for both
>    skinnability and customizability, and we need a CSS plan that works for
>    both.  

[Myk outlines a plan that allows for multiple skins and customized
 installations whose local style applies over the skins and the default
 style. I discuss his proposal with him over IRC to understand his
 motivation and share ideas.]

I have an alternative proposal, that I'm suggesting specifically for
2.20; the central motifs of this proposal are YAGNI and KISS. My
thoughtline is summarized as:

    - We currently have *very* limited support for customized styling, so
      we're practically starting from scratch.

    - When starting from scratch, it's my opinion that we should start
      simple and then move on to more complex solutions.

    - We're not sure if people preparing customized styles of Bugzilla
      will [be able to/want to] do so without touching templates.

    - We don't want to spend more time on this solution than strictly
      necessary right now, because we want to invest effort in our
      *default* UI which needs a *lot* of work.

    - We can move on to a more complex setup (with easier multiple
      skinnability) if 2.20 promotes the appearance of
      independently-released drop-in skins.

That's my central line of reasoning. The facilities I propose are dead
simple:

    - Provide a single empty /css/custom.css file for people to write
      their customized rules in. This file is linked to last in the
      header and thus applies over *any* styles defined for the page.

            (patch attached to bug 251740)

    - Use /images to place your customized images.

            (done on trunk)

    - Use location/use-oriented names for images instead of
      content-oriented names:
      
        - frontpage.jpg instead of ant.jpg
        - tree-open.png instead of plus.png

        (please don't bring up that ant.jpg is useful for debugging, I'll
         add a test.jpg file to the root directory that would be
         functionally equivalent).

All customizations should be done to custom.css. All images should go
into /images. 

People producing third-party skins (if they actually appear) should
provide tarballs that were structured:

    /css/custom.css
    /images/frontpage.jpg
    /images/tree-open.png
    /images/tree-closed.png

This is trivial to implement, requiring nothing beyond patches already
written and some trivial image manipulation.

This also makes the point that we want to invest in *our default UI*,
which is what we should work together on improving -- my position is
that skins are additionals that some people may want, but the default
look should be *good enough* to make the average installer not want one.

My suggestion is that we go with this plan during 2.19. If it turns out
this was too simple-minded it is *trivial* to move on to a more complex
mechanism in a few months (versus being non-trivial to move *back* from
a complex mechanism once it's implemented).

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331



More information about the developers mailing list