240486 - Convert Bugzilla banner to html4 and css (no functionality change)

Status: RESOLVED FIXED

(Bugzilla :: User Interface, enhancement)

Description

[Vitaly Harisov]

User-Agent:       Opera/7.50 (Windows NT 5.1; U)  [en]
Build Identifier: 

Me and my wife have strong experience in xhtml 1.1,
css1/2 and dom/javascript coding.

We can spend our time to make bugzilla pages be less
complex and more extensible. We propose to re-write
existing html templates (step-by-step, starting from
easiest ones) in order to separate the content from
the presentation. This can be achieved by using
xhtml 1.1 for markup and css1/2 for visualization.

Spend a little of your time to take a look at
http://csszengarden.com/. In this project you may
modify the style sheet in any way you wish, but not
the HTML. At the moment the complete list of
Zen Garden submissions contains 247 designs
(based on the same html code!).
See http://www.mezzoblue.com/zengarden/alldesigns/.

We are able to write such kind of generalized html
code and provide a number of designs (at least a
single pretty one ;) for bugzilla.

Are you interested in such efforts? Can we expect
that our patches will be submitted to CVS within
the reasonable time frame?


Reproducible: Always
Steps to Reproduce:

Comment 1

[Dave Miller [:justdave]]

It's great, assuming everyone has a modern browser, but a lot of people still don't.

See http://www.hixie.ch/advocacy/xhtml for why this has gotten wontfixed the
last several times it's been suggested.

I'm willing to be convinced though.

Comment 2

[Dave Miller [:justdave]]

Oh, and I'd be completely all for user-swappable css templates with HTML 4.01
without any argument. :)

Comment 3

[Gervase Markham [:gerv]]

I'd agree with Dave - CSS is great, and moving up to HTML 4.01 is a no-brainer. 

The controversy is where you go from above there. Using XHTML-style lower-case,
proper tag matching etc. is fine. The controversy arises when you want to remove
HTML constructs e.g. <nobr> or "wrap=hard" which we need because there is no
standards-compliant alternative supported widely enough.

Let me open another can of worms: I think we should drop explicit layout support
for Netscape 4. That is, we make sure it still works in Netscape 4, but we don't
care what it looks like. That would make a move like this much easier.

Gerv

Comment 4

[Vitaly Harisov]

(In reply to comment #1)
> It's great, assuming everyone has a modern browser, but a lot of people still 
don't.

These User-Agents will render strict html correctly w/o css.
See http://www.rathedg.com/ in different browsers. This site uses many tricks to 
avoid problems in outdated browsers (e.g. Netscape 4 of MSIE 4).

> See http://www.hixie.ch/advocacy/xhtml for why this has gotten wontfixed the
> last several times it's been suggested.

Ok, we can write in HTML 4.01 Strict using lower case for tag names, attributes 
and so on.

Comment 5

[Vitaly Harisov]

(In reply to comment #3)
> The controversy is where you go from above there. Using XHTML-style 
lower-case,
> proper tag matching etc. is fine. The controversy arises when you want to 
remove
> HTML constructs e.g. <nobr> or "wrap=hard" which we need because there is no
> standards-compliant alternative supported widely enough.

nobr -> white-space: nowrap | white-space: pre.

I don't know what "wrap=hard" means.

> Let me open another can of worms: I think we should drop explicit layout 
support
> for Netscape 4. That is, we make sure it still works in Netscape 4, but we 
don't
> care what it looks like. That would make a move like this much easier.

In order to avoid incorrect rendering in NN4 we use
<link rel='stylesheet' type='text/css' href='_.css' media='all'/>

Comment 6

[Myk Melez [:myk] [@mykmelez]]

> Ok, we can write in HTML 4.01 Strict using lower case for tag names,
> attributes and so on.

If you're willing to code to XHTML-friendly HTML 4.01 (dropping from strict to
transitional if/when necessary), then I'd be delighted to accept your patches.

> Can we expect that our patches will be submitted to CVS within the reasonable
> time frame?

There's no guarantee, as we're all quite busy and our schedules vary, but I'm
quite interested in the work you're proposing, so I'll try my best to get your
patches reviewed in a timely manner.  I suspect other reviewers feel the same.

One important factor is how similar Bugzilla looks with your patches applied. 
An exact match is easy to review once we test functionality to make sure nothing
breaks.  Slight variations (f.e. several pixel shifts in the position of an
element) don't present much of a problem either.

Significant changes in layout or style, however, like fields and sections that
change position or new color/border schemes, will overlap with existing UI
redesign bugs, generate lots of distracting discussion, and expand the scope of
review, increasing the time and energy required to move your patches through the
process.

In other words, resist the temptation to make Bugzilla look or work better, at
least initially, and save that work for separate patches once your initial
patches for HTML 4.01-compliance and CSS-friendliness get applied.  Make the
first style be "what it looks like now," and provide the "what you think it
should look like" style as a separate patch.

Comment 7

[Vitaly Harisov]

(In reply to comment #6)

> There's no guarantee, as we're all quite busy and our schedules vary, but I'm
> quite interested in the work you're proposing, so I'll try my best to get your
> patches reviewed in a timely manner.  I suspect other reviewers feel the same.

So we start to work on the first page (Bugzilla Main Page).
Which version of bugzilla should we hack?

[skip]
> In other words, resist the temptation to make Bugzilla look or work better, at
> least initially, and save that work for separate patches once your initial
> patches for HTML 4.01-compliance and CSS-friendliness get applied.  Make the
> first style be "what it looks like now," and provide the "what you think it
> should look like" style as a separate patch.

We understand and agree.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #7)

> Which version of bugzilla should we hack?

Hack the very latest version from CVS, which you can check out with the
following command (all on one line):

cvs -d :pserver:anonymous:[e-mail]:/cvsroot co
mozilla/webtools/bugzilla

Comment 9

[Dave Miller [:justdave]]

99% of the templatized pages in Bugzilla already validate as HTML 4.01
Transitional.  That doesn't mean they're CSS-friendly though.  See also:

bug 224595
bug 110152
bug 92565
bug 227990
bug 192600
bug 130276
bug 69654
bug 11901 <- this one is back-end modifications to allow us to get rid of the
             wrap=hard in the textareas on the show_bug page.

Something that might cause us a little trouble:

We only have one <!DOCTYPE> header.  The same header template which includes
that header is included from every other template (except buglist I think).  So
trying to change things from Transitional to Strict on a page-by-page basis
might not be obvious.

Comment 10

[Vitaly Harisov]

(In reply to comment #9)

> Something that might cause us a little trouble:
> 
> We only have one <!DOCTYPE> header.  The same header template which includes
> that header is included from every other template (except buglist I think).  
So
> trying to change things from Transitional to Strict on a page-by-page basis
> might not be obvious.

It is not problem.
We will change DOCTYPE to strict and validate page-by-page on local system.
And then all pages will be strict we change DOCTYPE in main header.

Comment 11

[Vitaly Harisov]

We hadn't enough free time in last weeks, but today we provide first
patch to make bugzilla html code clean and css-ready.

These changes are tested with:

Mozilla 0.9.8  (Windows NT 5.2)
Mozilla 1.3.0  (Windows NT 5.2)
Mozilla 1.7.b  (Windows NT 5.2)

Opera 5.12 (Windows NT 5.2)
Opera 6.06 (Windows NT 5.2)
Opera 7.50tp4 (Windows NT 5.2)

MSIE 5.0 (Windows NT 4.0)
MSIE 6.0 (Windows NT 5.2)

Netscape 4.78 (Windows NT 5.2)

Links 0.98 (Windows NT 5.2)
Lynx 2.8.2rel.1 (Windows NT 5.2)

Comment 12

[Vitaly Harisov]

Attachment: banner template patch

1) Each banner element has unique ID.
2) <p> element is used for lynx/links compatibility.
3) <span> in elements can be used for Douglas Bowman's Background-Image Text
   Replacement trick (http://www.stopdesign.com/also/articles/replace_text/).

See http://www.mezzoblue.com/zengarden/resources/ for more details.

Comment 13

[Vitaly Harisov]

Attachment: global css patch (banner support code)

Comment 14

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 147338 [details] [diff] [review]
banner template patch

Sorry for the delay in reviewing the patch...

>+    <div id='banner'>
>+        <p id='banner-name'>
>+            <span>This is [% terms.Bugzilla %]</span>
>+        </p>
>+        <p id='banner-version'>
>+            <a href='http://www.bugzilla.org/'><span>Bugzilla</span></a>
>+            <span>Version [% VERSION %]</span>
>+        </p>
>+    </div>

This looks good except that, per standard practice elsewhere in Bugzilla, use
double-quotes around HTML attribute values, and use two space indentation in
HTML.

Question: how are the SPANs around "Bugzilla" and "[% VERSION %]" useful?

Comment 15

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 147339 [details] [diff] [review]
global css patch (banner support code)

Looks good, r=myk.

Two suggestions for making future patches easier to review: combine changes to
multiple files into a single patch, and generate patches from the Bugzilla root
directory.  Both practices make patches easy and quick to apply regardless of
how many files are being patched or where they are located within the Bugzilla
directory structure.

Comment 16

[Vitaly Harisov]

> This looks good except that, per standard practice elsewhere in Bugzilla, use
> double-quotes around HTML attribute values, and use two space indentation in
> HTML.

Ok, I'll create another one.

> Question: how are the SPANs around "Bugzilla" and "[% VERSION %]" useful?

It prodives better CSS control. You may apply additional styles to it
or define 'display: none' for SPAN and define background image for
parent element.

See http://www.stopdesign.com/articles/css/replace-text/ for more details.

Comment 17

[Vitaly Harisov]

Attachment: banner template patch (double quotes, two space instead of four, full-path diff)

Comment 18

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 147921 [details] [diff] [review]
banner template patch (double quotes, two space instead of four, full-path diff)

>+    <div class="intro"></div>
>+    <div class="outro"></div>

What are these for?

Comment 19

[Vitaly Harisov]

(In reply to comment #18)
> (From update of attachment 147921 [details] [diff] [review])
> >+    <div class="intro"></div>
> >+    <div class="outro"></div>
> 
> What are these for?

You may apply additional styling for these elements. 

Comment 20

[Anne (:annevk)]

Why are you using such complex markup? For the banner and the small line under
it, one could use:

 <div id="banner"><a href="http://mozilla.org/">mozilla.org</a></div>
 <div id="bugzilla-version"><a href="http://www.bugzilla.org/">Bugzilla</a>
Version 2.17.6</div>

You don't need extra SPAN elements for replacing the contents of an element. You
shouldn't abuse semantic markup (like using P for something that is clearly not
a paragraph). Adding useless DIVs just for fun isn't what is needed either, this
is not CSSZenGarden, this is bugzilla and we just want the same layout, not
extra functionality.

Comment 21

[Vitaly Harisov]

(In reply to comment #20)
> Why are you using such complex markup? For the banner and the small line under
> it, one could use:
> 
>  <div id="banner"><a href="http://mozilla.org/">mozilla.org</a></div>
>  <div id="bugzilla-version"><a href="http://www.bugzilla.org/">Bugzilla</a>
> Version 2.17.6</div>

We using such complex markup in order to provide an ability to "skin" custom
bugzilla installation w/o hacking html code, just css. It is main goal of
our work on this bug.

> You don't need extra SPAN elements for replacing the contents of an
> element.

As I see on top of this page "This is Bugzilla" replaced with "bugzilla.org"
image. Using our code it can be done w/o changing original html.

> You shouldn't abuse semantic markup (like using P for something
> that is clearly not a paragraph).

Hmmm. Old bugzilla code use tables for non-tabular data. Places tables
inside paragraphs and so on.

We choose the lesser of two evils. We using P element in banner code
for lynx/links only (do you see new layout in these browsers?).
If such compatibility isn't required we replace P by DIV elements.

Which browsers should we support? Do we need NN4 compatibility?
Do we need pretty (not just accessible) look&feel in text browsers?

> Adding useless DIVs just for fun isn't what is needed either, this
> is not CSSZenGarden, this is bugzilla and we just want the same
> layout, not extra functionality.

As you can see we provide the same layout, isn't it? And we provide
an ability to make new, better look & feel in future using just
another CSS file(s).

Comment 22

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 147921 [details] [diff] [review]
banner template patch (double quotes, two space instead of four, full-path diff)

r=myk

Comment 23

[Myk Melez [:myk] [@mykmelez]]

Vitaly, you need someone to check this in for you, right?

Comment 24

[Vitaly Harisov]

(In reply to comment #23)
> Vitaly, you need someone to check this in for you, right?

AFAIK I can't check-in this changes by myself.

Comment 25

[Myk Melez [:myk] [@mykmelez]]

Patch checked in.  Resolving bug FIXED.  Thanks for the patch!  Please file new
bugs for new patches (which can span multiple files but should represent some
discreet portion of this work).

Checking in css/global.css;
/cvsroot/mozilla/webtools/bugzilla/css/global.css,v  <--  global.css
new revision: 1.2; previous revision: 1.1
done
Checking in template/en/default/global/banner.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/banner.html.tmpl,v
 <--  banner.html.tmpl
new revision: 1.7; previous revision: 1.6
done