Bug 69654

[Jouni Heikniemi]

On Sun, 7 Dec 2003, Cory 'G' Watson wrote:

> > 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?
> But that is not always a 'bugsummary', just like it's not
> 'rightAligned' (from a your patch comment).

Mm, yeah, I didn't mean a blind replace of "subsubheading" with
"bugsummary". But when the content of subsubheading is a bug summary, the
class name could reflect it. When it's something else, let's reflect that
then. We are not supposed to assume that all subsubheadings are created
equal (on style level), right?

> I'm not big on using <hX> all through the document, I'd prefer to break
> the page up with <div>s, but that's just MHO.

Since HTML's headings don't really define containment, those two ideas
work well together. Using Hx makes text-browsing and NS4 (CSSless) life
easier, and it also gives the pages structure (outline).

Let's remember that while <div> is an essential part of CSS layout, it's
still nothing but a block container without defined semantics. Whenever
something forms a natural text paragraph, it should be marked up as a <p>.
The flexibility of div (the ability to have %flow content, mostly)
shouldn't be abused, or we easily lose lot of usability when dealing with
browsers that practically ignore divs.

Anyway, something like the following is usable:

<h1>MyBugzilla</h1>

<h2>Query for bugs</h2>

<div id="query_form">

<h3>Bug status</h3>
<div id="status_query">
...
</div>

<h3>Bug resolution</h3>
<div id="resolution_query">
...
</div>

</div>

The example above sucks, and I wouldn't strain things like H3 that far;
the point is simply in co-operative use of Hx elements and (possibly
stylistic) divs.

> The problem with changing blocks to inlines is that things look
> different in older browsers.

How old browsers do you refer to? It's a pain, I agree, but display: xxx
works surprisingly well if you're ready to accept reasonable variance in
the UI. Anyway, we shouldn't base our default UI on the ability to alter
the box model on the fly. When we want something inline, let's use
something that's innately inline; when we want something rendered as a
block, let's use a block element. Those who want to override our
selections can work out the browser issues.

> I'm a tab guy in CSS, since it's separate code. I'm not married to it,
> however.

If I could erase tabs from the face of the coding world, I'd do it. :-)

> I prefer hierarchical, but as you point out, it requires alot more
> thought up front.  My problem is that I do not know bugzilla's innards
> very well, and I tend to do such work iteratively.  We may have to
> rework existing styles on the third of fourth template into the work
> because of some Epiphany of Elegance (my term for coming up with a much
> nicer way to get the same results in HTML/CSS).

Yes. The problem with iterative development is that it's not particularly
well suited to our reasonably heavy-weight review/approval system. But
still, getting a couple of iterations done is probably the nature of the
beast; it's not like anyone of us could really shake out a working CSS
infrastructure out of his sleeve. As long as we stay within one release
cycle, I don't think changing class names is a catastrophe. It would seem
we still have quite some time left before 2.18, so it's probably possible
to get the basics in.

Re your problem: Knowing Bugzilla innards isn't really that critical.
Sure, you're going to have to know your way around and understand
templates, but at least equally critical is understanding the UI and the
user's view of it. The whole reviewer posse has good working knowledge on
the internal issues, so what you said about many eyes applies again.


Jouni