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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
