Bug 69654

Sun Dec 7 16:58:36 UTC 2003

Jouni Heikniemi wrote:
> Any patch enhancing CSS support is a step in the right direction. 

Indeed; but Jouni is right. When we started doing templates, Myk and I 
had a very good understanding about how we wanted them coded. The result 
of that is that most of the templates are very consistent in style and 
approach. This is a big bonus.

We could do with the same thing for CSS. Ideally, one person would sit 
down, think through all the issues and come up with a proposal, rather 
than doing it inch-by-inch on this list.

This would include conventions for naming classes, how we split up the 
CSS for each page, and what CSS we should use and not use, based on 
current browser support.

More specific comments:

> This Hx organization is a hard one. For me, the intuitive solution is to 
> have the whole banner as an H1. 

Before we went with "This is Bugzilla", the banner was an image. I think 
it's far from certain that whatever a customiser replaces it with will 
be text. I feel that this is a poor use of H1.

Imagine a screen reader. "What's this page about?", asks the blind user. 
"This is Bugzilla", replies the reader, when it should really be 
replying "Bug 12345" or "Search for bugs".

> Now, you can argue that "Bugzilla 
> version xxx" is really a subheading and the version text is only a 
> placeholder. 

The version text isn't a heading either, it's sort of a colophon. It's 
an annotation, not an important part of the semantic structure of the page.

> Moving on from the Hx issue, we have the question on naming CSS classes. 
> It's been suggested that all classes should start with bz_ to avoid 
> namespace collisions. Theoretically I agree, but are there any namespace 
> collisions to avoid in practice? Should we care? Having a prefix makes 
> things more awkward to use.

Indeed. The only possible reason is user stylesheets - and we can 
namespace those by having a id="bugzilla" on the <html> element.

> Indentation is related; I prefer 2 spaces as already done in HTML 
> templates.

Sounds good.

> Classically, pixels and percentages don't mix. To some extent, mixing 
> relative and absolute units still causes pain - mostly with IE, whose 
> font scaling bugs are worth a volume in themselves. It's a lot easier to 
> use fixed font sizes like "13px" and "17px", but that may not be in the 
> best interest of the user. Does anyone have a strong opinion on this?

We've just been round this block with the new www.mozilla.org website. 
Ideally, we wouldn't scale the user's font size at all.

> Should we, during the transition to CSS, aim for a strict doctype? This 
> is a relevant question, as rendering mode changes particularly on IE6 
> causes interesting issues when changing the doctype. Most important of 
> these issues is the different calculation of box width wrt paddings and 
> margins. I'd consider moving towards strict, although it's a real strain 
> with some things.

What's the benefit of Strict?

> What's our attitude towards CSS2 selector stuff? Selectors like 
> |input[type=checkbox]| aren't really supported that well, but they 
> possibly will be in the future. Currently, using advanced CSS2 selectors 
> would probably make Bugzilla look better on Mozilla than on IE. This may 
> or may not be a problem. I don't know; I'm not too keen to rush into 
> CSS2 stuff just yet.

My view is IE5.0+, Mozilla1.0+, recent Opera, Safari 1.0 (inc. 
Konqueror) and Lynx.

> And then there is the questions of splitting the CSS rules physically 
> across files. I believe layout-heavy pages such as the query form should 
> have their own CSS files. This may prove tricky, though, as the query 
> form is a separate template and the included CSS files must be known at 
> the start of page;

Normally, there's a "wrapper" page which includes the fragments it wants 
to make up the compound page; it will just have to make sure it also 
includes the relevant css files.

> it's not sufficient to code the CSS file requirements 
> to specific templates, but they also need to be governed from the cgi's 
> calling the header template. This is a strong point for a single-file 
> approach (or more specifically, an approach where the same set of css 
> rules is imported for every Bugzilla page).

I'm not so keen on a single file, just from a maintainability 
perspective. If you have some odd CSS interaction, would you rather look 
through 20 rules to see what's weird, or 200?

Gerv