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