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 Juul <aj...@mondo.dk> on 2002/07/10 08:31:54 UTC
a little feedback
hi
i got a few mails from people who checked the rc1. a few of the issues we
knew already. please find enclosed a digested feeback text file which at
least discusses some issues i think we should/could look at when the next
version rolls out (:-)). really they are not ISSUES, but more NICETOHAVES,
maybe we can have such a file at perl.apache.org/NICETOHAVES ?
./allan
Re: a little feedback
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> but if we don't specify any family what could possible go wrong?
>
> I really dislike a few of the fonts that get rendered on my machine,
> e.g. I really don't like Helvetica to be first. But as we saw you cannot
> satisfy everybody when you have only one order to choose from.
>
> And I don't want to specify in my browser to override all other fonts,
> exactly for the reason you have mentioned: many sites will be simply
> unusable without these fonts (I suppose). Is our site going to have the
> same issue?
>
> > lastly we will have to do at least some testing on various
> > setups, so i suggest we move this issue to next version
>
> I guess so. But i really wasn't satisfied with the fonts setup from the
> beginning and simply didn't know of any better compromise. Now that this
> idea comes up, I'm eager to give a shot if it helps many people.
>
> But you are the design captain, so please decide.
let's wait and get the mod_perl site released ASAP
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: a little feedback
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> Stas Bekman wrote:
>
>> > [Tom's comments:]
>> >
>> > And personally, I
>> > wouldn't suggest named fonts at all. My Helvetica, for example, is a
>> > PostScript version which renders web pages very poorly. I would
>> > prefer that my browser's default sans-serif font be used instead.
>>
>>Hmm, I actually like this idea. Will it work? Currently the fonts we
>>have absolutely suck on linux. If this can work, I'm +1 on this idea, to
>>do it right now.
>>
>>The question is, why everybody else is specifying the fonts?
>
>
> everybody does it to "force" their design over the users
> head i guess. i agree with you and tom [i personally find it
> a feature], but hesitate to make the move. people who want
> to use their own fonts will already know how they can
> overrule our stylesheets fonts. if people do that by default
> they will always know what to expect. if we dont specify the
> fonts a "normal" user [i'm only guessing] will first have to
> find out that:
>
> a) our site doesnt specify a font-family
> b) where do i specfiy my own fonts in my application?
but if we don't specify any family what could possible go wrong?
I really dislike a few of the fonts that get rendered on my machine,
e.g. I really don't like Helvetica to be first. But as we saw you cannot
satisfy everybody when you have only one order to choose from.
And I don't want to specify in my browser to override all other fonts,
exactly for the reason you have mentioned: many sites will be simply
unusable without these fonts (I suppose). Is our site going to have the
same issue?
> lastly we will have to do at least some testing on various
> setups, so i suggest we move this issue to next version
I guess so. But i really wasn't satisfied with the fonts setup from the
beginning and simply didn't know of any better compromise. Now that this
idea comes up, I'm eager to give a shot if it helps many people.
But you are the design captain, so please decide.
>> > Many of your visitors will be using Lynx, I expect. (I, for one, am
>> > always using Lynx when I am configuring a server and need to consult
>> > the documentation.) You might want to direct some effort into making
>> > the pages look a little prettier for them.
>
>
>>The only thing we can improve is the <pre> sections which currently
>>stick to the main text.
>
>
> how do you mean, no whitespace?
no extra newlines, like this
% make
next line
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: a little feedback
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> > [Tom's comments:]
> >
> > And personally, I
> > wouldn't suggest named fonts at all. My Helvetica, for example, is a
> > PostScript version which renders web pages very poorly. I would
> > prefer that my browser's default sans-serif font be used instead.
>
> Hmm, I actually like this idea. Will it work? Currently the fonts we
> have absolutely suck on linux. If this can work, I'm +1 on this idea, to
> do it right now.
>
> The question is, why everybody else is specifying the fonts?
everybody does it to "force" their design over the users
head i guess. i agree with you and tom [i personally find it
a feature], but hesitate to make the move. people who want
to use their own fonts will already know how they can
overrule our stylesheets fonts. if people do that by default
they will always know what to expect. if we dont specify the
fonts a "normal" user [i'm only guessing] will first have to
find out that:
a) our site doesnt specify a font-family
b) where do i specfiy my own fonts in my application?
lastly we will have to do at least some testing on various
setups, so i suggest we move this issue to next version
> > Many of your visitors will be using Lynx, I expect. (I, for one, am
> > always using Lynx when I am configuring a server and need to consult
> > the documentation.) You might want to direct some effort into making
> > the pages look a little prettier for them.
> The only thing we can improve is the <pre> sections which currently
> stick to the main text.
how do you mean, no whitespace?
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: a little feedback
Posted by Stas Bekman <st...@stason.org>.
Allan, only now I've realized where you've gotten these comments from :)
Thanks for that, pal!
Here are some comments:
> [Tom's comments:]
> As far as fonts, I question the rationale in specifying a size of 1em
> for the body. Wouldn't browsers assume that?
I think that currently we don't specify 1em anymore. I can see only one
place where it must be specified (h4{})
> And personally, I
> wouldn't suggest named fonts at all. My Helvetica, for example, is a
> PostScript version which renders web pages very poorly. I would
> prefer that my browser's default sans-serif font be used instead.
Hmm, I actually like this idea. Will it work? Currently the fonts we
have absolutely suck on linux. If this can work, I'm +1 on this idea, to
do it right now.
The question is, why everybody else is specifying the fonts?
> Many of your visitors will be using Lynx, I expect. (I, for one, am
> always using Lynx when I am configuring a server and need to consult
> the documentation.) You might want to direct some effort into making
> the pages look a little prettier for them.
I think the site looks great under lynx (at least with the one that I
have lynx-2.8.5-0.7mdk). I'm not sure what is the issue here. Correct me
if I'm wrong.
The only thing we can improve is the <pre> sections which currently
stick to the main text.
> [Terje's comments:]
>
> That's ok. If you are getting ready for release, now is a good time
> to start tentative planning for the next major overhaul. I'll make my
> comments in that light.
>
> 1) Please, *please*, reconsider the design decision that put the
> navigation(-ish) boxes on the left side of the page!
>
>
>> by navigation(-ish) boxes, do you mean the prev|up|next currently
>> on >the righthand side of the screen?
>
>
> I mean the "Slashbox"-style boxes down the left edge of the page.
> They simply eat up too much of the valuable left margin of the page.
> The margin in print/layout works because it's _empty_ space; it
> creates some air on the left of the main body text. When you put
> "stuff" there you create a distraction which intereferes when you try
> to read the main body text. Placing those boxes on the right side
> takes care of this problem as well as degrading more gracefully when
> printed or viewed on low-resolution screens.
this is out of question because we have many wide pages (due to <pre>
mainly) and people will end up scrolling right all the time to get to
the navigation widgets.
>> we want to produce a seperate print style sheet, that hopefully
>> will take care of what you describe above
>
>
> Separate stylesheets for different media are a good idea, yes. I
> would prefer to move those boxes for on-screen presentation too
> though, for the reasons above. If you feel very strongly about
> keeping those boxes where they are, you may consider providing an
> alternate stylesheet that puts the boxes on the right (Mozilla-based
> browsers lets you choose which of several alternate stylesheets to
> use from a menu).
moreover, our current design is fscked up, because we use a fixed
absolute width for left and right boxes, so if you want to flip the two
it simply won't work.
> 5) You use a "<link>" element to refer to the "bookmark icon", but
> ignore the navigation ("top", "next", "previous", "toc", etc.)
> <link>s that lets Mozilla and other modern browsers provide the
> navigation.
>
>
>> i dont get you, exactly what is wrong with that ?
>
>
> <link rev="start" href="/"> <link rev="next" href="chapther2.html">
> <link rev="glossary" href="glossary.html">
>
> These let you define logical relationships between the various pages
> on the site -- especially for logical collections of pages such as
> the manual -- that will allow smart browsers to provide an UI for
> moving between those parts. Read up on the Mozilla "Links Toolbar",
> or the similar feature in iCab. Search engines can also take
> advantage of this sort of markup.
we could add this, though the problem is that other than next and prev
which we already have and they are use to map to <link>, I'm not sure
what to do about the rest.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org