Re: [wgo] i18n && skin

[Ricky Zhou <ricky zhou gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Simone: Sorry, I forgot to reply to all the first time)

Simone Deponti wrote:
> Well, it's more or less what I'm doing. Although it's not exactly a copy
> paste job due to some peculiar characteristic of plone and how we chose
> to implement menus and all.
> But that's mainly the idea. I used the display block and float approach
> for the navbar tho, since this seems to be the most common approach and
> in my opinion the one that gives the best result. As for the bottom grey
> border, I don't think that using a container div should be a problem at
> all, since it doesn't seem to me (but I might be wrong on that) that it
> breaks the semantic badly in any way.
Honesty, most of the default Plone styles are simply unnecessary for
(and probably conflict) our design, not to mention that class/ID names
will be different once we introduce our markup (and even things like
that horrible table layout).  To put reworking the CSS into context, it
really took me about two-three days worth of some free time to put my
mockup together (and I did not need to reimplement much plone CSS).

I don't think the main point of my message got through though.  I was
really trying to stress the importance of completing the HTML before
starting CSS work.  By doing it in parts as we are now, it's going to
become very difficult to tell what's been done or not, and parts of
the default Plone layout will be difficult to remove (or worse, will
persist into later versions).

Since we have significant time until the final design is put out, it
would definitely be best to start working on markup so that we're in
an organized state when we start CSS work.  Although a single person
might be able to manage the changing markup and CSS at the same time,
it will soon become unmanagable when a team of people are constantly
committing changes.  At this point, one has to search through the
numerous HTML/CSS files to make sure that a change doesn't conflict
with/break other work.  When the markup is pretty much finalized, we
pretty much have one file to worry about/manage (and this will make
merging changes *much* easier).

To restate my goal:
I propose that we finish all HTML work before worrying about any CSS at
all.
To use a painting analogy, we should delete default CSS to get a clean
canvas to work with, instead of just covering the existing painting
(and wasting a lot of paint).

Hope this gets my point across,
Ricky

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcPc5iXbZ7NjlUcARAjR5AJ4+LiITfJJx3KXPs+O24pQGWlkMwQCfdTZY
4WzUjljb6+bv1hdipO/vcI0=
=KpLQ
-----END PGP SIGNATURE-----