forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: bert skin added
Date Mon, 03 Jun 2002 10:16:55 GMT
Bert Van Kets wrote:
> At 08:09 2/06/2002 -0400, you wrote:
> >Great job, Bert and crew, on the new skin. A few thoughts:
> >
> >1. What's the intended use of the light blue rectangle area just above the
> >top of the white content area of page? Will it eventually contain
> >something? If not, I would get rid of it. The skin design is already
> >top-heavy enough.
> It is meant to contain paging code.  Page number, next page, previous page,
> stuff like that.  Personally I'm not sure how to do it, but I guess others
> will know.

If you look in the cocoon scratchpad you'll see the "Paginator" which is
a transformer which takes a "pagesheet" and filters out the pipeline. I
swear I'll provide samples and breif documentation real soon.

> >2. I assume the directory icons on the side bar menu will eventually be
> >dynamic, opening and closing? If not, IMO they are a bit confusing as is.
> >I found myself clicking them...
> There's a mixed feeling about a dynamic menu.  I'll change the icons to
> filled squares to avoid the confusion for now.

Yes, let's avoid dynamism for those things, I think it's useless.
> >3. I think you need a bit more white space before the first title on every
> >page.
> I'll add some.  I' guess the easiest way is to add a break before the first
> line.  This way the balance is kept when the font is enlarged.
> >4. Why are you introducing another shade of blue for the inactive tabs?
> >Why not use the same color as the the light blue used elsewhere on the page?
> I'll try it and see how it looks.  Nice suggestion btw.
> >5. I could be completely wrong, but it's my understanding that margin-top
> >is supported by your target browsers, as along as it's a positive value.
> >If you agree, here's another thought. Floating subheads (which have the
> >same amount of white space before and after) drive me crazy. They are
> >supposed to "belong" to the page elements, usually the paragraphs which
> >follow them. That is, there should be more space above a subhead than
> >below it -- not equal amounts. With the documentation I've seen so far
> >with Cocoon, it gets visually confusing, at least for me, especially in
> >documents with short paragraphs and rather large subheads. Ideally,
> >margin-bottom is a better way to implement this (that's how it's done in
> >print design), but it's problematic for some browsers. In my work,
> >subheads, known as <s> can be siblings of <p> elements. Thus, I simply
> >check if a <p> has an immediate preceding <s> sibling (
> >name(preceding-sibling::node()[1])='s'"). If true, margin-top is zero. If
> >false, it gets margin-top value of, let's say 0.5em. Subheads, in this
> >case, would get a 1em for their top-margin value. Based on this info, I
> >dynamically build a predefined css class name which reflect this and other
> >css specifications.  With Forrest, after a very quick review, it appears
> >you'd simply have to check if the position of <p> within a section.
> >Clearly this check would occur in document2html.xsl, not in the skin
> >transformation. I would be happy to submit  a patch to this effect, if
> >it's useful, appropriate, or relevant at this phase or for this version.
> If you've got it working, please do provide a patch.  Your argument is
> absolutely right. Nice solution too.
> >Sorry to be late with my comments. I don't know how everyone keeps up :/ ...
> No problem.  A site is never finished and I'm always up for
> perfection.  The use of a skin makes adjustments to the site very easy.

Yep, here are a few comments/questions on the skin as well as the

1) the path changes from

    something > something else


   something : something

I *far* prefer the first because it gives a sense of flow that the
second doesn't.

2) "build with *" buttons escalation. Please, let's remove them. We can
easily write a page "About" where we indicate what we used to build it
and blah blah blah. We *DO*NOT* need to indicate this on each and every

3) PRE wrapping: there are a few ways to solve the issue of horizontal
scrolling (which is indeed a problem in many situations)

a) perform automatic wrapping on the server side
b) perform automatic wrapping on the client side (with the ability to
turn it off via javascript)
c) create a warning if anything in a PRE exceeds 80 columns during build
d) substitute PRE with TEXTAREA
e) use CSS2 to constraing the PRE overflow in scrollable (this is not
very portable across user-agents)

4) In IE5.5 on win2k, if I reduce the font size, the PRE fonts are too
tiny to be readable. I'm not sure if this problem is solvable (but it
doens't bugg me too much, just for your information).

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message