allan wrote:
but that was not what i meant in my mail. i meant, change this:
text text ... text
top-widget (or any widget)
text text ... text
to:
text text ... text
top-widget (or any widget)
text text ... text
more vertical whitespace. it will increase the chances of a vertical scrollbar but will be a hell of a lot easier and cleaner to read.
even when we now use the image? See for example:
http://domm.zsi.at/modperl-site-domm/docs/2.0/devel/testing/testing.html#Batch_Mode
3) (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)
I agree. That's why I dumped the boxes in the domm-version
+1 please send me patches, preferably gradually. so we fix a piece at a time. But a few together is fine too.
regarding menu. i prefer the boxed verion, but either we ignore ns4+ in the sense that it will look bad, but not exactly unsuable, or we use a html-table as in my version. i dont vote for bullets or arrows or a unboxed version of the menu.
it looks the same in mozilla and ns4-79 on linux, but yes, the menu has lost some of its appeal without a border. I guess the previous versions were somewhat better, so we couldn't figure out how to resolve the buggy browsers problems without using tables. So shell we use a table here?
well, as far as i understand the use of ems is _basically_, please correct me someome if i wrong here:
browser-config: whatver font, 10pt. style.css: whatvever font 1.5em => 15pt.
browser-config: whatever font, 15pt. style.css: whatvever font 2.0em => 30pt.
"am em is the actual height of the element's font as rendered on a given display device" (from the flamingo book)
so, for instance, if we have a specfic nested <p>-tag in a <div>-tag:
div {10t} p {2.0em} => 20pt because
I guess the question is whether the majority of the browsers will do the right thing.
the only problem i see with using relative sizes is that if someone browser confic, has, say a default-font-size set to 56pt it will look quite bad. well, the fonts will look beautiful, but the design/boxes will look bad :-) this is extreme cases so i dont think we need worry.
but then users can adjust their settings no? I don't think we try to deviate from the sites with similar content (info). Are we?
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
+1 to give it a try
that's what we have now
+1
10) the images for download widget should have specified image proportions
+1 but we still haven't got the final images ...
+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.
i dont see the [pdf|src] as navigation, do you? that is why i dropped the idea stas mentions above.
_if_ we decide to use the contrasting colour images i suggest to _not_ use the [pdf|src]-icons _if_ we decide _not_ to use the contrasting colour images i suggest we do use the [pdf|src]-icons
of course you are right. let's keep the slick navagation colors for navigation only.
So check the new way the [SRC][PDF] is presented (no icons at all) (though the [PDF] link doesn't appear, but imagine that it does). Do you like it better? The problem I had with the src-icon is that it wasn't clear that it was a source (no problem with the PDF icon).
-1, it doesn't work in reality because people use different lengths of- use tabs for indention
tabs and they don't always use tabs but mix with spaces.
true and annoying :-)
but tell you editor to do the annoying part for you, I've long forgotten that my tab is actually using spaces and use tab-key for indentation all the time.
So if your tab is 8 chars and mine is 4, and you mixed tabs and spaces, it'll look very bad for me.
it will only look bad if i _mix_ tabs and spaces - otherwise it will just be a "larger" view of the same file, no?
yes, but you *always* end up mixing these, because in some cases you the text end up on the border of the tab and you happen to adjust it with the space bar, forgetting about using tab.
So may be you as in Allan, will be perfect with using the tab everywhere, but you as in Stas may slack and mix things. So in the multideveloper env we try to find the best solution that works for everybody. Given the fact that it's a sw editor's responsibility to the right thing.
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
ok, no problem. but think of all that silly extra bytes browsers need to download :-)
You can use Apache::Clean! :)
_____________________________________________________________________ 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]
