Bug 69654

Sat Dec 6 22:13:38 UTC 2003

At 10:33 6.12.2003 -0200, you wrote:
>I actually like the direction the patch is going.

Any patch enhancing CSS support is a step in the right direction. Most of 
the issues I raised in the bug are relatively small things; the important 
ingredient is that we have people ready to work for this. Kiko described my 
last comment in 69654 as "apocalyptic" - didn't mean to sound that bad :-)

Right now, I suggest we stop posting patches to 69654 and file new bugs (to 
keep 69654 as a meta bug). The banner stuff already posted on the bug is an 
excellent start.  Then, we should discuss the main issues with BZ 
CSSification here, so that we're at least aware of all the problems, even 
if we can't find the solutions for all of them.

Although this will probably get messy, here are some ideas on various 
issues (sorry, it's rather long, and my brain is already nigh-asleep):

>As for the <h1>/<h2> issue, I can accept your rationale for having the
>organization's identification up there. So we would have, for a sample
>query.cgi, contrasting vanilla bugzilla with a pseudo-branded bugzilla:
>    <h1>    Bugzilla Main Page      Gozilla.org: Family-Approved Sprockets
>     <h2>    Bugzilla Version XXX    Bug Tracking (Bugzilla XXX)
>     <h3>    Search for bugs         Search for bugs
>     <h4-h6> (free)                  (free)

This Hx organization is a hard one. For me, the intuitive solution is to 
have the whole banner as an H1. Now, you can argue that "Bugzilla version 
xxx" is really a subheading and the version text is only a placeholder. 
However, we can also approach this the other way around. The page headings 
don't have to reflect real world relationships totally: a company with 
divisions and country-level units would hardly format (or even mentally 
think about) their web pages with heading hierarchies like

h1: Megacorp Ltd
h2: European division
h3: Finnish unit
h4: Press information

More likely, this would be reduced to a h1 "Megacorp Ltd, Europe / Finland" 
and a "Press information" h2.

I don't see a problem with "Gozilla.org Bug tracking tool v2.17" being the 
semantic "first-level heading". The fact that it's all marked up as h1 is 
fine with me; people can customize different parts of h1's to look 
different. The ugly but trivial example is <h1>Acne Corp - <small>fleshing 
out your face</small></h1>.

There is also the point of possible repetition of a certain heading level. 
It doesn't sound too good to have levels H1-H3 fixed to be once per page 
only, because then we're left with pretty few usable levels. H5 and H6 have 
horrible default renderings (sometimes smaller than body text, and 
non-graphic browsers have a hard time separating them from higher heading 
levels), so it would probably be good to stick to first four levels as much 
as we can.

So,

>For request.cgi:
>
>     <h1>    Bugzilla Main Page      Gozilla.org: Family-Approved Sprockets
>     <h2>    Bugzilla Version XXX    Bug Tracking (Bugzilla XXX)
>     <h3>    Request Queue           Request Queue
>     <h4>    Flag: approval          Flag: whatever
>             Flag: review            Flag: hassle
>     <h5-h6> (free)                  (free)

I'd go for

<h1>    Gozilla.org bug tracking (Bugzilla XXX)
<h2>    Request Queue
<h3>    Flag: approval
<h4-h6> (free)

>    <h3>    Bugzilla Bug YYY        Bug YYY
>         <span id="subheading">      <span id="subheading">
>             ui: need more electrons     ui: need more electrons
>         <span id="subsubheading">   <span id="subsubheading">
>             changed 2003-08-31          changed 2003-08-31
>     <h4-h6> (free)                  (free)

Now, what's the point of having a semantic markup and then slipping with 
stuff like "subheading" and "subsubheading"? (you probably mean class 
instead of id anyway) Or maybe the names of the classes were just badly 
selected? They should probably be something natural such as "bugsummary", 
right?

>I'm not 100% those subheading spans shouldn't be divs, so we can quibble
>over that if people like.

This is a can of worms, but we don't probably have to care. Majority of the 
most useful CSS rules are applicable for both blocks and inlines, and you 
can always customize with display: block/inline. The correct default simply 
comes from our needs wrt the default layout. For the most part, it's 
probably going to be div for separately positioned elements.

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. In what sort of case could somebody reasonably 
mix non-Bugzilla style sheets into this? Maybe if you have a site-wide 
element that you want to copy into Bugzilla, but then you're best off by 
giving your separate element an id and forming all CSS rules with syntax 
like "#commonlogobanner .email { blah }" to force rule containment.

Then there is the capitalization and naming style issue. "requestHeading", 
"RequestHeading", "request_heading" or what? Underscores have been formally 
allowed for class names for some time now, but may cause problems with 
really old browsers. This is probably a non-issue since our current styles 
have underscores as well, and we haven't heard many complaints. I prefer 
names  like "requestHeading", but anything goes.

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

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?

NS 4 support: I'd say let's hide all CSS from NS4 and strive to keep our 
markup as semantically valid as possible. That will leave pages readable, 
but it probably will drastically change the look of some pages (show_bug 
mostly) in the course of time. Excluding NS4 will cut down development time 
a lot.

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.

Should we aim for lots of classes and simple selectors 
(.queryform_cclist_checkbox) or fewer classes and more hierarchical 
selectors (#queryform #cclist input.checkbox)? I prefer the more 
hierarchical model, but it will take some effort in the design phase. CSS 
files end up lot more readable though. Multiclassing HTML elements is a 
related issue, but it's perhaps not the time to start that discussion here 
(especially if we end up excluding NS4 anyway).

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.

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; 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).

All right, those are some questions and thoughts on them. Stuff like 
setting fonts and colors with CSS are relatively easy to do once some of 
those basic decisions are made. CSS layout is of course going to be much 
harder and require much more thought. All discussion is warmly welcomed :-)

Jouni