stas at stason
Dec 20, 2001, 8:47 AM
Post #7 of 38
Thomas Klausner wrote:
> Just some comments on the stuff posted so far
>>* 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.
>>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
> 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
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
> 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.
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
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
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas [at] stason http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
To unsubscribe, e-mail: docs-dev-unsubscribe [at] perl
For additional commands, e-mail: docs-dev-help [at] perl