Bug 69654

[Jouni Heikniemi]

On Sun, 7 Dec 2003, Gervase Markham wrote:

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

Let's hope there will be a moment when a capable person will have both the
sufficient information and the time to do this. I think throwing some
ideas around first is a good idea, though.

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

Actually, while what you say is true, I disagree. If you click a link on
some page and end up on something called "Bug 34567", you're pretty much
baffled. While it's true that when navigating inside Bugzilla the first
really interesting heading is the page title, I still don't think we can
skip the heading describing the particular installation.

Screen readers have all sorts of problems, and we're not going to be able
to solve all of them here. At this point, I feel that having a meaningful
page outline (auto-constructed from the Hx elements) is the best we can
do. An H1 of "bugzilla.mozilla.org: Bug reporting system for Mozilla and
related products" and a H2 of "Bug 23134: Yadda yadda" is pretty good in
this sense.

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

Or, more practically speaking, we should at least avoid scaling the
default body font (fine-tuning heading sizes et al is usually more
acceptable). It's very easy to convince me to that, but people usually
view the default font sizes as way too large. This is not too bad with
serif fonts, though; Arial and especially Verdana suffer from this far
more.

> > Should we, during the transition to CSS, aim for a strict doctype? This
> What's the benefit of Strict?

Apart from the concept of "The Right Thing" (which is arguable, sure),
strict doctype tends to eliminate quirk modes, thus giving us less hassle
with misinterpretations of certain rules. Take a look at
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>
for a small sample of what I'm talking about.

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

The problem here is that it's potentially hard for the wrapper pages to
know all required css file references. It takes quite a bit of work to
figure out which style sheets could be necessary in all possible parameter
combinations. For example, if some new popup-based UI feature gets checked
in and used in several pages (like our current user selector), it can be
potentially hard for all pages to include exactly the proper combination
of css files.

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

20, of course. But if it's 200 in ten files or 200 in a single file, the
difference isn't that great. I'd still pick 200 in ten parts, but mostly
I'd rely on DOM inspector to see where the bug is before I fire up my text
editor at all.

The previous is not to push an opinion on the split issue. I haven't
thought about this enough to really say. It's probably possible to do the
split using some relatively natural structure (something like
"general.css", "buglist.css", "query.css", "admin.css", "show_bug.css"
comes to mind). But we're going to have to be flexible with this, of
course.


Jouni