Announcement

  •  » Requests
  •  » Improved HTML and layout

#31 2005-08-18 01:26:38

yoDan
Member
France
2005-06-05
39

Re: Improved HTML and layout

A few comments so far:
- 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
- let's work on that 1.5 branch. I go on vacations in 10 days (28 aug) and for two weeks (do the math)
- I haven't got a chance to work on the display issues chrisaga mentioned earlier in this thread. I will do that on Friday and during the WE, unless someone fixed them in the meantime
- My CVS access is pending authorization ;-)
- picture.tpl doesn't look "table-based" to me, chrisaga. Did you mean another page?

Offline

 

#32 2005-08-18 02:06:22

chrisaga
Former Piwigo Team
France (92)
2005-08-10
543

Re: Improved HTML and layout

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.


cepatre.net
Utilisateur depuis la version 1.3, Impliqué depuis la 1.4, Responsable du template des 1.5 et 1.6  ... et en (in)disponibilité sur la 1.7. J'ai fait l'impasse, et j'ai sauté directement en 2.2.2 !

Offline

 

#33 2005-08-21 02:29:45

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

I've started to work directly into CVS template cclear. First : wow, it's great to use and modify. Then, several questions/remarks :

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

- 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)

- 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?

- 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).

- 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).

- I'll soon commit changes in picture.tpl required for displaying the "set as representative" button and the code filling infoTable (no br anymore).

Offline

 

#34 2005-08-21 10:58:40

chrisaga
Former Piwigo Team
France (92)
2005-08-10
543

Re: Improved HTML and layout

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.


cepatre.net
Utilisateur depuis la version 1.3, Impliqué depuis la 1.4, Responsable du template des 1.5 et 1.6  ... et en (in)disponibilité sur la 1.7. J'ai fait l'impasse, et j'ai sauté directement en 2.2.2 !

Offline

 

#35 2005-08-21 12:39:36

yoDan
Member
France
2005-06-05
39

Re: Improved HTML and layout

Damn you are so fast. :)
I am not sure I can help you with the code until tonight (FTP access to free.fr is at best unreliable when you do not have a free.fr IP) but I can explain a bit my code, for sure.
* a naming convention (which I have not always followed myself) could be to use thePage, theNavbar, theContent and theImage for IDs.
* the purpose of thePage (formerly main, then the_page) was to make it easy to have an inner frame. CSS code should be empty, for now.
* dotted border-bottom should be no problem for Gecko (I may look at it tonight)
* thumbnails are the real big difficulty. Concessions have to be made to keep all browers happy. Indicating a width (128px when I wrote it) in the CSS is necessary (and since it is a presentationnal hint to nicely align thumbnails, it really pertains to CSS). For this, and for the navbar width issue, it makes very much sense to have a bit of CSS code generated by some PHP, depending on user preferences and gallery setup. Once the width is set, I would expect the "display:table-cell; display:inline-table; display:inline-block;" trick to take care of height differences, but more testing is always welcome.
* splitting CSS code into several files was an attempt to separate layout and colors, first, then inside the "layout" I distinguished between "general rules" (BODY, headers, links, that's about it) and page specific rules (something like "navbar.css", "thumbnail.css" or "category.css", "image.css" or "picture.css", and "admin.css").

Offline

 

#36 2005-08-21 15:18:59

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

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.

Offline

 

#37 2005-08-21 15:45:57

chrisaga
Former Piwigo Team
France (92)
2005-08-10
543

Re: Improved HTML and layout

z0rglub wrote:

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?

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, ...). The goal is the same as giving an id in each form even if we don't use it now (I started doing it) : we can adjust layout locally (for instance :
#menubar {
    ...
    width: 22em;
    ...
}

BODY#admin #menubar {
    width: 14em;
}


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.

z0rglub wrote:

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

Lowercase don't bother me because I edit files with gvim with syntax highliting. I don't like very much uppercase, but again, if it's OK with everybody, I can switch to your naming convention.


cepatre.net
Utilisateur depuis la version 1.3, Impliqué depuis la 1.4, Responsable du template des 1.5 et 1.6  ... et en (in)disponibilité sur la 1.7. J'ai fait l'impasse, et j'ai sauté directement en 2.2.2 !

Offline

 

#38 2005-08-21 22:32:10

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

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.

Offline

 

#39 2005-08-21 23:27:58

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

I've just commited adaptation of comments.tpl and admin/comments.tpl (with CSS rules that I'm sure I placed in the right place :-/). I've got a problem in the first comment to validate (so in screen [Administration > Pictures > Comments], you need to have at least one unvalidated comment, use database field comments.validated to create unvalidated comments) : my first comment has an enormous height, I don't understand which CSS rule is working here?

Offline

 

#40 2005-08-22 00:51:08

yoDan
Member
France
2005-06-05
39

Re: Improved HTML and layout

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? :)

Offline

 

#41 2005-08-22 12:56:21

chrisaga
Former Piwigo Team
France (92)
2005-08-10
543

Re: Improved HTML and layout

yoDan wrote:

I am concerned with the new nesting level in the thumbnails (UL.thumbnails LI.thumbnails DIV UL LI ...) with mixed "display" property

First I was trying to fix some display bugs in FF, then I decided to get rid of the <BR /> in the properties displayed below the thumbnail. I was inspired by the conversation you had with zorglub about <BR /> in thr image.tpl
Maybe it's too complicated, and the bug resolution in FF is not very clean, so it would be worth to go back to your design which was <SPAN> based.
I saw an example of this pseudo-table design where <P> were used instead of <SPAN> (I've not the link right here, but you maybe know it : it displays butterfly drawings). The author said that the base sould be <P> because this tag implies a separation or a "pause" between the elements. IMHO he's right. I used <DIV> because I wanted to put images properties in a list

yoDan wrote:

(I can now see display bugs in the thumbnail list both in Opera and FF.)

The FF is caused by the fact it doesn't apply the vertical-algnement in this context
The Opera 7 bug is an old bug which makes it display a partial "gosht" of the next line first element at the end of the previous one. I think there is a known workaround but I couldn't find it again on the web.

yoDan wrote:

using the same class name "thumbnails" applied to a UL and a LI is IMHO a call for weird bugs in the future,

You are probably right ! Must change this!

yoDan wrote:

I do not understand ULs with a single LI (for the picture name, in category.tpl)

There is a single LI only if we display categories or if we don't display the comment numbers below the image name.

yoDan wrote:

a <LI>&nbsp;</LI> is certainly not quite right.

It's there so the page still validate when the user is not an admin and doesn't have the tools. Without it the validator complains about an empty UL. Feel free to give a better solution.

I let Zorglub answer for the other point except BSF = Best So Far ;-)


cepatre.net
Utilisateur depuis la version 1.3, Impliqué depuis la 1.4, Responsable du template des 1.5 et 1.6  ... et en (in)disponibilité sur la 1.7. J'ai fait l'impasse, et j'ai sauté directement en 2.2.2 !

Offline

 

#42 2005-08-22 21:53:30

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

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 :-)

Offline

 

#43 2005-08-22 22:03:49

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

As we speak about the thumbnails display, please take a look at this perfect display in Jimmac [1] photo gallery

[1] Jimmac is Jakub Steiner, creator of many icons for Gnome. I've taken all clear icons from his famous Gorilla theme :-)

Seeing Jimmac photo gallery, we must consider we have one difficulty he hasn't : displaying a caption under the thumbnail. Wouldn't it be cool if we had this difficulty squashed? We should think of something ingenious for differentiating a thumbnail representing a sub-category and a thumbnail linked to picture.php (and calendar would be hard to read :-/)

Offline

 

#44 2005-08-22 22:24:27

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13789

Re: Improved HTML and layout

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?

Offline

 

#45 2005-08-23 13:10:19

yoDan
Member
France
2005-06-05
39

Re: Improved HTML and layout

thumbnail display

The page you recall with butterflies is probably http://www.spartanicus.utvinternet.ie/c … ptions.htm. I can see it has been updated by its author since the time I mentioned it (third message in this thread) and it now "copes" with Mozilla/FireFox, except for the vertical-align part.

Regarding <BR />, I still think we should replace them... at least by <BR>!  I am afraid adding extra blocks (be it P, DIV or UL/LI) is likely to break the thumbnail. I dislike <BR>, for it is a presentational-only HTML element, but it is available, and we might have to use it. UL/LI doesn't seem proper markup to me anyways.

Regarding the vertical-align issue with gecko browsers, I trust Spartanicus tried many options, so I am sceptical we can find a solution right away (doesn't prevent anyone from trying, though).  I think I can bear with it, but I am biased, as FF is not my everyday browser. I can understand it is a serious issue for you guys. Wrapping the IMG in a DIV, just to specify a width and a height, might work (not tested).

As for Jimmac's gallery, not having a caption makes a world of a difference. He can use a simple <A ...><IMG ...></A>, make A a block of fixed height and width, and float it: he is done! Variable height is what causes us extra trouble.

Tools only available to admins, cause of empty LI

I think a <!-- BEGIN admin_tools --> block is how the templating system handles this kind of situations.

Paragraphs in comments

You are right, using P instead of BR is The Right Thing (tm), but where do you stop? Other funny things you might want to account for: multiple BR, simulated lists (like I do with
* item1
* item2
in this forum), and so on. The quick and dirty way (putting the whole comment in a P) would be fine with me (you respect all user-inserted line breaks, and assume no structure), but if you feel like doing something more sophisticated, please do. :)

Offline

 
  •  » Requests
  •  » Improved HTML and layout

Board footer

Powered by FluxBB

github twitter newsletter Donate Piwigo.org © 2002-2024 · Contact