130225 - Whole Bugzilla should use global CSS-styles

Status: VERIFIED DUPLICATE of bug 69654

(Bugzilla :: User Interface, enhancement)

Description

[Andreas Höfler]

All Bugzilla-Pages should make use of a global css-file where all default and
special settings for the interface and layout can be defined.

This would concentrate all layout-changes to a single file.

At the moment the situation is like that: If one uses a global css via the
headerhtml-setting most font- and table-styles keep the same as before because
they are hardcoded in the cgi's and/or templates.

A global css could also decrease the transfer-volume because if it's used once
it is in the browsers cache in most cases and the cgi-generated html-code would
also be shorter because instead of 100 chars style-defs only a style-id would be
needed.

Comment 1

[Matthew Tuck [:CodeMachine]]

CSS files should be templatised CGIs.  I believe this is possible.

Comment 2

[Andreas Höfler]

If the .css would be generated via templatised cgi, it isn't possible to make
use of the browser-cache anymore, isn't it?

In my opinion, the css-file should be static, otherwise this would generate
additional load on the webserver every time a webpage is displayed.

Comment 3

[Jacob Steenhagen]

I agree that we're better off *not* putting the CSS style definitions in a
template.  I don't see any gain from doing this, and I do see performance issues
with running perl/TT twice per Bugzilla page view (instead of once) just to
output what should be a static page.

Also, better CSS support for Bugzilla is bug 69654.

*** This bug has been marked as a duplicate of 69654 ***

Comment 4

[Matthew Tuck [:CodeMachine]]

There is good reason to templatise static pages, and that's what bug #106612 is
about.  Basically the admin can customise them then.  If they do it as a static
page then it'll get overwritten next upgrade.

Another reason to templatise is we want a lot of pages to later become dynamic
that don't apparently have any good reason to be at first.

AFAIK, CGIs can be cached, providing you specify the right headers.  One would
be the last changed date, which could be reasonably easily computed.  The hard
bit is if you do allow the template to become dynamic, how do you compute this
date given you don't know what information it is going to access?

Comment 5

[Myk Melez [:myk] [@mykmelez]]

>There is good reason to templatise static pages, and that's what bug #106612 is
>about.  Basically the admin can customise them then.  If they do it as a static
>page then it'll get overwritten next upgrade.

Static pages can also be customized, just not using the custom directory
approach, but as I've said before, templates in the custom directory should be
the last tool for customization, not the first.

>Another reason to templatise is we want a lot of pages to later become dynamic
>that don't apparently have any good reason to be at first.

This is a good reason, but it's still better to do it out of necessity rather
than the assumption that it will become necessary.  The latter approach is bound
to be incorrect some of the time and fail to account for the specifics of the
situation that will have to be dealt with when it actually does become necessary.

Comment 6

[Matt Perry]

Verified dupe