yoDan wrote:

- to the best of my knowledge and understanding, Strict HTML is indeed the best doctype for PWG, so if it is fine with you, let's do that

OK, so let's do that

yoDan wrote:

- picture.tpl doesn't look "table-based" to me, chrisaga. Did you mean another page?

Corect it's not table based but there are some tables in it. We may decide that tey are legitimate tables but IMHO the  untranslated summary attribute value isn't.

z0rglub wrote:

I've started to work directly into CVS template cclear.

Thanks I'll not need any more to run after your improvement in the default template to port them on ccclear ;-)

z0rglub wrote:

First : wow, it's great to use and modify.

Thanks it's still in progress but some parts are actually "lighter"

To answer your questions, first this work is based on yoDan work on an 1.4 template and I tried to respect his choices

z0rglub wrote:

- what is the purpose of #the_page, since BODY already exists

It was the #main of the default template yoDan renamed (don't know why) . I planned to rename it back at final. It's useless for this template but give the frame of the default template (white border and background).

z0rglub wrote:

- I thought it was fine to have linked underlined (with dots) on first version of yoDan template, but A border-bottom has dissapeared, why ? (personnaly, I'll had them for my personnal use)

Yes, but I messed it up and begin to have hugly links rendering so I disabled it (but planned to turn it back on). If you did, set it in CVS.
In addition, the underline whas solid in geko (firefox 1.0.6) (Firsttime I saw IE behaving better than Geko)

z0rglub wrote:

- there was an alignement issue on picture.tpl, because of floating blocks, I fixed it (not in CVS yet) by an invisible horizontal line with clear:both before comments list. Was that the problem of alignement?

No, I didn't start to work on picture.tpl . I have the hardest time getting a thubnails table looking good in Geko, IE and Opera when thubnails are not the same size (landscape, portrait, 4/3, 3/2, 16/9, ...) and the names wraps on several lines, and is HTML 4.01 strict. yoDan's design based on dispaly:inline-table variants works but   doesn't display well in Geko (I hate to say that, but we found some tricks to make IE working, not Geko). I even tried a design based on display:run-in or display:compact but only Geko understants it :-(

In addition, I don't like very much the need to fix the width...
I'm still working on it,

z0rglub wrote:

- what is the logic (explained, I think I understand, but I'd like to hear it from template creators) of stylesheets separation. There are many. Isn't it a bit too much complex? Personnaly, I like to have all property of A:hover set in the same block and not the color in a stylesheet, the layout in another (but I've management to work with the existing separation).

Again, it was on yoDan's work and I didn't wanted to change it untill we could discuss it.

I think it woul be good to keep "theme" css rules (i.e. colors backgrounds, text decoration, ...) away from pure layout rules because these are the rules we will do the difference betwen cclear template and say default template.
Splitting up the layout css give no benefit while it doesn't get huge, unless yoDan had in mind a very modular desing where every block can be moved by just choosing a different general layout, for instance getting the menu bar right or on top (i did this in my 1.3 templates).
Whatever option we take, a havy cleaning is necessary in the css.

z0rglub wrote:

- default #menubar width (and consequently #content margin-left) is too small I think. I've change it from 14em to 22em (my category tree is quite deep).

Totally agree !

A small request for you : could you add an id attribute with the name of the template on the body tag? It would help us. We could for instance keep a narrower #menubar in the administrative section without much code.

chrisaga wrote:

A small request for you : could you add an id attribute with the name of the template on the body tag? It would help us. We could for instance keep a narrower #menubar in the administrative section without much code.

I can do it, but I don't see the point right now :-/ Something like <body id="cclear"> would suit you?

In administration, IMHO the title of the page should be in h1 and not in h2 (as current version of template "default") : having h2s without h1 is a nonsense.

Among naming conventions, there is another one I found really : uppercase for HTML tags and lowercase elsewhere. DIV#comment, BODY, A#illustration.

chrisaga wrote:

Sorry I was not clear before: it's actually not about the name of the template (like cclear, default, ...) but the name of the page (like category, admin, ...).

I understand now and obviously, it can be very useful (the example you gave is the most relevant)

chrisaga wrote:

z0rglub wrote:

In administration, IMHO the title of the page should be in h1 and not in h2 (as current version of template "default") : having h2s without h1 is a nonsense.

To be honest, I expected this, but I do think it should be the same in administration as in category and yoDan took H1 for the logo/main title. If it's Ok with both of you, we could use a generic DIV for that and get the H1 back.

yoDan is right, I had forgotten the gallery title! To be coherent, I must had the gallery title in comments.php, profile.php, search.php and so on. And in admin.php too.

I can see the cclear template is moving fast. I can hardly keep track, actually.
I am concerned with the new nesting level in the thumbnails (UL.thumbnails LI.thumbnails DIV UL LI ...) with mixed "display" property (I can now see display bugs in the thumbnail list both in Opera and FF.), using the same class name "thumbnails" applied to a UL and a LI is IMHO a call for weird bugs in the future, I do not understand ULs with a single LI (for the picture name, in category.tpl) and a <LI>&nbsp;</LI> is certainly not quite right.
A last few notes:
* in picture.tpl, P would be a more appropriate container than DIV for {information.INFORMATION} (top of the file)
* one cannot write {comments.comment.COMMENT} directly inside a <blockquote></blockquote> block, it needs to be wrapped in a P
* oh, and WTH is BSF? :)

yoDan wrote:

I am concerned with the new nesting level in the thumbnails (UL.thumbnails LI.thumbnails DIV UL LI ...) with mixed "display" property (I can now see display bugs in the thumbnail list both in Opera and FF.), using the same class name "thumbnails" applied to a UL and a LI is IMHO a call for weird bugs in the future, I do not understand ULs with a single LI (for the picture name, in category.tpl) and a <LI>&nbsp;</LI> is certainly not quite right.

I read you seem concerned :-/. I agree with you that HTML must become as simple as possible (it's already far simpler than with previous template "default"). I think you're quite right about the UL/LI for displaying thumbnail informations. Indeed, personnaly, I don't display anything under thumbnails but when they represent a category (see include/config_default.inc.php:$conf['show_thumbnail_caption'] configuration parameter). The number of comments is an option, false by default, and advised not to turn on because of numerous SQL queries.

About thumbnails captions, when the name of a category is displayed, it's sometimes the full name, I mean [cat1 > cat 1.1 > cat1.1.3] with ">" replaced by BRs. You can have an example on special page "last categories".

Having an empty LI is certainly not quite right, but this can be avoided by having a template block <!-- BEGIN nb_comments --> containing the LI. I'm not fond of UL/LIs for thumbnail caption, but this could be a solution (and have a UL with a single LI, and in case of $conf['show_thumbnail_caption'] set to false, an UL with no LI.

Obviously, the thumbnail HTML/CSS code is the most difficult part of the job. Let's make it as simple (compatible, maintenable) as possible, couldn't we?

As you two have arguments, I think the best would be to discuss of the "thumbnails display" point here and once everybody agree on the best solution, we commit it into CVS. YoDan goes on vacaations in 5 days and chrisaga in 10 days, I'll have to maintain this part of code once you're gone and I'd like to understand why it's been done this way and not another :-).

yoDan wrote:

* in picture.tpl, P would be a more appropriate container than DIV for {information.INFORMATION} (top of the file)

I'll make the modification.

yoDan wrote:

* one cannot write {comments.comment.COMMENT} directly inside a <blockquote></blockquote> block, it needs to be wrapped in a P

Oh, OK. The content of {comments.comment.COMMENT} (I have to change this ugly code) is HTML with BRs to create new line... (see include/functions_html.inc.php:parse_comment_content which uses nl2br PHP function). I should modify the function generating the HTML content. I won't add a wrapping P tag in the template but in the function (since a comment can contain more than one paragraph)

yoDan wrote:

* oh, and WTH is BSF? :)

Best So Far, best in term of new features, not in stability :-)

I continue on my thoughts...

Maybe it could be the right time to differentiate category.php displaying thumbnails linked to picture.php and category.php displaying thumbnails linked to category.php. As in Menalto Gallery application, when the thumbnail represents a category, it is alone on the line, left aligned, with the description of the category on the left (like comments in current BSF comments.php). Calendar would require the same kind of display.

In my opinion (and that's why I've recently added $conf['show_thumbnail_caption'], to set it to false for my personnal use) there should be no caption under thumbnails, only "tool tips" (infobulle en français).

Your opinion?