Cory 'G' Watson
gphat at loggerithim.org
Sun Dec 7 22:31:10 UTC 2003
On Dec 7, 2003, at 2:59 PM, Jouni Heikniemi wrote:
> Mm, yeah, I didn't mean a blind replace of "subsubheading" with
> "bugsummary". But when the content of subsubheading is a bug summary,
> class name could reflect it. When it's something else, let's reflect
> then. We are not supposed to assume that all subsubheadings are created
> equal (on style level), right?
I was under the impressions that being that generic was precisely the
goal. If you call it 'bugsummary', you've pretty much made it
impossible to use anywhere else.
> 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.
I like the example, actually. I've never used <hX> where X > 3 for
anything before. :/
> How old browsers do you refer to? It's a pain, I agree, but display:
> works surprisingly well if you're ready to accept reasonable variance
> the UI. Anyway, we shouldn't base our default UI on the ability to
> 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.
Absolutely. I was referring back to a few of Christian's suggestions
for using <div's> for elements of the heading, which need to be inline
to stay horizontal.
> Yes. The problem with iterative development is that it's not
> well suited to our reasonably heavy-weight review/approval system. But
> still, getting a couple of iterations done is probably the nature of
> 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
> we still have quite some time left before 2.18, so it's probably
> to get the basics in.
Yes. Changing class names would be Bad for anyone who was doing the
exact thing we are trying to enable: simply making mods to a
stylesheet, rather than huge CSS mods.
> 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
> user's view of it. The whole reviewer posse has good working knowledge
> the internal issues, so what you said about many eyes applies again.
I voiced this mainly because I've not looked into what crazy CSS will
be required for other pages. I spend my of my patch time on the bug
info page. I'm not qualified to devise a set of classes and such that
Just Work everywhere.
Cory 'G' Watson
"The universal aptitude for ineptitude makes any human accomplishment
an incredible miracle." - Dr. John Paul Stapp
More information about the developers