Thomas Klausner wrote:
Hi!
Just some comments on the stuff posted so far
Stas:
* The menu is not fixed and may grow, so it's probably the best to keep it as a single column on the left (but trying to keep it as narrow as possible). Also in order to avoid unnecessary scrolling on short pages, it's probably the best to keep the head of the page as short as possible.
I'd also prefer the navbar on the lefthand side.
* The [prev - up - next] widget is neat but should be centered and appear on the top as well. Before the table of contents I guess.
I agree with that.
Jonathan:
This isn't a problem. Use HTML's <Table>, use a fixed with for the column, and set the main tables width to 100%
I don't like the idea of using HTML tables to structure a site. Tables are good to present tabular data, but (IMO) shouldn't be used for page layout.
I know that a lot of sites are doing this, but this isn't a reason to do it, too (cf Microsoft).
:: I think that this problem can be fixed by making the 'where I'm in the :: site' widget bar of a fixed size? Or is it a bad idea? Bad idea - what happens at different resolutions? Horizontal scroll bars at low res and masses of whitespace at high res.
I would suggest a fixed width, either in pixels or in percent, or a mixture.
In my initial submission I used fixed widths for the left navbar, and a percentual value for the content box. The only problem was when text inside a <pre> tag was bigger then the browser window (but I think that would happen too if you use tables)
You miss one problem that I see at least with mozilla (check your original design). When the content part is empty or there is too little to fill the whole width, what happens is the main box's border shrinks. What we want is to have the skeleton fixed, so when you flip through pages, you see the content changed but not the base. Can you reproduce the problem?
e.g. see:
http://domm.zsi.at/modperl-site-domm/stats/index.html
We still have the problem with <pre> which is too wide, but I think what's you've created is pretty good. So we can probably live with this inconvenience. The document writers should be aware of this problem and try to make the code sections under 80 chars width. (You have the same problem when you write a book). Basically I say this is not a designer's problem so we delegate it to the author.
But I still don't like the idea of having the main box's fixed width. I like Jonathan's idea of ensuring that there is always enough width to make the box stable.
Hmm, may be you always insert
print ' ' x 80; ? but we lose then one line, let's how it works out.
All but very basic CSS is still a non-starter if you want to guarantee cross-browser capability.
I don't (want to) work to gurantee cross-browser capability, but standards complienance. If the browsers are not standard compatible, it's the browser manufactureres problem, not mine. You only have to inform the users politly that, if they are seeing crap, it's their browsers fault.
BTW, one of the big advantages of CSS is that you can switch them off, and that sites using CSS are usable with non-graphic browser (lynx, etc)
I agree with Thomas here.
Some new comments: I think that the background color of the breadcrumb trail (never knew it was called that, BTW) and the Table of Contents can be done better using CSS.
Allan, do you think you could do a "proper" release of your new design, so we can work on that?
What about putting the site distribution in CVS somewhere? I have got a CVS running here, I think I could put it there, but maybe Stas wants the src part more accessible to him? Should we split the distro into src and tmpl ?
It'll be all in cvs. The problem is that I didn't decide yet how exactly to layout the docs. The problem goes like this:
We have 3 repositories.
modperl-2.0 modperl-docs modperl-site
Now both, modperl-2.0 and modperl-site want to share modperl-docs, since you want to find the pods in the modperl-2.0/docs of the source distribution and you want to be able to use the same docs for the modperl-site repository. And now remember that there will be a transition period where the old site is still there and the new one is not ready for the production.
Originally I wanted to kill modperl-site rep completely, but then I realized that modperl-docs shouldn't include the non-docs, so it's going to be like this:
modperl-2.0/docs <-- modperl-docs modperl-site/src/docs <-- modperl-docs
simply you set the CVSROOT/modules to embed modperl-docs at the desired subdirectory (using -d).
Hence if you prefer to store the design temporarely elsewhere it'd be great. I believe that I'll get back to work on the layout and new site next week and so I will start doing the cvs reps changes. But may be it'll take longer.
As for the separation of src and tmpl, there is no problem. Leave the src as it is, and just work on the tmpl with whatever is in src. The two things are unrelated (which is great!). Also Allan mentioned that some of the src docs are not standard complient, that's fine, we will fix that later.
Once tmpl is more or less satisfying we just grab it and use it.
Is that OK?
I don't know if I find some time to make a new design suggestion in the next few days (Christmas is coming ...), but I think I'll do something before New Year.
Yeah, let's make a nice present for the modperl community for the New Year! :)
_____________________________________________________________________ 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]
