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:

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.

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

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.

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

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/

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

Sorry for the delay. The new directory structure has now landed and is available for an updated version of this patch.

First part of new index page code, index.css coming in next attachment.

First part of new index page code, index.css coming in next attachment.

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

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.

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.

Comment on attachment 163228 [details] [diff] [review] Corrected index page code (patch with correct slashes) Looks good, works well. r=myk

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

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