Bug 69654

[Cory 'G' Watson]

On Dec 6, 2003, at 4:13 PM, Jouni Heikniemi wrote:

> At 10:33 6.12.2003 -0200, you wrote:

> 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 :-)

I think it sounds just fine.

The benefit of this open development crap is that we get lots of eyes.  
I get caught up in the actual modification and start giving my styles 
bad names, and you help me catch them. ;)  You also bring up lots of 
good choices that need to be made.

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

Absolutely.

<snip>

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

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.

I'm pretty happy with my latest patch.

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

The problem with changing blocks to inlines is that things look 
different in older browsers.
>
> 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.

I'm a studlyCaps guy when it comes to CSS names.

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

I'm a tab guy in CSS, since it's separate code. I'm not married to it, 
however.
>
> 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?

Not I.

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

Yes. ;)

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

I would prefer to do that.

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

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

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

Me either.

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

If we go as hierarchical as possible, I think we can stick with a 
single file.
>
> 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 :-)

Yes, the actual work will be easy once the details are pounded into a 
fine grit ;)

Cory 'G' Watson

"The universal aptitude for ineptitude makes any human accomplishment 
an incredible miracle." - Dr. John Paul Stapp