Bugzilla CSS plan

[Myk Melez]

Christian Robottom Reis wrote:

>I have an alternative proposal, that I'm suggesting specifically for
>2.20; the central motifs of this proposal are YAGNI and KISS.
>  
>
By way of comparison, my proposal's motivations are to implement the 
simplest solutions that meet our feature needs and goals and to do what 
we need to do now while preparing to the degree possible for what we 
might want to do in the future.

>    - 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.
>  
>
Note that my proposal also lets customizers edit a single file, it just 
puts that file in a different place, calls it something else, and 
suggests that customizers may want to use multiple files like with the 
standard skin for performance and maintainability.

>    - Use /images to place your customized images.
>  
>
One of the problems with using the existing css/ and images/ directories 
for custom files is that custom files show up as unknown files (or as 
changed even though a "changed" custom.css means something completely 
different from a "changed" regular Bugzilla file) in the output of "cvs 
diff -u", and installations can't track customizations on their own CVS 
server.  With images, the other problem is the risk of us checking in a 
default image that overwrites (or conflicts with) a custom one.  Thus 
it's useful to keep customized files separate from files in Bugzilla's CVS.

>    - 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
>  
>
Agreed, naming images by function rather than contents makes it much 
more obvious what to replace when creating a skin or customization.

>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.
>  
>
It also means third-party skins will overwrite the custom skin and parts 
of the default skin and that you can only have one third-party skin 
installed at any given time.  I want installations to retain the 
integrity of their default and custom skins when installing third-party 
skins and be able to install (and make available to users, ultimately) 
multiple third-party skins.

>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.
>  
>
I agree that we want to invest in our default UI, but I think skinning 
helps our cause by generating more Bugzilla UI activity from people 
whose good ideas we can bring back into the standard Bugzilla UI and 
whose bad ideas we can ignore.

It's worth noting that many installations have already created extensive 
customizations that are essentially skins.  They've done so with 
template hacks, but much of what they've done could have been done with 
CSS if Bugzilla had good structural HTML.

One of my primary motivations in kicking of templatization of the 
codebase a few years ago was to make it possible for installations to 
customize their UI without touching Perl code.  We've had some success 
with that; now we need to take it to the next level.  And just as 
templatization was and is an imperfect solution (some changes still 
require code hacking), so too will skins be imperfect.  Nevertheless, 
the closer we get to enabling customization without base file hacking, 
the better off our installations will be.

>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).
>  
>
We're already confronted with the issue with our existing stylesheet 
files and image along with the patches to improve customizability and 
skinnability.  We can't solve all the problems now, and I don't want to, 
but I do want a simple plan that provides everything we need right now 
and expect to need shortly while not arbitrarily shutting the door on 
future expansion of functionality.

In case it wasn't clear from my proposal, I'm not suggesting that we do 
everything in the proposal immediately.  What I'd like to do now is find 
a new home for the standard and custom Bugzilla stylesheets and images 
that makes it possible for us to support skinnability without having to 
move files around in the future.

Finally, I should note that while YAGNI and KISS are fine principles and 
guide my proposal as well, we've had good luck in the Bugzilla community 
with discussions over how to organize files and directories so that they 
work well for the future.  Our template directory structure, f.e. isn't 
as simple as it can be, but it is as simple as it can be while still 
supporting the features we wanted Bugzilla to have (like localization, 
customization, and hooks) and which have proven valuable to Bugzilla 
installations.  We've changed things a few times and moved files around, 
but not as much as we would have had to if we hadn't thought these 
things through first.

There's always some tension between acting on the present and preparing 
for the future, and I tend to focus on the present, but occasionally 
it's useful to consider the future implications of present actions and 
prepare accordingly, especially when there's code on a collision course, 
as is the case with our current customizability and skinnability work.

-myk