You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs-dev@perl.apache.org by allan <la...@inet.uni2.dk> on 2002/01/27 09:03:37 UTC
more and less
hello
these shots are from a mac system:
http://www.bullitt.suite.dk/b/domm-version_ns479_mac.gif
http://www.bullitt.suite.dk/b/cvs-version_ns479_mac.gif
please keep in mind that comments below are from one page
only (download/binaries.html). i probably have further
comments for other details only presents on other pages
cvs-version = http://www.apache.org/~stas/modperl-site/download/binaries.html
domm-version: http://domm.zsi.at/modperl-site-domm/download/binaries.html
and referering:
al-version = http://www.apache.org/~stas/preview/allan_24_1/download/binaries.html
my general view of what could be better is:
1) (both)
more whitespace between top-widgets and text
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 ?)
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)
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+.
4) (both)
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)
5) (both)
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.
6) (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?
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
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
8) (cvs-version)
h1-h6.
the actual size (relative or not) of these should be
specified in the stylesheets IMO
9) (domm-version)
toolbar (in need of a better word: search pdf/src prev|up|next)
this one works better than the cvs-version.
so i vote for:
breadcrumb
title
pdf|src prev|up|next
content
not:
breadcrumb
title
pdf prev|up|next
src
content
10)
the images for download widget should have specified image proportions
11) (all versions)
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
12)
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:)
- use tabs for indention
- use " (double qoutes) for values
- lowercase all tags
./allan
RE: [ANNOUNCE] mod_perl logos...
Posted by Bill Moseley <mo...@hank.org>.
At 04:10 PM 01/29/02 -0000, Jonathan M. Hollin wrote:
>It is tough - it's such an abstract concept. I'm still playing around
>with a design myself (brace yourself for my submission) and I'm torn
>between doing something completely new (dynamic, vibrant, etc) or using
>existing design cues like the eagle, feather, camel...
Go crazy. People have been struggling with the feather camel thing for a
while. How bout Two large letters that looks like they are made from stone
"MP" with a leopard sitting on top? Or lightening bolt with a wrench, or a
shooting star, or what ever comes to mind.
Then for fun the logos can be delivered based on IP, so people will say "I
like that new logo" and be looking at different things. ;)
>:: Can you put them all on a single page along with the other
>:: two logo designs?
>
>I could indeed - er, what other two logos?
The two that have been on the mod_perl dev examples lately. Were there
more than two?
>So do I! Damn and blast it, it's running on a Windows box...
I think it might be your upstream provider, as sometimes traceroutes fail,
too.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: Did I miss a call on the modperl list? I don't think there
:: are more than
:: 10 people on this list. So I won't expect many submissions.
You didn't miss such a call Stas. A major oversight on my part. I'll
get it together right away.
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Stas Bekman <st...@stason.org>.
Jonathan M. Hollin wrote:
> :: My quick opinion is 2 - 1 - 7
>
> Actually, I'm not looking for votes at this point. I was hoping this
> would encourage further submissions.
Did I miss a call on the modperl list? I don't think there are more than
10 people on this list. So I won't expect many submissions.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: My quick opinion is 2 - 1 - 7
Actually, I'm not looking for votes at this point. I was hoping this
would encourage further submissions.
:: I think the camel and feather (and even the word "mod_perl")
:: is a tough combination to work with. (I mentioned it to a
:: friend that does CD cover artwork for bootleg CDs over a
:: beer and he wanted to do a camel riding a moped with a
:: feather in its hat ;) Really, it would be fun to explain to
:: a graphic designer what mod_perl *is*, but don't tell them
:: anything about the existing icons.
It is tough - it's such an abstract concept. I'm still playing around
with a design myself (brace yourself for my submission) and I'm torn
between doing something completely new (dynamic, vibrant, etc) or using
existing design cues like the eagle, feather, camel...
:: Can you put them all on a single page along with the other
:: two logo designs?
I could indeed - er, what other two logos?
:: Thanks very much. And thanks to your designer!
:-)
:: BTW -- I often find it hard to connect to your site.
So do I! Damn and blast it, it's running on a Windows box... There,
I've confessed. It's just not stable at all, and I'm forever having to
reset Apache. The doc's are right, Apache + Windows should NEVER be
used on a production server. Truth is, I'm not even sure where the
problems lie - is it Apache, Windows or my own software? Unfortunately,
I know f&*k all about *nix, so my options are limited. So, if anyone is
able to donate hosting space and little bandwidth on a *nix box, please,
please let me know. :-(
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Bill Moseley <mo...@hank.org>.
At 11:05 AM 1/29/2002 -0000, Jonathan M. Hollin wrote:
>:: I have 7 new logo graphics available at this time. I'll put
>:: them on the web and post the details here. Sorry - I
>:: completely forgot about the icons! :-(
My quick opinion is 2 - 1 - 7
2 for the looks and I can imagine a nice color scheme with it on the site,
and it fitting into a banner, if we use one.
1 not sure why, looks fun and nice mascot
7 show's more power, I guess.
I think the camel and feather (and even the word "mod_perl") is a tough
combination to work with. (I mentioned it to a friend that does CD cover
artwork for bootleg CDs over a beer and he wanted to do a camel riding a
moped with a feather in its hat ;) Really, it would be fun to explain to a
graphic designer what mod_perl *is*, but don't tell them anything about the
existing icons.
Can you put them all on a single page along with the other two logo designs?
Thanks very much. And thanks to your designer!
BTW -- I often find it hard to connect to your site.
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: But may be we need to have more people throwing in their
:: ideas before we
:: start deciding on the new logo?
Hell yes - I wouldn't have it any other way. My own submission will
follow shortly! ;-)
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 04:28 PM 01/29/02 -0000, Jonathan M. Hollin wrote:
>
>>:: I've no problem with releasing the new site with the current
>>:: logo and
>>:: then replace it down the road.
>>
>>+1
>>The new logo can be introduced with a little fanfare all of its own.
>>
>
> One comment, which really isn't an issue. Everytime I've worked on a site
> it's been hard to get input when I need it. But soon as I release it
> everyone has an idea about a change. Then when I change something at
> someone's request everyone else then asks for it back. You can't win. :-o.
This one is easy. Run an official contest. Collect voices. Cut. Move on.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: One comment, which really isn't an issue. Everytime I've
:: worked on a site it's been hard to get input when I need it.
:: But soon as I release it everyone has an idea about a
:: change. Then when I change something at someone's request
:: everyone else then asks for it back. You can't win. :-o.
I know. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by Bill Moseley <mo...@hank.org>.
At 04:28 PM 01/29/02 -0000, Jonathan M. Hollin wrote:
>:: I've no problem with releasing the new site with the current
>:: logo and
>:: then replace it down the road.
>
>+1
>The new logo can be introduced with a little fanfare all of its own.
One comment, which really isn't an issue. Everytime I've worked on a site
it's been hard to get input when I need it. But soon as I release it
everyone has an idea about a change. Then when I change something at
someone's request everyone else then asks for it back. You can't win. :-o.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: [ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: I've no problem with releasing the new site with the current
:: logo and
:: then replace it down the road.
+1
The new logo can be introduced with a little fanfare all of its own.
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 10:05 PM 1/29/2002 +0800, Stas Bekman wrote:
>
>
>>But may be we need to have more people throwing in their ideas before we
>>start deciding on the new logo?
>>
>
> How long did you want to work on this site? ;)
like one more week? Seriously, we should be finishing this project very
soon now.
I said before that we can add many things in the future. We don't have
to change the logo now.
I was saying that it's unfair to other people who may wanted to suggest
their own logo, and we didn't give them a chance.
I've no problem with releasing the new site with the current logo and
then replace it down the road.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Bill Moseley <mo...@hank.org>.
At 10:05 PM 1/29/2002 +0800, Stas Bekman wrote:
>But may be we need to have more people throwing in their ideas before we
>start deciding on the new logo?
How long did you want to work on this site? ;)
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl logos...
Posted by Stas Bekman <st...@stason.org>.
Jonathan M. Hollin wrote:
> :: I have 7 new logo graphics available at this time. I'll put
> :: them on the web and post the details here. Sorry - I
> :: completely forgot about the icons! :-(
>
> Okay gang, the few new mod_perl logos I've collected so far are
> available at http://wypug.digital-word.com/mod_perl/. There's no need
> to keep checking back here - I'll notify the list when new logos are
> available...
Very neat, I like the 7th the best too. Though we could move the
mod_perl words elsewhere if needed.
But may be we need to have more people throwing in their ideas before we
start deciding on the new logo?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
[ANNOUNCE] mod_perl logos...
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: I have 7 new logo graphics available at this time. I'll put
:: them on the web and post the details here. Sorry - I
:: completely forgot about the icons! :-(
Okay gang, the few new mod_perl logos I've collected so far are
available at http://wypug.digital-word.com/mod_perl/. There's no need
to keep checking back here - I'll notify the list when new logos are
available...
Kindest regards to all,
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: more and less
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: >>>i thought jonathan had something up his sleeve with
:: regard to icons
:: >>>(and logo). in the meantime, please find enclosed a pod.gif for
:: >>>viewing pleasure :-)
I have 7 new logo graphics available at this time. I'll put them on the
web and post the details here. Sorry - I completely forgot about the
icons! :-(
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> >>>i thought jonathan had something up his sleeve with regard to
> >>>icons (and logo).
> >>>in the meantime, please find enclosed a pod.gif for viewing
> >>>pleasure :-)
> >>>
> >>neat :) but it's too big relative to the pdf image (I guess we can scale
> >>it down),
> >>
> >
> > in fact im not sure i agree on that (for once) - have you
> > tried to scale it up? i just did here - it looks quite
> > alright to me. see attached photoshoped gif
>
> You mean, you want it to stand out? But the images are not equivalent,
> the pdf bar is a way smaller than [src] on this snapshot.
what i liked about them bigger, is the fact that when our
site is very poor on colors and graphic elements (which is
nice) these small elements lightens a little bit up. so yes,
they stand out a little but they hardly distract the eye IMO.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> Stas Bekman wrote:
>
>>>sorry for beeing ignorant, but why do we in fact offer the
>>>src-download option?
>>>
>>for example if you want to send me a patch for some doc. You need a pod
>>for this, not the html version. And not all users know how to get the
>>cvs version. At least they need to bother less to get started.
>>
>
>
>>>i thought jonathan had something up his sleeve with regard to
>>>icons (and logo).
>>>in the meantime, please find enclosed a pod.gif for viewing
>>>pleasure :-)
>>>
>>neat :) but it's too big relative to the pdf image (I guess we can scale
>>it down),
>>
>
> in fact im not sure i agree on that (for once) - have you
> tried to scale it up? i just did here - it looks quite
> alright to me. see attached photoshoped gif
You mean, you want it to stand out? But the images are not equivalent,
the pdf bar is a way smaller than [src] on this snapshot.
>>Of course we can use a different image for each source format, but I
>>think one universal image will do.
>>
>
>
> so we will not come in a situation where we have
> pdf|pod|html for instance? (then we should have various
> images for "src" i think)
I guess we can, but it doesn't matter. It'll be POD in 99%.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> > sorry for beeing ignorant, but why do we in fact offer the
> > src-download option?
>
> for example if you want to send me a patch for some doc. You need a pod
> for this, not the html version. And not all users know how to get the
> cvs version. At least they need to bother less to get started.
> > i thought jonathan had something up his sleeve with regard to
> > icons (and logo).
> > in the meantime, please find enclosed a pod.gif for viewing
> > pleasure :-)
>
> neat :) but it's too big relative to the pdf image (I guess we can scale
> it down),
in fact im not sure i agree on that (for once) - have you
tried to scale it up? i just did here - it looks quite
alright to me. see attached photoshoped gif
> Of course we can use a different image for each source format, but I
> think one universal image will do.
so we will not come in a situation where we have
pdf|pod|html for instance? (then we should have various
images for "src" i think)
./allan
Re: more and less
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> Stas Bekman wrote:
>
>
>>Still I think the top.gif image should be made of a single color, no?
>>to be consistent with other navbars, where a different color implies a
>>different link.
>>
>
> +1 for single color, but i haven't even seen any version
> that has more than one color, which url are you refering to ??
it's in CVS. I'm not updating the online version after every cvs commit.
The sw on apache.org is incomplete, (ps2pdf is missing), so I've to
upload some 6MB+ from my machine.
You can try it by updating your cvs version and running bin/build -df
cvs up
bin/build -df
That's it.
>>>>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).
>>>>
>>>>
>>>i think i prefer the icons being there. especially the pdf
>>>icon is so well known and most people know by intuition that
>>>when they meet this icon on a website it automatically means
>>>that here is something that can be downloaded.
>>>
>>>_if_ we go for the soloution that incorperates these icons i
>>>_also_ suggest we use a non-underlined link for the two
>>>words "pdf" and "src", again because espceially the pdf-icon
>>>is so well-knowm so the user automatically knows that this
>>>section is downloadable.
>>>
>>how do we make the source icon, so that it'd be clear that it's a source
>>page and not the current html? I guess ALT="This is a source document"?
>>
>
>
> sorry for beeing ignorant, but why do we in fact offer the
> src-download option?
for example if you want to send me a patch for some doc. You need a pod
for this, not the html version. And not all users know how to get the
cvs version. At least they need to bother less to get started.
> i thought jonathan had something up his sleeve with regard to
> icons (and logo).
> in the meantime, please find enclosed a pod.gif for viewing
> pleasure :-)
neat :) but it's too big relative to the pdf image (I guess we can scale
it down), and it should say 'src' or 'source' ('src' is narrower), since
the source can actually be in HTML and in the future in many other formats.
Of course we can use a different image for each source format, but I
think one universal image will do.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> Still I think the top.gif image should be made of a single color, no?
> to be consistent with other navbars, where a different color implies a
> different link.
+1 for single color, but i haven't even seen any version
that has more than one color, which url are you refering to ??
> >>I don't think we try to
> >>deviate from the sites with similar content (info). Are we?
> >>
> >
> > what do you mean by this, i dont understand ??
>
> I was just trying to say that we don't generate something that the
> visiting users will have to adjust their setting, because things are
> different from the majority of the sites out there.
ahh, like that. no, our site won't deviate in that manner (i
hope) :-)
> >>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).
> >>
> >
> > i think i prefer the icons being there. especially the pdf
> > icon is so well known and most people know by intuition that
> > when they meet this icon on a website it automatically means
> > that here is something that can be downloaded.
> >
> > _if_ we go for the soloution that incorperates these icons i
> > _also_ suggest we use a non-underlined link for the two
> > words "pdf" and "src", again because espceially the pdf-icon
> > is so well-knowm so the user automatically knows that this
> > section is downloadable.
>
> how do we make the source icon, so that it'd be clear that it's a source
> page and not the current html? I guess ALT="This is a source document"?
sorry for beeing ignorant, but why do we in fact offer the
src-download option?
i thought jonathan had something up his sleeve with regard to
icons (and logo).
in the meantime, please find enclosed a pod.gif for viewing
pleasure :-)
./allan
Re: more and less
Posted by Stas Bekman <st...@stason.org>.
> eh, i dont get you. what image? are we not talking about the
> image with an arrow and the word "top"? that image has been
> used for some time mow, right?
> that is the image i am refering to. i simply want more
> pixels (not a lot perhaps 10-15) *above _and_ below* this
> image. if you look at
> http://www.apache.org/~stas/preview/allan_24_1/docs/2.0/devel/testing/testing.html#Batch_Mode,
> you can see what i am agitating for ;-)
done in cvs:
- updated to your version top.gif
- added new lines around it.
Still I think the top.gif image should be made of a single color, no?
to be consistent with other navbars, where a different color implies a
different link.
>>>>>>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?
>>
>
> +1 for using a table here.
> (see possible hmtl-code at: http://www.apache.org/~stas/preview/allan_24_1/)
+1, visually (NS/Opera/Mozilla).
You guys decide on the implementation.
>>>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.
>>
>
> they will certainly not do the _same_ thing, but taking
> everything (userbility, cross-browser issues) into acount i
> personally think they almost always will do the right thing
> for us.
cool, so we go with em.
>>>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?
>>
>
> yes, and we dont mind that users can adjust their settings,
> do we?
> using font size="+1" gives more or less the same result as
> using {font-size:1.2em}. with ems you can fine tune more,
> and that - combinbed with the fact that a user with damaged
> vision can increase our text-size - i like.
+1
>>I don't think we try to
>>deviate from the sites with similar content (info). Are we?
>>
>
> what do you mean by this, i dont understand ??
I was just trying to say that we don't generate something that the
visiting users will have to adjust their setting, because things are
different from the majority of the sites out there.
>>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).
>>
>
> i think i prefer the icons being there. especially the pdf
> icon is so well known and most people know by intuition that
> when they meet this icon on a website it automatically means
> that here is something that can be downloaded.
>
> _if_ we go for the soloution that incorperates these icons i
> _also_ suggest we use a non-underlined link for the two
> words "pdf" and "src", again because espceially the pdf-icon
> is so well-knowm so the user automatically knows that this
> section is downloadable.
how do we make the source icon, so that it'd be clear that it's a source
page and not the current html? I guess ALT="This is a source document"?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
>
> 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
eh, i dont get you. what image? are we not talking about the
image with an arrow and the word "top"? that image has been
used for some time mow, right?
that is the image i am refering to. i simply want more
pixels (not a lot perhaps 10-15) *above _and_ below* this
image. if you look at
http://www.apache.org/~stas/preview/allan_24_1/docs/2.0/devel/testing/testing.html#Batch_Mode,
you can see what i am agitating for ;-)
> >>>>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?
+1 for using a table here.
(see possible hmtl-code at: http://www.apache.org/~stas/preview/allan_24_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
>
> I guess the question is whether the majority of the browsers will do the
> right thing.
they will certainly not do the _same_ thing, but taking
everything (userbility, cross-browser issues) into acount i
personally think they almost always will do the right thing
for us.
> > 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?
yes, and we dont mind that users can adjust their settings,
do we?
using font size="+1" gives more or less the same result as
using {font-size:1.2em}. with ems you can fine tune more,
and that - combinbed with the fact that a user with damaged
vision can increase our text-size - i like.
> I don't think we try to
> deviate from the sites with similar content (info). Are we?
what do you mean by this, i dont understand ??
> 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).
i think i prefer the icons being there. especially the pdf
icon is so well known and most people know by intuition that
when they meet this icon on a website it automatically means
that here is something that can be downloaded.
_if_ we go for the soloution that incorperates these icons i
_also_ suggest we use a non-underlined link for the two
words "pdf" and "src", again because espceially the pdf-icon
is so well-knowm so the user automatically knows that this
section is downloadable.
> >>>>- 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 :-)
>
> 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.
and thats why you are now sometimes sloppy ;-):
> ... 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.
> > ok, no problem. but think of all that silly extra bytes
> > browsers need to download :-)
>
> You can use Apache::Clean! :)
wow, that sounds great!
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by Stas Bekman <st...@stason.org>.
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).
>>>>- 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 :-)
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:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
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: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by Stas Bekman <st...@stason.org>.
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.
>>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.
>>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>?
>
>>5) (both)
>>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
+1
>
>>6) (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
+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
>>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.
>>11) (all versions)
>>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
>>
> Stas?
Yes, that's on my playground. I'll solve it.
>>12)
>>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:)
>>
> +1
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:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by Thomas Klausner <do...@zsi.at>.
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
> 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 ?
> 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
> 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 ...
> 5) (both)
> 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
> 6) (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.
> 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
> 10)
> the images for download widget should have specified image proportions
+1 but we still haven't got the final images ...
> 11) (all versions)
> 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
Stas?
> 12)
> 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:)
+1
> - use tabs for indention
> - use " (double qoutes) for values
> - 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.
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: more and less
Posted by allan <la...@inet.uni2.dk>.
sorry, for attaching those gifs in my last mail!
also this should have read
11) (all versions)
THIS CONCERNS ONLY about/about.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org