Stas Bekman wrote:
>
> 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.
+1 (for the above suggestion)
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.
> >>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.
> >>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.
> >>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...
> >
> >
> >>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)
> >>
> > OK. are em and small/etc renderd differently? I never really used em ...
>
> 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>?
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
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.
> >>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
> >>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
> >>- 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.
true and annoying :-)
> 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?
> 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 :-)
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
