Convert Bugzilla index page to html4 and css (no functionality change)

RESOLVED FIXED in Bugzilla 2.20

Status

()

Bugzilla
User Interface
--
enhancement
RESOLVED FIXED
13 years ago
4 years ago

People

(Reporter: Vitaly Harisov, Assigned: Vitaly Harisov)

Tracking

unspecified
Bugzilla 2.20
Bug Flags:
approval +

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

13 years ago
User-Agent:       Opera/7.51 (Windows NT 5.2; U)  [en]
Build Identifier: 

First of all I'm glad to congratulate you with bugzilla 1.8rc1.

We continue to improve bugzilla html/css code (see bug 240486, bug 245924, bug 
248379).

This is corrected index page code.

These changes are tested with:

Mozilla 0.9.8  (Windows NT 5.2)
Mozilla 1.7.0  (Windows NT 5.2)

Firefox 0.9    (Windows NT 5.2)

Opera 5.12 (Windows NT 5.2)
Opera 6.06 (Windows NT 5.2)
Opera 7.51 (Windows NT 5.2)

MSIE 5.0 (Windows NT 5.2)
MSIE 5.5 (Windows NT 5.2)
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)

Notes:

1) Links on page organized to unordered list.

2) 'ant' image moved from html to css code (this is not content, this is
   appearance). No 'ant' image for NN4 provided due to NN4 bugs.

3) Index page display changed in NN4 (is this important?).

4) Each list item receives its unique ID.

Proposal: "add to sidebar" code works only with Mozilla-based browsers with 
JavaScript enabled. I propose to hide this item by default and enable it using
JavaScript for Mozilla-based browsers. I can provide patch.

What do you think about this?


Reproducible: Always
Steps to Reproduce:
(Assignee)

Comment 1

13 years ago
Created attachment 152976 [details] [diff] [review]
Corrected index page code.
(Assignee)

Updated

13 years ago
Attachment #152976 - Flags: review?(myk)
Comment on attachment 152976 [details] [diff] [review]
Corrected index page code.

>diff -r -u css/global.css css/global.css
>--- css/global.css	Mon Jul 12 22:46:28 2004

Wouldn't it make more sense to put this into a page-specific CSS file rather
than one that gets parsed for every page on the site?  To add a page-specific
CSS file (f.e. index.css), put the following code before the line that
processes the header:

[% style_urls = [ "css/index.css" ] %]

Otherwise looks good, so granting review, but consider splitting this out into
a separate file.
Attachment #152976 - Flags: review?(myk) → review+
(Assignee)

Comment 3

13 years ago
(In reply to comment #2)
> Wouldn't it make more sense to put this into a page-specific CSS file rather
> than one that gets parsed for every page on the site?

CSS file will be downloaded by user-agent only once until it will not be 
changed.

Splitting to set of files is not good idea because one CSS file provides better
ability to easy change appearance of bugzilla by replacing only one file.

Page may have a set of alternative stylesheets which can be easily switched
using user-agent controls or piece of javascript code.

Splitting CSS to set of files makes with task more difficult.

That do you think about this?
(Assignee)

Comment 4

13 years ago
Sorry for missprints:

Splitting CSS to set of files makes this task more difficult.

What do you think about this?
(In reply to comment #3)

> CSS file will be downloaded by user-agent only once until it will not be 
> changed.

It only gets downloaded once, true, but it gets parsed every time a page is
loaded, and if every page's rules are in a single stylesheet it means the
browser will parse a bunch of rules unnecessarily every time.


> Splitting to set of files is not good idea because one CSS file provides better
> ability to easy change appearance of bugzilla by replacing only one file.
> 
> Page may have a set of alternative stylesheets which can be easily switched
> using user-agent controls or piece of javascript code.
> 
> Splitting CSS to set of files makes with task more difficult.

Hmm, good point.  Over in bug 251740 some folks are talking about adding a
local.css file which gets included into every page via a link tag right after
the link tag including global.css so that installations can override global
styles with their own.  Should this be done using alternate stylesheets instead,
or perhaps global.css should @import local.css?

What about using an @import rule to import the global stylesheet into each
page-specific stylesheet?  Then each page would only have to specify one
stylesheet, f.e. page.css, so it would work with alternate stylesheets, but at
the same time the browser would only have to parse the page-specific and global
CSS and would not have to parse any page-specific CSS for other pages.
(Assignee)

Comment 6

13 years ago
(In reply to comment #5)
> 
> > CSS file will be downloaded by user-agent only once until it will not be 
> > changed.
> 
> It only gets downloaded once, true, but it gets parsed every time a page is
> loaded, and if every page's rules are in a single stylesheet it means the
> browser will parse a bunch of rules unnecessarily every time.

This is not time consuming task. IMHO using one stylesheet file have more
pros than cons.

One file (currently global.css) can be easily replaced by other using one
Alias rule in apache config when someone wants to skin its own bugzilla
installation.

> > Splitting to set of files is not good idea because one CSS file provides 
> > better ability to easy change appearance of bugzilla by replacing only one
> > file.
> > 
> > Page may have a set of alternative stylesheets which can be easily switched
> > using user-agent controls or piece of javascript code.
> > 
> > Splitting CSS to set of files makes with task more difficult.
> 
> Hmm, good point.  Over in bug 251740 some folks are talking about adding a
> local.css file which gets included into every page via a link tag right after
> the link tag including global.css so that installations can override global
> styles with their own.  Should this be done using alternate stylesheets 
> instead, or perhaps global.css should @import local.css?

If local.css file will be included to global.css then rules from global.css
will have higher priority over rules from local.css.

If someone will skin their own bugzilla installation it will replace
default global.css file completely because rules from default stylesheet
will intersect with rules from new stylesheet.

> What about using an @import rule to import the global stylesheet into each
> page-specific stylesheet?  Then each page would only have to specify one
> stylesheet, f.e. page.css, so it would work with alternate stylesheets, but at
> the same time the browser would only have to parse the page-specific and 
> global CSS and would not have to parse any page-specific CSS for other pages.

Yes, this can be done. But let's I say it again: if we have a skinning in
mind converting existing code to strict html4 and css better to have one
file over bundle because one file can be easily replaced by other (see
http://csszengarden.com/).
> > It only gets downloaded once, true, but it gets parsed every time a page is
> > loaded, and if every page's rules are in a single stylesheet it means the
> > browser will parse a bunch of rules unnecessarily every time.
> 
> This is not time consuming task. IMHO using one stylesheet file have more
> pros than cons.

According to David Baron, Mozilla CSS hacker, while parsing the stylesheet isn't
time consuming, applying the rules is, especially with rules like "#page-index
p" and "body#page-index p".


> One file (currently global.css) can be easily replaced by other using one
> Alias rule in apache config when someone wants to skin its own bugzilla
> installation.

Replacing whole directories of files is just as easy.  In fact, the HTTPD docs
on the Alias directive give just such an example:

http://httpd.apache.org/docs/mod/mod_alias.html#alias


> If local.css file will be included to global.css then rules from global.css
> will have higher priority over rules from local.css.

True, but if we do it the other way around--i.e. local.css or a page-specific
CSS file imports global.css--then the site- and page-specific rules will take
precedence over the global rules, and we'll still be specifying a single
stylesheet in the HTML, so it'll be just as easy to specify alternate stylesheets.


> If someone will skin their own bugzilla installation it will replace
> default global.css file completely because rules from default stylesheet
> will intersect with rules from new stylesheet.

Right, but the other common use case is installations customizing their look and
feel with minor modifications that don't constitute a complete skin.  In this
scenario it makes sense for installations to continue using global.css and
merely override it where appropriate with higher precedence rules.


> > What about using an @import rule to import the global stylesheet into each
> > page-specific stylesheet?  Then each page would only have to specify one
> > stylesheet, f.e. page.css, so it would work with alternate stylesheets, but at
> > the same time the browser would only have to parse the page-specific and 
> > global CSS and would not have to parse any page-specific CSS for other pages.
> 
> Yes, this can be done. But let's I say it again: if we have a skinning in
> mind converting existing code to strict html4 and css better to have one
> file over bundle because one file can be easily replaced by other (see
> http://csszengarden.com/).

I have skinning in mind, but I also have performance, code maintenance, and
customization to think about, and site- and page-specific CSS files offers
better performance, simpler, more organized code, and easier customization. 
Even for skinning, though, installing a directory of files isn't significantly
harder than installing a single file, and the multi-file approach has the added
benefit of letting skins import portions of the main stylesheet for pages they
don't intend to change.

Comment 8

13 years ago
This looks like a duplicate of Bug 69654 where there are some patches to do this
(though they are now outdated for sure)..

I have submitted a patch in Bug 69654 which allows to create flexibles CSS.
Example is in action at http://bugzilla.xpertnet.biz/
(Assignee)

Comment 9

13 years ago
(In reply to comment #7)
> > > It only gets downloaded once, true, but it gets parsed every time a page 
is
> > > loaded, and if every page's rules are in a single stylesheet it means the
> > > browser will parse a bunch of rules unnecessarily every time.
> > 
> > This is not time consuming task. IMHO using one stylesheet file have more
> > pros than cons.
> 
> According to David Baron, Mozilla CSS hacker, while parsing the stylesheet 
isn't
> time consuming, applying the rules is, especially with rules like "#page-index
> p" and "body#page-index p".

Draw attention that in case of non index page this rules will not be applied.
If document not contains specified ID this rules just will be skipped.

> I have skinning in mind, but I also have performance, code maintenance, and
> customization to think about, and site- and page-specific CSS files offers
> better performance, simpler, more organized code, and easier customization. 

Ok, let's move this way. We are waiting for new directory structure to
continue our work.

(In reply to comment #9)
> > According to David Baron, Mozilla CSS hacker, while parsing the stylesheet 
> isn't
> > time consuming, applying the rules is, especially with rules like "#page-index
> > p" and "body#page-index p".
> 
> Draw attention that in case of non index page this rules will not be applied.
> If document not contains specified ID this rules just will be skipped.

They'll be skipped, but it takes a good bit of time, since for every p in the
document, we walk up its parent chain and check if each element is a body
element, and if so, if its id is "page-index".  (We have optimizations so that
class and ID selectors perform very well when they're on the subject of the
selector, but not when they're on a simple selector (CSS2.1 terminology) other
than the subject.)
Blocks: 253449
Sorry for the delay.  The new directory structure has now landed and is
available for an updated version of this patch.
(Assignee)

Comment 12

13 years ago
Created attachment 163226 [details] [diff] [review]
Corrected index page code

First part of new index page code, index.css coming in next attachment.
Attachment #152976 - Attachment is obsolete: true
(Assignee)

Comment 13

13 years ago
Created attachment 163228 [details] [diff] [review]
Corrected index page code (patch with correct slashes)

First part of new index page code, index.css coming in next attachment.
Attachment #163226 - Attachment is obsolete: true
(Assignee)

Comment 14

13 years ago
Created attachment 163229 [details]
css file for index.html.tmpl

1) Copy index.css to skins\standard\.
2) Create directory skins\standard\index.
3) Move ant.jpg from root directory to skins\standard\index.
(Assignee)

Updated

13 years ago
Attachment #163229 - Flags: review?(myk)
(Assignee)

Updated

13 years ago
Attachment #163228 - Flags: review?(myk)

Updated

13 years ago
OS: Windows Server 2003 → All
Hardware: PC → All

Comment 15

13 years ago
Comment on attachment 163229 [details]
css file for index.html.tmpl

(In reply to comment #14)
> 3) Move ant.jpg from root directory to skins\standard\index.

I'd suggest not moving ant.jpg, but just leaving it in for the sake of
ease-of-testing. I'd also like the ant to be called logo or splash or
front.jpg, because any site customizing the image will probably change it to a
different critter.
Attachment #163229 - Flags: review?(myk) → review-
(Assignee)

Comment 16

13 years ago
Created attachment 163336 [details]
Corrected index.css for index.html.tmpl (ant.jpg -> front.jpg)

1) Copy index.css to skins\standard\.
2) Create directory skins\standard\index.
3) Copy ant.jpg from root directory to skins\standard\index\front.jpg.
Attachment #163229 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #163336 - Flags: review?(kiko)
Comment on attachment 163228 [details] [diff] [review]
Corrected index page code (patch with correct slashes)

Looks good, works well. r=myk
Attachment #163228 - Flags: review?(myk) → review+

Comment 18

13 years ago
Comment on attachment 163336 [details]
Corrected index.css for index.html.tmpl (ant.jpg -> front.jpg)

Yeah, that was my main concern (there is a testing harness that uses it in
fact).
Attachment #163336 - Flags: review?(kiko) → review+
(Assignee)

Comment 19

13 years ago
When will be this patch commited to cvs?
Right now.  Sorry about the delay. :-/

This is relatively low risk.  It's still too significant to go into 2.18 at this
late stage in the game, but it would be valuable to get into 2.20.

skins/standard/index/front.jpg template/en/default/index.html.tmpl
RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/index.css,v
done
Checking in skins/standard/index.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/index.css,v  <--  index.css
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/index/front.jpg,v
done
Checking in skins/standard/index/front.jpg;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/index/front.jpg,v  <--  front.jpg
initial revision: 1.1
done
Checking in template/en/default/index.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v  <-- 
index.html.tmpl
new revision: 1.18; previous revision: 1.17
done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: approval+
Resolution: --- → FIXED
Target Milestone: --- → Bugzilla 2.20
Assignee: myk → vitaly
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.