Thomas Klausner wrote:
Hi!
On Sun, Jan 27, 2002 at 04:03:37PM +0800, allan wrote:
1) (both) more whitespace between top-widgets and text
you mean more margin between the text and the background ? +1, if this is what you mean
yeah, please explain.
2) (domm-version)
remove arrows from menu - (or remove them from lists). why? having them both places looks mis-guiding IMO and i
much prefer them in the lists.
(why did you use tables for this version of the menu ?)
Yeah, I just put them there to have some sort of identification of seperate manu items. If you just use line brakes, menu items consitsiting of two words (like "Extraordinaeire Tech") look confusing.
What about using plain <li> as on www.apache.org ?
I don't think we really need bullets, in any case I don't mind whichever way you prefer. So I'm +0 on <li> or no bullets at all.
I agree. That's why I dumped the boxes in the domm-version3) (cvs-version) the menu (box-type) looks bad in ns4.7 - and i think thomas you agree that this is just not fixable without the use of tables (see al-version)
+1 please send me patches, preferably gradually. so we fix a piece at a time. But a few together is fine too.
4) (both) we need to fix the colored crossbars at least for ns4+ as they don't span 100%. i think it is a dangerous approach to have th h1-tags background-colored. instead put them inside div tags which are more natural to have a background-color in. div tags are more glad to margin-values as well and these are needed at least for ns4+.
The reason I did this (the ".headline" CSS used in the title) is that some pages use H1 as a internal headlines and some not. But see below...
OK. are em and small/etc renderd differently? I never really used em ...i dont mind the use of small/x-small etc. but this is an endless road to trouble if we want fonts to appear more or less the same cross browser. i have had relatively good results (read, no complaints) with em font-sizes (which is a relative notation)
If you know that em is working good for relative sizing, go for it. Can you use +1, -2, +3 in the css? like you can say <font size=+1>?
5) (both)+1
link colors.
i guess the blue and underlined is ok for userbility reasons
but we should at least have a
red/pink for visited, no? i suggest #993333.
+1
+16) (both) hover color i also like the fact that ie/opera/mozilla supports the hover style for the anchor tag (i suggest #666666)- what do you think about this?
+1
6) (both) i suggest kill the table of contents header completely. (if we knew we had to implement the search function now i would suggest the version where the test-field is incorperated into the table of contents title-bar. so my cuurent suggestion is to in fact integrate the search this way and then out-comment the whole title-bar
Hm. What about making the TOC-Bar more unobtrusive by not putting a colored crossbar behind it? IMO the internal links without some indication what they are linking to are confusing.
+1 to give it a try
7) (both) h1-h6. i am very fond of the background-color used for these (#dddddd). what i dont like though, is that too many of them inside the contents gets annoying IMO. currently i suggest using those from al-version
+1 IMO those colored bars are overused
+1 for allan's version
+1 but we still haven't got the final images ...10) the images for download widget should have specified image proportions
+1 and I have a suggestion. I really love Allan's contrasting colour images idea. How about putting the acroread and source icons into such a container? So we have all the navigation things looking the same. I'd even say: [pdf|src] without any icons, but whichever you guys think is the best.
11) (all versions)Stas?
there is a ie/mac browser bug i guess that prevents it from
fethcing the stylesheet. this is caused by the path being:
././../style.css where it should be just ../style.css
it could also be
.././style.css
Yes, that's on my playground. I'll solve it.
+112) style. as well as perl style we should have (encouraged) a consequent (?) html style. i know we diagree on this as well and its late in the process but i suggest we find a common ground on this as well:)
Of course, but we use the apache/mod_perl coding style as defined here:
http://www.apache.org/~stas/modperl-site/docs/2.0/devel/modperl_style/modperl_style.html
- use tabs for indention
-1, it doesn't work in reality because people use different lengths of tabs and they don't always use tabs but mix with spaces. So if your tab is 8 chars and mine is 4, and you mixed tabs and spaces, it'll look very bad for me. So we conform with apache style and use 4 spaces identation. Your editors should be able to set your tab to expand into spaces of 4 tabs. here you can see settings for vi/emacs.
http://www.apache.org/~stas/modperl-site/docs/2.0/devel/modperl_style/modperl_style.html
- use " (double qoutes) for values
+1, but in some cases it doesn't work. There are a few templates where ' are used because of strings assignments.
- lowercase all tags
+1
I will try to merge my last version with the latest CVS-version today, implementing some of the issues raised by Allan.
Great!
Thanks Allan, Thomas! _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
